Security Architecture for the TEAMDEC System By

2024-06-23 来源：好走旅游网

Security Architecture for the TEAMDEC System

Haiyuan Wang

Thesis submitted to the Faculty of theVirginia Polytechnic Institute and State Universityin partial fulfillment of the requirements for the degree of

Master of Science

Electrical and Computer Engineering

Mark Jones, ChairEloise CoupeyScott Midkiff

July 7, 1999Blacksburg, Virginia

Keywords: Network Security, Cryptography, Authentication, Digital Signature,Key Agreement, Java, TEAMDEC

Security Architecture for the TEAMDEC System

ByHaiyuan WangMark T. Jones, Chairman

Department of Electrical and Computer Engineering

(ABSTRACT)

The prevalence of the Internet, client/server applications, Java, e-commerce, andelectronic communications offers tremendous opportunities for business, education andcommunication, while simultaneously presenting big challenges to network security. Ingeneral, the web was designed with little concern for security. Thus, the issue of securityis important in the design of network-based applications. The software architectureproposed in this thesis allows for the secure and efficient running of a team-baseddecision support system, specifically TEAMDEC. Based on the system's requirementsand architecture, three types of possible attacks to the system are identified and a securitysolution is proposed that allows for user authentication, secure communication, and scriptaccess control. The implementation of these features will reduce security risk and alloweffective use of the valuable system information data.

Acknowledgements

I am deeply grateful to my advisor, Dr. Mark T Jones, for his continued guidanceand support throughout this work. Dr. Jones's extensive knowledge and creative thinkingwere truly invaluable.

I would like to express my gratitude to Dr. Eloise Coupey and Dr. Scott F.Midkiff for their comments and valuable contributions as members of my advisorycommittee.

My special thanks to Ms. Qian Chen and Ms. Jing Ma for their contributions tothis research project.

Finally I want to express my gratitude to my husband, Yu Wang, who gave me hislove and emotional support during the past years.

TABLE OF CONTENTS

Chapter 1Introduction

1.1 Introduction

1.2 Overview of TEAMDEC 1

121.3 1.4 Chapter 22.1 2.2 2.3 2.4 2.5 Thesis Statement

1.3.1Objectives of Research1.3.2ContributionsThesis Organization

Review and Background

Objectives of Network Security

2.1.1 Objectives of Network Security2.1.2 Threats to the Network System

2.1.2.1 People Threats2.1.2.2 Virus Threats2.1.2.3 Physical Threats

User Authentication

2.2.1 Authentication Objectives2.2.2 Authentication Methods

2.2.2.1 Passwords2.2.2.2 Physical Keys2.2.2.3 Biometrics

Access Controls

2.3.1 Password-based Scheme2.3.2 Access Control ListDatabase SecurityCryptography

2.5.1 Public Key Cryptography

iii

3345

66888991011111314141515161718

2.5.1.1 RSA Algorithm

2.5.1.2 Diffie-Hellman Algorithm2.5.2 Digital Signature2.5.3 Message Digest2.6 The Java Security API

2.6.1 JCA2.6.2 JCE

Chapter 3: Security Issues in TEAMDEC System

3.1 Overview of TEAMDEC

3.1.1 What is TEAMDEC?3.1.2 TEAMDEC's Architecture3.2 Security Requirement Analysis

3.2.1 Confidentiality Objectives3.2.2 Integrity Objectives

3.3 An Architecture for Achieving a Secure System

3.3.1 Possible System Attacks3.3.2 Security Methods3.4

Summary

Chapter 4: Implementation

4.1 User Authentication

4.2 Data Encryption to Prevent Eavesdropping Attack4.3 Script Access Rules

4.3.1 User Classification4.3.2 Script Access Rules

4.3.2.1 Access Control List4.3.2.2 Permissions on a Script

4.4 Database Protection4.5 Summary

20212122222324

25252729293335353739

414346464849495253

Chapter 5: Security Evaluation

5.1 User Authentication

5.1.1 Functionality

5.1.2 The Difficulty of Attack5.2 Secure Communication5.3 Database Server Issues5.4

Summary

Chapter 6: Conclusionand Contributions

6.1Conclusion6.2

Contributions

ReferencesVita

545457606262

6364

6670

LIST OF ILLUSTRATIONS AND TABLES

Figure 2.1Table 3.1Figure 3.1Figure 3.2Figure 3.3Figure 4.1Figure 4.2Figure 4.3Table 4.1Table 4.2Table 4.3Table 5.1Table 5.2Figure 5.1Table 5.3

Two Methods of Public Key CryptographyComponents of A Group Discussion ScriptTEAMDEC System ArchitectureSystem Architecture and Possible AttacksTEAMDEC Security ArchitectureUser Authentication Method - Client sideUser Authentication Method - Server sideKey Exchange between Client A and BScript Table

Script Access Control ListAccess Control List ContentTesting Results

Factoring Using the General Number Field SieveOperation of the Authentication AlgorithmFactoring Using the Quadratic Sieve

192728363842434550505155565759

Chapter 1Introduction

1.1Introduction

The growth of the Internet and the World Wide Web (WWW) during the past few

years has been dramatic. Most business and government institutions have their own webpages, and web browsing is quickly becoming the primary source of information forpeople of all ages. Current estimates indicate that there will be 500 million usersconnected to the Internet by 2001[1]. The prevalence of the Internet, client/serverapplications, Java, e-commerce, and electronic communications offers tremendousopportunities for business and education, while it simultaneously presents big challengesto network security because cyberspace is an open, distributed, and insecure environment.An organization’s key asset, business information, becomes exposed and morevulnerable. If no security measures are taken, unauthorized access to this information iseasy to obtain and difficult to detect. In this expanding electronic world, security issuestake on new importance and complexity. Enforcing security in such a complexenvironment requires a security model and administration. Unfortunately, the web wasdesigned with little concern for security. Thus, the issue of security is essential tonetwork-based application.

The software architecture proposed in this thesis allows for the secure andefficient running of a team-based decision support system, specifically TEAMDEC[2].

1.2Overview of TEAMDEC

TEAMDEC is an intelligent decision support tool that allows people to

coordinate information from many different information sources to facilitate decision-making. People can make decisions using information from the Internet, or from scriptspreviously stored on the database, or even through real-time communications with othermembers of the decision team. A key element of TEAMDEC is the script database,which can be used to guide team decision-making. The script database can be used toprovide suggestions about possible actions (information sources, personnel to contact)based on similar instances of past actions that are stored in the action database[3].

TEAMDEC can be used to help individuals or teams make better decisions more

efficiently, whether working alone, or with input from members of a team. The securitychallenges arising from these features are substantial.

The following are the main requirements influencing the security architecture forTEAMDEC:

(1) TEAMDEC is for military use. It demands a higher level of security than a simplecooperative system. Thus, to guarantee that only an authorized user can accessTEAMDEC, user authorization should be based on strong cryptography rather thanon a simple password-based authentication scheme.

(2) To provide guarantees of the integrity and the secrecy of scripts in TEAMDEC, there

is a need for fine-grained access control to individual scripts and their attributes. Thusa generic access model is required that enables access rights to be based on anindividual's role in the system.

(3) The TEAMDEC runtime environment involves dynamic user groups. In such anopen environment, communication among group members must be secure and, at thesame time, efficient. Authenticated key agreement protocol based on the Diffie-Hellman[4] method can be employed to achieve that purpose.

1.3 Thesis Statement

1.3.1 Objectives of Research

Due to the sensitivity of the data related to decision-making, especially before afinal decision is reached, security has been one of the main concerns of TEAMDEC.These issues demand a systematic response to making safe and controlled access toTEAMDEC along with its significant information - scripts. Thus, appropriate securitymechanisms should be identified in order to maintain the confidentiality and integrity ofsystem data. The research focuses on implementation of a security architecture that willprovide the following security functions:

(1) user authentication by using public key cryptography that offers powerful toolsfor proving identity,

(2) role-based, fine-grained access control model that provides a finer level ofsecurity control for individual scripts, and

(3) authenticated key agreement protocol based on Diffie-Hellman[4] for safecommunication among team members.

1.3.2 Contributions

First, the focus of this research is on how to develop a high quality GroupDecision Support System(GDSSs). Qian Chen’s research investigates the use of GDSSsas a practical aid for an organization and concerns with the factors influencing the qualityof an interactive software system and concentrates on the design of interactive GDSSs.Based on the theories and concepts of human decision-making, the design principles ofinteractive software and GDSSs are applied to the development of TEAMDEC. Severalconcerns are taken into account, primarily including usability, efficiency, effectiveness,and security, and these concerns influence the quality of TEAMDEC[2].

Second, the desired collaborative features of TEAMDEC have beenimplemented. These features include interactive, simultaneous communications amongteam members of TEAMDEC, for example, group discussion and videoconferencingfunctions. Real-time search and integration capability, for example, retrieving searchresults from commercial search engines on the Internet and displaying them. The mostimportant contribution is that the implementation of TEAMDEC script system. Thesystem is able to record and track the user's actions and provide the action suggestionscripts and thus improve quality and efficiency of decision-making. All these features arenecessary functions in group decision support systems

Third, the contribution of this thesis is that the security architecture is proposedand implemented. These security features enable the secure operation of TEAMDEC.The proposed security features include user authentication to prevent unauthorizedaccess, encryption/decryption mechanism based on the Diffie-Hellamn[4] key agreement

protocol for safe communication among decision team members and script access rules tomaintain the confidentiality and integrity of system data.

1.4 Thesis Organization

The thesis is divided into the following chapters. The first chapter begins with anintroduction and overview of TEAMDEC along with relevant security issues andidentifies the security architecture. It then gives the thesis statement and organization.The second chapter first gives an introduction to the objectives of network security. Itthen reviews literature on areas such as a user authentication system, cryptography andaccess control. The advantages and disadvantages of different algorithms and protocolsare also examined and compared. At the end of this chapter, new security features of Javaare reviewed. Chapter Three provides an overview of TEAMDEC and its architecture,then gives a detailed security requirement analysis of TEAMDEC. The analysis involvesthe examination of security objectives related to confidentiality, integrity, andavailability. It then defines three types of attacks and provides the proposed securityarchitecture. The fourth chapter goes into more depth on the implementation of thesecurity architecture of TEAMDEC. Topics include user authentication, data encryption,and script access rules. The evaluation of the security implementation is presented inchapter five. The analysis is based on two factors: computation speed and the ability toprevent different attacks. In addition, the advantages and disadvantages of the securityalgorithm are evaluated. The chapter concludes with a brief discussion of the possibleimprovement in the future. Chapter Six provides conclusions and closes the thesis.

Chapter 2Review and Background

This chapter presents a review of some areas in network security. The chapterbegins with an overview of network security. It then moves into user authentication andcryptography and presents some of the algorithms and protocols, such as public keycryptography and digital signatures. It continues with a review of access control anddatabase security. Finally, new security features in Java are discussed.

2.1Overviews of Network Security

2.1.1 Objectives of Network Security

With usage of the Internet and Intranets, today's networks are complex anddiverse. This diversity, both technically and geographically, means that network securitybecomes a critical, ongoing issue for an information technology environment. Systemdata and other sensitive information are exposed to threats such as unauthorized access,unauthorized modification, or unauthorized denial of services. Following are a fewfundamental objectives of network security [1].(1) Integrity

Integrity ensures that data is transmitted from the source to the destination withoutundetected alteration [6]. For example, if one wants to load a script from the databasein TEAMDEC, one wants to be assured that the script is exactly what is wanted andhas not been altered by a third party.

(2) Confidentiality

In communication, confidentiality requires that the intended recipients know whatwas being sent but unintended parties cannot determine what was sent[6]. Forexample, when a user shops online, he must ensure that his credit card informationmust be kept secret when transferred over the Internet. Other examples includecritical business information or personal data covered by privacy laws. Mechanismscommonly used to provide confidentiality are authentication[5] and encryption[6].For example, \"Hello, world!\" can be encrypted to \"xyOoLnWOH0eqRwUu3rQHJw\"by using a specific key[7].(3) Availability

Availability ensures that the authorized users of the system will not be deniedaccess when access is desired. An online stock trade system must be accessible to theinvestor when the stock market is open.

In addition to the fundamental objectives addressed above, several otherobjectives are frequently mentioned including accountability and disaster recovery.Accountability ensures that managers can determine who made what changes, when, andfrom where[1]. Summing up, these objectives provide the needed foundation for networksecurity.

The proposed software architecture for TEAMDEC uses public key-based userauthentication and data encryption to ensure data confidentiality, and uses role-basedscript access rules to ensure data integrity. All these schemes are used to achieve theobjectives of network security.

2.1.2Threats to the Network System

As the computer networks and distributed systems expand, they not only offerendless opportunities, but also create a number of threats. The threats are increasing asfast as the growth of the networks. Some threats are mainly due to people whodeliberately try to steal critical information and secrets or simply change data. Others arevirus threats and physical threats[1]. Each of these types of threats is discussed below.

2.1.2.1 People Threats

People threats usually include unauthorized use, deletion, and/or modification ofsystem data. Some people are hackers who are motivated by the desire to break intosecure systems. The most common form of access is through repeated loginattempts[5][8]. The other biggest threat is when an individual of an organization suppliesinformation (like account details) to a hacker in order to obtain confidential information.Using password protection often prevents the normal hacker. Using encryption schemescan provide more secure protection. These schemes will be discussed in detail later in thischapter. In TEAMDEC, to provide system data confidentiality and integrity, public keybased user authentication and script access rules are employed to prevent people threats.

2.1.2.2 Virus Threats

Computer viruses are the most widely recognized example of a class of programswritten to cause some form of intentional disruption or damage to computer systems ornetworks[1]. A virus is a piece of programming code inserted into other programming tocause some unexpected and, for the victim, usually undesirable event[9]. Viruses can be

transmitted by downloading files from other web sites or by files on a disk. The source ofthe file being downloaded or received is often unaware of the virus. The virus liesdormant until circumstances cause its code to be executed by the computer. Some can bequite harmful, erasing data or causing the hard disk to require reformatting. The bestprotection to prevent a virus is to know the origin of each program or file you load intoyour computer. Typically anti-virus software can help to remove any viruses that arefound.

2.1.2.3 Physical Threats

Physical threats usually originate from the physical environment. They caninclude electrical power failure, hardware failure or environment failures that causedamage to the whole system. Possible consequences include loss of system data, dataintegrity, and/or interruption of services[1].

To achieve secure and reliable operation of the network system, the threats to thesystem must first be identified and adequately addressed. Otherwise a threat, whether ofnatural causes or the result of human behavior, may cause substantial harm or loss to thewhole system. The proposed security architecture for TEAMDEC is mainly used toprevent people threats. The following discussions give a review of different schemes toact against people threats.

2.2User Authentication

The user authentication system is the first line to prevent unauthorized users from

gaining access to the system. Authentication is the process of reliably verifying the

identity of someone and ensuring the person is who he claims to be and not an impostor.Some authentication systems are accomplished with the use of a password that must bepresented to the system. Other authentication systems require the user to present aphysical key or physical characteristics, such as fingerprints. There are lots of examplesof authentication in our everyday life:

(1) By presenting the student ID card, the student is authorized to enter the VISC lab atVirginia Tech.

(2) At an automated machine, you identify yourself using your ATM card. You mustinput a personal identification number (PIN) to authenticate yourself.

(3) An online order company might accept as authentication the fact that you know theexpiration date on your credit card.

2.2.1Authentication Objectives

By providing only authorized users with an authentication to access the system,unauthorized users have no means of access. But this does not mean that unauthorizedusers are unable to gain access to the system because the system does not authenticate theidentity of a user, but who the user claims to be. That is, unauthorized users are able toaccess the system by appearing to the system as an authorized user.

Authentication is tremendously important in computer and network applications.The other party you communicate with may be in the next room or another city. Youhave none of the visual or aural clues that are helpful in everyday communication. Sincethe system cannot verify the user's true identity, measures must be taken to defend the

system. That is, the primary objective of an authentication system is to preventunauthorized users from gaining access to the system[10].

2.2.2Authentication Methods

The authentication methods have been categorized into three different types basedon something the user knows (e.g. a password), has (e.g. a physical card) or is (e.g.fingerprints)[11].

The first type is currently the most commonly used. A system requires the user toprovide specific information such as password or pass phrases to access the system. Thismethod has the advantage of both simplicity and easy implementation. However,passwords often provide an unreliable basis for authentication. The big problem withpassword-based authentication is eavesdropping[8].

The second type requires physical objects that a user must have to access thesystem. Examples of physical objects include smart cards and magnetic cards[5][8]. Thismethod provides a higher level of security than passwords alone and also is simple to use.

The third type is advantageous as it may not be easily guessed or stolen. It isusing a user's physical characteristics such as a fingerprint or hand geometry andmatching them against a profile to grant or deny access[5]. However, the technologyrequired to implement most biometrics methods is very expensive.

2.2.2.1 Passwords

Passwords or pass phrases are predefined words that an authorized user knowsand provides to the system for granting access. The passwords or pass phrases may be

assigned by the system or selected by the user. This type of method is one of the mostwidely used authentication methods. When a user presents the password that matches thepassword stored in the system for that user, the system grants access.

On some systems, passwords are administratively set to a fixed attribute of aperson, such as their birth of date or their email address. Although they are easier toremember, they are often easily guessed. Many systems allow users to select their ownpasswords that are difficult to guess. They also may be guessable if the imposter guessesenough times. In general, the password should be both easy to remember, but difficult toguess. In fact, any password, no matter how carefully chosen, can be guessed byenumerating all the finite characters sequences until you get the correct password.

There are many real problems with password-based authentication. For example,an eavesdropper might see the password when a user is using it to log in, the passwordmight be easy to guess, or an intruder might read the file where the system storespasswords. Several approaches can be taken to reduce such threats and to preventunauthorized people from gaining access to passwords. First, people should never write apassword down, and should change the password on a regular basis. Second, the systemcould keep track of the number of consecutive incorrect passwords entered for anaccount, and when the number exceeds a threshold, \"lock\" the account and refuse access,even with a correct password, until the system is administratively reset[8]. Third, theuser’s password file could be encrypted[12].

2.2.2.2 Physical Keys

Physical keys are objects that a user must have in his possession to access thesystem[13]. The most common is the key that we use everyday to unlock our home orcar. In computer and network systems, the three commonly used physical keys aremagnetic cards, smart cards, and specialized calculators[5].

A credit card is one example of magnetic cards. It is a piece of non-conductivematerial with an additional piece of magnetic recording material attached[13][14]. Theadvantages of using magnetic cards are that they are not easy to forge and they can holdinformation that is not easily memorized. There are disadvantages to using magneticcards. First, in order to use the magnetic card technology, the system requires hardware(e.g. card reader) on each access device, such as an access terminal or a physical accesspath (e.g. a door). Second, the card can be stolen or lost. To improve security, the cardmust be used with a PIN or password for authentication.

A smart card is a better type of physical key. It is a device similar to the creditcard but is capable of processing, storing, and manipulating data. The elements of a smartcard are a microprocessor, memory, input/output devices, and a power source[5][15].Due to the processing capability, smart cards have a lot of applications such as phonecards, vending machines, and road tolls. Smart cards are also being used in cellularphones and satellite TV's. Attempts are now being made to integrate all the applicationsinto a single card. Like magnetic cards, the serious practical problem with smart cards isthe need for card readers at every access terminal. But the information stored on a smartcard is safer than that stored on a magnetic card because smart cards are more difficult toduplicate and offer substantial protection against eavesdropping.

2.2.2.3 Biometrics

Biometric keys are used in the user authentication process due to theircharacteristics and recent advancements in technology. Biometric keys provide manyadvantages over password-based keys or physical keys because they belong to theauthorized user and are difficult to reproduce. There are various biometric keys. Somecommonly used ones are fingerprint, hand geometry, and retinal prints. Theauthentication process allows the granting or denying of user system access based on theuser's unique physical characteristics. The whole process is accomplished by obtaining anunverified sample from a user and comparing it to a previously authenticated sample.Biometric key authentication is very accurate and very difficult to reproduce. With therapid advances in technology, biometric authentication is becoming an attractiveauthentication method.

2.3Access Controls

Access control is the mechanism used to protect information from unauthorized

access. Access control can define not only who or what process may have access to aspecific resource, but also the type of access that is permitted[15]. Permissions aredefined by the system access control policy. An access control policy basically includes aset of rules that describe the methods in which a user can access the system resource.Various schemes can be used to implement access control and protect system resources,such as a password-based scheme, a capabilities based scheme, an access control list, andprotection bits. Only two of these are discussed below.

2.3.1Password-based Scheme

A password-based scheme is similar to its usage for user authentication. In orderto gain access to information (e.g., a file), the user must present the information'spassword to the system. In this technique, the password for specific information isdifferent from the password for the system. The system manager or the owner of theinformation originally assigns a password to the information. Then the information'spassword must be told to the user who is to be given access to the information.

Conceptually, this technique is easy to understand and easy to implement. It alsoprovides a fine grained security level. But it has several problems and is not suitable formost environments today. According to this scheme, users have to remember eachpassword for each specific information they will access. The first problem is that the userneeds to remember a large number of passwords. Also, with this technique there is noway to determine who has access to specific information because anyone who knows thepassword could access the information.

2.3.2Access Control List

An access control list (ACL) is a table that tells a system which access rights eachuser has to a particular system object, such as a file directory or individual file. Eachobject has a security attribute that identifies its access control list. The list has an entryfor each system user with access privileges. The most common privileges include theability to read a file (or all the files in a directory), to write to the file or files, and toexecute the file (if it is an executable file, or program). Windows NT[30], Novell'sNetWare 5[31], Digital's OpenVMS[32], and UNIX-based systems are among the

operating systems that use access control lists. The list is implemented differently by eachoperating system.

There are several advantages in using this method. Since a list is associated witheach file instead of each user, it is easier to determine who has access to a specific objectand easier to change a user's access permission. This technique also has twodisadvantages. First, it is very restrictive because a user can only access the objectsexplicitly named in the list and an object can only accessed by a specified set of users inits ACL. Second, it becomes difficult to update and check all the object's ACLs whenobjects are changed.

2.4Database Security

Database security, as a whole, is considered to deal with the confidentiality,

integrity, and availability of the data stored in a database system. Confidentiality meansinformation is only disclosed to those users who are authorized to have access to it.Integrity means information is modified only by those users who have the right to do so.For example, an employee should not be able to modify his own salary or change dataconcerning other payments. Availability means that information and other resources canbe accessed by authorized users when needed.

For most environments, the confidentiality and integrity are often taken as acombination. Normally this is the case for systems where incorrect data could result invast loss. A database may suffer from any of four different types of vulnerabilities[5].These vulnerabilities are inference, aggregation, data integrity, and Trojan Horses. Thefollowing paragraph gives definitions of these terms.

Inference means the derivation of new information from known information. Theproblem is that the new information may be classified at a level for which the user has nopermission. To properly protect a database from inference is not an easy task becauseinference vulnerabilities allow a user, either authorized or unauthorized, to determine thecontents of the data without performing any malicious actions. Aggregation is the resultof assembling or combining different tables of data when handling sensitive information.Aggregation of data might result in the dissemination of what would otherwise beconsidered hidden, or private, information. . Data integrity vulnerabilities allow theunauthorized or inappropriate modification, addition, or deletion of database data. ATrojan Horse is a program that performs a task that a user does not expect and does notwant completed[5]. Unlike inference and aggregation, a Trojan Horse attacks thedatabase operations and data.

Several security mechanisms can be used to prevent such vulnerabilities. Thesemechanisms are often similar to those employed in non-database systems, and theyemphasize different applications of cryptography.

2.5Cryptography

Cryptography is the science of writing messages that no one except the intended

receiver can read[15][16]. Cryptography provides stronger methods of authentication.Two examples of using cryptography are given.

A user can encrypt the data on his computer so that even if some people gainphysical access to the computer, they cannot access the data. Most web browsers (e.g.,Netscape Communicator or Internet Explorer) now support SSL (Secure Sockets

Layer)[17], a cryptographic protocol that encrypts information before it is transmittedover the Internet. Thus, a user can shop online using his credit card number withoutworrying too much that the number will be stolen.

2.5.1Public Key Cryptography

Public key cryptography is a system based on a pair of keys. The idea is to usetwo separate keys: a private key that need not be revealed to anyone, and a public keythat is preferably known to the entire world. These two keys are used for encryption anddecryption, and the decryption key cannot be derived from the encryption key. All knownmethods are quite slow, and they are usually only used to encrypt session keys that arethen used to encrypt the bulk of the data using a symmetric cipher.

The algorithm could work in two different ways (shown in Figure 2.1). Forexample, the public key could be used to encrypt a message by someone who has nevermet the recipient, and only the recipient with the private key could read themessage[15][16]. Or the private key could be used to sign a document, and anyone coulduse the public key to verify the signature[15][16]. The second way is often called a digitalsignature. Either way, two people do not need prior contact to communicate privatelyover an insecure channel.

Public keyPrivate key

PlaintextEncryptionCiphertextDecryptionPlaintextPrivate key Public keySigningVerificationPlaintext Signed messagePlaintext

Figure 2.1 Two Methods of Public Key Cryptography

The basic idea is that public key cryptography provides a means by which twoends of the network can trust each other. For example, in a simple client/serverapplication, the client application could send the user's credentials encrypted with theserver's public key and send them to the server. Then the server could decrypt the user'scredentials and authenticate the user's identity. If someone acquires the encryptedmessages by listening in on the entire process and has the server's public key, however,he can not recover either the client's credentials or the server's private key. This offersboth confidentiality and integrity for network messages.

In addition to the authentication example described above, public keycryptography also can solve many of the security problems of large, heterogeneousnetworks. In the proposed software architecture in this thesis, public key basedcryptography has been built into TEAMDEC to provide user authentication.

Two commonly used public key algorithms, RSA[18] and Diffie-Hellman[4], are

discussed below. Detailed descriptions of these two algorithms are given in [16].

2.5.1.1 RSA Algorithm

RSA (Rivest-Shamir-Adelman)[18] is the most commonly used public keyalgorithm. It can be used both for encryption and for signing. It is generally considered tobe secure when sufficiently long keys are used (512 bits is insecure, 768 bits ismoderately secure, and 1024 bits is secure, see Table 5.2). The security of RSA relies onthe difficulty of factoring large integers. Dramatic advances in factoring large integerswould make RSA vulnerable. RSA is currently the most important public key algorithm.At present, 512 bit keys are considered weak, 1024 bit keys are probably secure enoughfor most purposes, and 2048 bit keys are likely to remain secure for decades. One shouldknow that RSA is very vulnerable to chosen plaintext attacks - a form of cryptanalysiswhere the cryptanalyst may choose the plaintext to be encrypted[19]. In a chosenplaintext attack, the cryptanalyst not only has access to the ciphertext and associatedplaintext for several messages, but he also chooses the plaintext that gets encrypted.Because the cryptanalyst can choose specific plaintext blocks to encrypt, they might yieldmore information about the key[16]. If the key used to encrypt or decrypt the messages isdeduced, the algorithm is broken. The RSA algorithm is believed to be safe when usedproperly, but one must be very careful when using it to avoid these attacks. Manyimplementations of RSA are freely available.

2.5.1.2 Diffie-Hellman Algorithm

Diffie-Hellman[4] is a commonly used public-key algorithm for key exchange. Itis generally considered to be secure when sufficiently long keys and proper generatorsare used. The security of Diffie-Hellman relies on the difficulty of the discrete logarithmproblem (which is believed to be computationally equivalent to factoring largeintegers)[16]. Diffie-Hellman is sensitive to the choice of the strong prime and thegenerator. The size of the secret exponent is also important for its security. Conservativeadvice is to make the random exponent twice as long as the intended session key. Inpractice, if the same prime is used for a large number of exchanges, it should be largerthan 512 bits in size, and preferably 1024 bits.

2.5.2Digital Signature

A digital signature is used to verify that a message really comes from the claimedsender. It is completely analogous to a handwritten signature used for authentication. Incryptography, a digital signature is a block of data that was created using some privatekey, and there is a public key that can be used to verify that the signature was reallygenerated using the corresponding private key. It is fully described in[20]. Digitalsignatures provide two important functions: authentication and integrity.

The algorithm used to generate the signature must be such that without knowingthe private key it is impossible to create a signature that would be verified as valid.Digital signatures can also be used to timestamp documents, a trusted party signs themessage and its timestamp with the private key, thus testifying that the message existedat the stated time[16].

A digital signature of an arbitrary document is typically created by computing amessage digest from the document and concatenating it with information about the signerand a timestamp. The resulting string is then encrypted using the private key of the signerand a suitable algorithm. The resulting encrypted block of bits is the signature. It is oftendistributed together with information about the public key that was used to sign it. Toverify a signature, the recipient first determines whether it trusts that the key belongs tothe person it is supposed to belong to and then decrypts the signature using the public keyof the person. If the signature decrypts properly and the information matches that of themessage (proper message digest), then the signature is accepted as valid. Several methodsfor making and verifying digital signatures are freely available. The most widely knownalgorithm is RSA.

2.5.3 Message Digest

A message digest is also known as a cryptographic hash function[15]. It isbasically a mathematical transformation that takes a message of arbitrary length,transforms it into a string of bits, and computes from it a fixed-length number. Acryptographic hash function does this transformation in a way that makes it extremelydifficult to come up with a message that would hash to a particular hash value.Cryptographic hash functions typically produce hash values of 128 or more bits. Thisnumber is vastly larger than the number of different messages likely ever to be exchangedin the world. Many good cryptographic hash functions are freely available. Well-knownones include MD5[33] and SHA[25].

Detailed algorithm descriptions on MD5, SHA and digital signatures arediscussed in[16].

2.6The Java Security API

The Java security API is a set of packages that are used for writing secure

programs in Java. In particular, JDK 1.2 contains substantial security featuresenhancements: policy-based, easily-configurable, fine-grained access control; newcryptographic services and certificate and key management classes and interfaces[21].Two major components, JCA and JCE, will be discussed below.

2.6.1JCA

JCA stands for Java Cryptography Architecture. It was first introduced in JDK1.1and refers to a framework for accessing and developing cryptographic functionality forthe Java platform[22]. It specifies design patterns and an extensive architecture fordefining cryptographic concepts and algorithms.

The JCA includes a provider architecture that allows for multiple and interoperablecryptography implementations. The term cryptographic service provider (CSP), or simplyprovider, refers to a package (or a set of packages) that supplies a concrete implementationof a subset of the cryptography aspects of the JDK Security API[22]. In JDK1.1 a providercontains an implementation of one or more digital signature algorithms, message digestalgorithms, and key-generation algorithms. JDK 1.2 adds five more types of services:keystore creation and management, algorithm parameter management, algorithmparameter generation, key factory support to convert between different key

representations, and certificate factory support to generate certificates and certificaterevocation lists (CRLs) from their encodings. The JDK1.2 comes with a default provider,named SUN, that implements a few cryptographic algorithms including a number of DSAservices, MD5 and SHA-1 message digest algorithms, and X.509 certificates.

2.6.2JCE

JCE means the Java Cryptography Extension. Sun divided its cryptographicclasses into two groups because the U.S. government limits their export. The first groupis included in standard JDK1.2 and can be exported without limitation. The secondgroup is called JCE, and is for U.S and Canadian distribution only.

JCE extends the JDK to include API's for encryption/decryption, key exchange,and message authentication code (MAC)[23]. JCE and the cryptography aspects of theJDK provide a complete, platform-independent cryptography API. The algorithmssupported in JCE include encryption/decryption, password-based encryption, and Diffie-Hellman key agreement. By employing this package, one can efficiently reducedevelopment time and prevent errors in applications.

The Java security API is used to implement the security features of TEAMDEC.Because the API provides extensive support for cryptographic algorithms and protocols,hides a lot of implementation details, and exposes cryptographic concepts, it is suitablefor TEAMDEC's design and implementation. A security requirement analysis ofTEAMDEC is provided in Chapter 3. Detailed descriptions of these algorithms andimplementations are provided in Chapter 4.

Chapter 3Security Issues in TEAMDEC System

The development of distributed computing has recently accelerated toward asystem for sharing data, applications, and computing resources across networks. Asapplications become more distributed, more useful features are introduced, such as thosethat enable data sharing and information gathering. However, distributed systems alsointroduce an increased security hazard. Each site could have a security risk similar to thatof a centralized system, as well as the problems introduced by connecting to a network.For successful use of the application, one critical element - security - must be considered.

This chapter first gives a detailed description of TEAMDEC. Then the system is

analyzed with respect to security requirements and the type of security measures requiredto be taken.

3.1Overview of TEAMDEC

3.1.1 What is TEAMDEC?

TEAMDEC is a team based intelligent decision support tool, which integrates

information from different sources to facilitate decision-making[2][3]. With TEAMDEC,people can make decisions using multiple information sources such as scripts from thescript database, information from the commercial search engines (e.g., Yahoo, AltaVista)on the Internet, or through interactive real-time audio/video communication (e.g., videoconferencing) with other decision team members. All these features can help people tomake better decisions more efficiently, whether working alone or with a decision team.

A key element of TEAMDEC is the script database, which can be used to guideteam decision-making. The script database enables a user to specify a set ofinformation/actions that should be taken, and to label this \"script\" with a scenario name.Thus, when faced with the real situation, the user activates the script and follows thedesired procedure. For example, a user intends to carry out a discussion with a number ofon-line users about the issues of flight safety. The user must first set the option forsuggestion acceptance to “On”, which indicates that the user wishes to get actionguidance. After that step, the user’s activities are traced. Simultaneously, the systeminvokes its inference engine to derive timely action suggestions based on the user’s real-time activities in the TEAMDEC system, knowledge from the action database and otherdatabases, and rules which are related to predictive judgment, evaluative judgment, anddecision making. The system consequently produces advice on possible actions.Generally, the suggestion information is organized in the structure of the script as shownin Table 3.1. The script consists of two scenarios: the development of a discussion groupand the group discussion[2].

Develop a discussion groupOpen a window for selecting usersDisplay the user information

Select the user and add to the discussion groupRemove a user from the discussion groupConfirm and quit

Begin a group discussionOpen a window for group discussionGive a topic

Send an invitation with the topic to group membersGet agreement replies from members

Setup communication channels and begin discussionEdit the opinion expression and pose it outSend an off-line messageEnd the discussion

Table 3.1 Components of a Group Discussion Script[2]

The functionality of the scripts is one of the significant characteristics ofTEAMDEC. This unique feature makes TEAMDEC a flexible, useful, decision makingtool. From the table, we know that a script is a set of information that is stored in thescript database to guide a user's possible actions. Thus the script database is the mostimportant system asset in TEAMDEC.

3.1.2TEAMDEC's Architecture

TEAMDEC is a team-based decision support system, in which a leader makes a

decision with the input of a flexible team of people[3]. Figure 3.1 below shows the maincomponents of TEAMDEC and their connections.

Client 1(Applet)ApplicationServerSecurityLogin, Handleclient's requestDatabaseServerClientInfo TableScript/ActionTableClient 2(Applet)Client 3(Applet)External Information Sources(e.g., audio/video, Internet,whiteboard ) Figure 3.1 TEAMDEC System Architecture

Basically, the system is a multi-user client/server system and employs a three-tierarchitecture. The system has three components: the applet (also called client), theapplication server, and the database server. The applet is responsible for GUI display,communicating with other TEAMDEC applets, and sending requests (e.g., save requestfor saving actions, query request for querying about desired scripts) to the databasethrough the application server. The application server is the middle-ware between theapplet and the database server. The server is responsible for user authentication andhandling client's requests. The database server is responsible for storing and operatingsystem critical data including user information and actions/scripts.

3.2

Security Requirement Analysis

The process of analyzing system security requires the examination of security

objectives related to confidentiality, integrity, and availability. The following sectiongives a detailed analysis of the system requirements in TEAMDEC.

3.2.1Confidentiality Objectives

TEAMDEC is largely dependent on information transmitted among different

decision team members and between clients and servers to make it a flexible decision-making system. Without reliable, confidential information, it is not possible to achieve anefficient, better quality decision among decision-team members. Thus, ensuring theconfidentiality of the system information and protecting it from unauthorized accessbecomes the most important task in security analysis. The types of information inTEAMDEC are listed below.

The first type of information is that transmitted among different clients. Theinformation would be an invitation, a request, or a response. For example, an invitationmessage sent by a user to his team members would be: \"The discussion topic isEmergency, Would you like to join my discussion group?\" The second type ofinformation is the information transmitted between a client and the application server.The information sent by the client to the server would be the client's personal informationsuch as user name, user ID, the client's request code, and the client's action records orscripts. The request code is a digital number that identifies the type of request that theserver will accept. A record or a script is a string consisting of a series of strings, such astime, activity, description of the activity, and name of the action. These strings are

concatenated together and describe the user's actions. The information sent back from theserver to the client would be the server's response code. The response code is also adigital number that identifies the type of response from the server and the type of scriptsretrieved from the database server according to the client's search criteria.

These critical system data are all in plain text if they are not encrypted, whichmeans that when transmitting them from sender to receiver, they will not be secure overthe Internet. The data could be accessed by unauthorized people, and could be altered orviewed by a third party. When transmitting the data over the Internet, such a lack ofsecurity would be a major flaw.

In addition, if users from inside can get out to the Internet and get valuableinformation, then without precautions users from outside can get into the local system.This applies not only to the Internet, but also to any system if it allows users to come infrom the outside. Interconnection of networks introduces vulnerabilities as a result ofnetwork resource sharing with public users. Remote access can leave a system vulnerableto hackers, viruses, and other intruders. The client in TEAMDEC is implemented as aJava applet. Although Java can provide several benefits such as platform independence, italso introduces potential security issues.

Because the applet is a program written in the Java language, it can be included inan HTML page. When using a Java-enabled browser to view a page that contains anapplet, the applet's code is transferred to the local system and executed by the browser.Thus, anyone could run the applet anywhere in the world and access TEAMDEC as longas he used a Java-enabled browser to view the page. This will not be allowed because

only an authorized user should be able to access TEAMDEC. To prevent such a situationfrom happening, user authentication is essential.

In a distributed system such as TEAMDEC, a client sends sensitive informationto another client or to a server through an insecure communication channel, which mayhave the following risks. The system data of TEAMDEC is highly sensitive. The datacould be stolen and disclosed, which would do damage to the whole system and impactthe decision-making capability. Someone using the Internet could disguise himself as anauthorized user of TEAMDEC or could change the information content. For example, anintruder could look at the data packets transmitted on the network and intercept networkdata sent from client to server or vice versa via network eavesdropping. Eavesdropperscan operate from any point on the pathway between the two communication end points.This is one of the most difficult threats to be detected. Over the Internet, data packetsmay come through several nodes or even take different paths. For the end point users,there is no way to know exactly what happened during transmission. In the case ofwireless communication, the media is accessible to anyone. For mission-criticalinformation transmitted on the Internet by TEAMDEC, security measures must be takento prevent eavesdropping. Data encryption is the only defense against this kind of threat.

The following example could describe the possible attacks mentioned above.An airplane is in an emergency situation because its landing gear are locked.When the airplane approaches the airport, the pilot calls for help. With TEAMDEC, thecontroller opens the decision script for airplane landing. Following the script prompts, thecontroller contacts the manufacturer of the airplane and gets possible suggestions. Thenthe controller integrates the information from different sources and makes a decision with

his decision team. After the possible decision is made, the controller communicates withthe pilot and sends him the instructions for a safe landing.

During the whole rescue procedure, there are three possible attacks. First,information from the pilot is stolen or modified. If this mission-critical information ismodified, then the controller will not get the correct information and may make adecision that is not suitable for a safe landing situation. Second, the scripts in thedatabase are modified or deleted. If someone modifies the airplane landing script in thescript database, for example, then the sequence of instructions from the scripts aremodified and the decision team will not make a correct decision. Third, the instructionsfrom the controller to the pilot are stolen or modified. If the important instructions aremodified or lost, the pilot can not get the correct instructions and a safe landing will notbe accomplished.

Under any of the attacks described above, the rescue task can not be completedsuccessfully and the damage will be great. As seen from this example, securityconsiderations impact the whole system. This example demonstrates the most importantobjectives of TEAMDEC, confidentiality and integrity. For secure, timely, and accuratedelivery and receipt of the system data, TEAMDEC requires user authentication, accesscontrol, and encryption/decryption. These make up the desired security features ofTEAMDEC.

Different types of user authentication to prevent unauthorized access exist.Different methods may provide different levels of assurance and be used to protectagainst different threats. In TEAMDEC, there is a need not only for confidentiality, but

also for strong user authentication, because TEAMDEC is a distributed system over theInternet.

A password-based authentication scheme is a simple authentication method, but itis prone to attack by a user guessing password values. In a relatively low riskenvironment, it can provide protection for the system from attacks, in which an impostercannot see, insert, or alter the information passed between the sender and the receiverduring an authentication process. But using such a simple authentication method in adistributed network system can only provide weak authentication. The user authenticationmethod in TEAMDEC, which will be discussed in the next chapter, uses digitalsignatures with public/private keys and message digest function for the communicationbetween client and server. It provides a strong user authentication method, and it ensuresmutual confirmation of identification.

3.2.2Integrity Objectives

Integrity is an essential requirement for the proper operation of TEAMDEC. Thescripts stored in the database are the heart of TEAMDEC. By using this criticalinformation, the system helps develop a decision, and provides suggestions such as whoshould be contacted or which command should be issued when a specific situationhappens.

Everyone's role in the decision team environment is unique. For example, oneteam member might be the team leader, who gets information from different sources andcoordinates them before issuing a decision. Another team member might only collect

information from the Internet and report it to the team leader. These different functionsmay dictate that access rights to the scripts must also be different.

Shared use of TEAMDEC by independent team members introduces the risk ofunauthorized access to the critical system data and hence compromises the system'sintegrity. Because in today’s networks, disgruntled employees, hackers, and other formsof destruction are common, the threat may come from within the TEAMDEC usercommunity or from outside the system. For an outside threat, an unauthorized user couldbreak into TEAMDEC and modify some system critical information. For an insidethreat, any registered users can access, distribute, and even change valuable informationdata if proper security measures are lacking. Consider the following examples.

A user of TEAMDEC executes some actions such as changing record actions or

deleting scripts that he is not authorized to do. This is the kind of attack that breaks theintegrity of critical information. A disgruntled user of TEAMDEC would retrieve thescripts from the script database and send them to other people who are not related toTEAMDEC. This makes confidential information open to others and destroys thesecurity of the system.

The user authentication method can be used to prevent unauthorized access fromthe entry point of the system, while access control can protect highly sensitiveinformation from being disseminated to users who are not authorized to receive it.

Several access control schemes have been suggested in the literature[24][34][35].One of these is task and role-based access control for distributed applications[24]. Inorder to provide a fine-grained access control level to the critical scripts in TEAMDEC,a role-based access control method is employed. The access is granted by the user's role

in the system. In the next chapter, the method and its implementation will be discussed indetail.

In addition to the two major security aspects of TEAMDEC, confidentiality and

integrity, another security objective is availability. This issue is related to denial ofaccess, data loss, or disaster recovery. This is one area that many organizations mayoverlook[1]. As more and more organizations begin to utilize the Internet for theirbusiness, \"availability\" will be a key requirement for success.

3.3An Architecture for Achieving a Secure System

As the Internet expands its reach and scope, there are a growing number of

computer hackers who attempt to penetrate computers. Computer fraud is becoming morewidespread and sophisticated. The previous discussions on security requirement analysisof TEAMDEC indicate a critical need to protect system information, such as scripts,records, and users' personal information. The proposed security schemes in this thesisshould provide confidentiality and integrity.

3.3.1Possible System Attacks

The first step in designing a security architecture is to analyze systemrequirements and identify the possible risk areas in the running environment of thesystem. Based on previous discussions, we can examine TEAMDEC's architecture againand identify the possible attacks. Figure 3.2 shows the communication among the variousparties and the possible attacks.

Client 1Eavesdropping attackApplicationServer Eavesdropping attackDatabaseServerClient 2Break in attack Database attackFigure 3.2 System Architecture and Possible Attacks

A Break in attack is a type of attack in which the attacker tries to break into thesystem and obtain unauthorized access to system information. It can be prevented by auser authentication method. An eavesdropping attack is a type of attack in which theeavesdropper captures or modifies the information between the two end points of acommunication channel. In TEAMDEC, this type of attack is possible between theclients, between the client and the application server, and between the application serverand the database server. This type of attack can be prevented by using an access controlscheme, and/or by using an encryption/decryption method. The database attack is a typeof attack in which the attacker tries to gain access to the information database directly.An access control method implemented in the application server and in the databaseserver can prevent such attacks.

Once the possible attacks have been identified, the next step is to protect thesystem from such attacks by using user authentication, access control, andencryption/decryption methods.

3.3.2Security Methods

TEAMDEC employs a three-tier architecture. A three-tier architecture is a

special type of client/server architecture consisting of three well-defined and separateprocesses including a user interface, a middle tier, and a database management system,each possibly running on a different platform. The user interface runs on the user'scomputer (the client). The middle tier runs on a server and is often called the applicationserver and actually processes data. A database management system (DBMS) runs onanother server and stores the data required by the middle tier[36].

The main drawback to this scheme is the decreased speed compared to a two-tiersystem in which the clients are communicating directly with the database server.However, the three-tier architecture makes the system more secure. Since the databaseserver can only talk to the application server, it greatly limits the threat of someoneconnecting directly to the database server and causing damage.

Figure 3.3 shows the security methods proposed in this thesis to prevent thepreviously described possible attacks.

Client 1Encryption/Decryption EavesdroppingApplication attackServerattackEncryptionDecryptionUserAuthenticationDatabaseServerAccessControl EavesdroppingEncryption/DecryptionClient 2 Break in attack Database attack

Figure 3.3 TEAMDEC Security Architecture

Figure 3.3 also shows the proposed security architecture for TEAMDEC.

All the three possible attacks can be protected by the proposed architecture.

The user authentication scheme is based on public key cryptography[15][16][18].Each new user is first registered by the system administrator and given a pair of DSAkeys. The DSA private key is encrypted with the user's password. When the user logs intoTEAMDEC, he must present his password and private key for the client application togenerate a signature and send to the server for authentication. The server verifies thesignature by using the user's public key. If the signature has been successfully verified,then the user has been authenticated and will be granted access to TEAMDEC.

The encryption/decryption method employed in this architecture prevents aneavesdropping attack. At the beginning of the communication, two end points agree on asession key by using the Diffie-Hellman key agreement protocol[4][16]. The remainderof the communication is encrypted using the session key at the sender and is decryptedusing the session key at the receiver. The detailed algorithm description andimplementation are presented in the next chapter. Due to the communication between twoend points being encrypted, the information on the network is no longer plain text.Although an eavesdropper could capture the message, he can not recover the message.

There are two types of access control implementation. One is the access controlscheme that is implemented in the database server by the vendor. The access control listcan be configured using a database provided function. The other is proposed andimplemented in the application server for fine-grained access control to scripts. This kindof access control is based on the user's position in the system. It can be flexiblyconfigured and updated.

3.4 Summary

This chapter provides an overview of TEAMDEC and its architecture, then gives

a detailed security requirement analysis of TEAMDEC. The analysis involves theexamination of security objectives related to confidentiality and integrity. It thenidentifies the three types of attacks in the running environment of the system. Based onthe analysis, user authentication, access control, and encryption/decryption methods areproposed to protect the system from such attacks. In the next chapter, a detailedimplementation of the three security methods is presented.

Chapter 4Implementation

In the previous chapter, TEAMDEC's security risks are analyzed, and threepossible attacks are identified according to its security requirements. In this chapter, adetailed implementation is presented, including the user authentication scheme forpreventing break-in attacks, the key agreement protocol for preventing eavesdroppingattacks, and the access control model for preventing database attacks.

The implementation is accomplished by using existing Java security packages,specifically, the Java Cryptography Architecture (JCA) and the Java CryptographyExtension (JCE). The choice of Java provides the following advantages. The Javaplatform is a great development environment and provides a large number of libraries andprograms for network application development. Java is portable to nearly every platform,including Windows 95/98, Windows NT, and most UNIX systems. Java also provides aframework and implementations for encryption, digital signature, strong random numbergenerating, key management algorithms and support for encryption including symmetric,asymmetric ciphers in the Java Cryptography Architecture, which makes it an excellenttool for the development of secure applications. Java also enables software reuse andintegration capabilities because of its object model.

4.1User Authentication

User authentication is implemented in TEAMDEC to prevent unauthorized users

from stealing confidential system information not intended for their eyes and modifyingand executing scripts stored in TEAMDEC.

Through the user authentication method, the system can assure that the remoteuser is, in fact, an authorized user. Passwords are a simple solution to authentication; theyare easy to implement, but they are not considered very secure, especially when peoplechoose easy-to-guess passwords, or write down passwords in obvious places. A publickey based authentication scheme, which is used in this project, is a stronger form ofauthentication. The whole authentication procedure including key generation and keydistribution is outlined below.(1) Prepare public/private key pair

In TEAMDEC, a new user first must be registered. The TEAMDEC system

administrator generates a pair of public and private keys for each user using the DSAalgorithm[20].

(2) Encrypt the user's public key

The user's DSA private key is encrypted with the user's password. The name ofthe encryption algorithm implemented in JCE is PBEWithMD5AndDES. PBE stands forpassphrase-based encryption. PBEWithMD5AndDES is a particular variant of PBE; aMD5 message digest is used to digest the passphrase. The digest value is then used as aDES key. The detailed algorithm is described in PKCS#5, a document published by RSAData Security, Inc[12].

(3) Client generates signature

Upon logging in, the user is prompted for his user name and password. Thepassword is used to decrypt the user's private key. The client generates a timestamp and arandom number. Then the client creates a signature using this data and his private key.After the digital signature is generated, the client sends this information to the server forverification. Figure 4.1 shows the method[7] on the client side:

Random number

Timestamp

Signature To Server Password Client Decryption Private Key

User nameFigure 4.1 User Authentication Method - Client Side

(4) Server verifies signature

After receiving the information from the client, the server retrieves the user'spublic key according to the user's user name. The server verifies the signature with theclient's public key and decides either to allow the user into the system or deny access.

A signature provides two security services, authentication and integrity. Recallfrom Chapter 2 that a signature is a message digest that is encrypted with the signer'sprivate key. Only the signer's public key can decrypt the signature, which provides

authentication. If the message digest matches the decrypted message digest from thesignature, then integrity is also assured.

The name of the algorithm used to generate the message digest in JCA is SHA.SHA stands for the Secure Hash Algorithm that was developed by the National Instituteof Standards and Technology (NIST)[25]. Figure 4.2 shows the method[7] on the serverside.

From Client Random number

Timestamp

Signature User name

User’s public key

Verify SignatureFigure 4.2 User Authentication Methods - Server Side

Safely maintaining and distributing the private/public key files is the mostimportant task. Usually, it involves saving the private key file on a removable media, andcarrying it when logging in. Detailed discussions on public/private key security and apossibility of storing the private key file on a smart card are presented in Chapter 5.

4.2Data Encryption to Prevent Eavesdropping Attack

In TEAMDEC, communication among clients, or between client and server are

on an insecure medium, the Internet. It is not hard to eavesdrop because data is sent inplain text over the network. In order to guarantee safe communication between differentclients and between client and server, cryptography must be added to the system,providing authentication for each end of the conversation and encryption for the

communication itself. A common way to protect information is to encrypt it at thesending end and decrypt it at the receiving end.

The Diffie-Hellman (DH) key agreement protocol[4] is employed in TEAMDECto secure conversations on networks. At the beginning of the conversation, each end pointagrees on a session key that will be used to encrypt each data packet sent between them.The remainder of the conversation is encrypted using the session key. The followingprocedures show how the protocol works between two communication end points, calledClient A and Client B. The whole key agreement procedure is presented in Figure 4.3.(1) At the beginning, create new DH parameters - base and modulus.

(2) Client A creates his own DH key pair using the DH parameters above. Then heexecutes Phase1 of his version of the DH protocol. He encodes his public key andsends it to Client B.

(3) B has received A's public key in encoded format. He creates a DH public keyfrom the encoded key material. B gets the DH parameters associated with A'spublic key. He uses the same parameters to generate his own key pair. B executesPhase1 of his version of the DH protocol and encodes his public key, and sends itover to A.

(4) Client A uses B's public key for Phase2 of his version of the DH protocol. Beforehe can do so, he has to create a DH public key from B's encoded key material.(5) B uses A's public key for Phase2 of his version of the DH protocol.

(6) At this stage, both A and B have completed the DH key agreement protocol. Eachgenerates the (same) shared secret.

During the subsequent conversation, each end can use the generated secret key tocreate a DES[26] key, which can be used to encrypt their messages. Although someone isable to hear the entire exchange between A and B, he will not know the shared secret andsubsequent communications between them.

DH Parameters(Base b and Modulus m) Client A Client BUsing b and m, create aDiffie-Hellman key pairUsing b and m, create a Diffie-Hellman key pair A's public keyCompute the secret keyusing own private keyand B's public key B's public keyCompute the secret keyusing own private key andA's public keySecret KeySecret KeyFigure 4.3 Key Exchange between Client A and B

This key agreement protocol can easily be expanded to include three or moreparticipants. For example, if A, B and C participate in a communication, imagine themsitting around a table. Each one picks DH parameters and computes his own DH key pair.

Then each one passes his public key to the person sitting to his right. Thus, each personcan calculate the secret value based on the other person's public key and his own privatekey. If there are 5 participants, 4 exchanges of information are required before the secretvalue can be calculated[7]. During the whole procedure, five session keys will becalculated that all of these have the same value. The Diffie-Hellman algorithm isimplemented in JCE.

4.3Script Access Rules

4.3.1User Classification

In many systems, misuse of the administrative procedures could corrupt thesystem data or deny service to users. In TEAMDEC, measures are taken to prevent suchthings from happening. The system decides whether to allow procedures based on theuser's identity, the system scripts' attributes, and the type of operation the user isattempting. In TEAMDEC, users are divided into two categories: System Administratorand General Users.(1) System Administrator

The administrator is a trusted user, authorized to perform system management andmaintenance functions essential to the smooth and secure running of the system.These functions are not available to the general user; only the administrator mayaccess them through a separate administration program. The TEAMDEC systemadministrator has exclusive control over the registered user database and scriptsdatabase. The administrator has the following responsibilities:

a. Setting up a new user's account

To establish a user account, the administrator must run the system administrationprogram, type certain items, such as user name, user ID, password, user position,user position ID, and group ID to describe the new user, and create an entry in theregistered user database and public/private files, when placing the group ID in theuser database asserts that the user is a member of the specified group.b. Deleting an existing user's account

When the user leaves the organization or ceases to require access to TEAMDEC,deleting the inactive account improves security. To do this, the systemadministrator may run the administration program and remove the entire entrythat defined for the user.c. Setting up user groups

To create user groups, the administrator needs to run the administration program,type the group name, the group ID, and a list of names of the users who areauthorized to be members of this group, and then place an entry in the groupdatabase.

d. Deleting user groups

A group is deleted by removing an entry from the group database.

(2) General User

When a user logs into the system, the user needs his user name, user ID, group ID,and password for authentication. That means the user can only work in one group at atime, even though he may be a member of several groups.

The user database is used to hold information about registered users of the system.Each entry in the user database includes each user's login name, user ID, position,position ID, and group ID. The user database is totally controlled by the systemadministrator.

Each user must be a member of at least one group and can be a member of severalgroups. If one user is a member of several groups, the administrator may need to placemore than one entry in the user database for this user. In this situation, the system treatsthe user as different users.

4.3.2 Script Access Rules

Scripts are the critical data in TEAMDEC. Each script has several associateattributes that are related to security. These attributes specify the script's access controllevel. In TEAMDEC, the system administrator will specify different permissions fordifferent users and groups. The primary reason is to identify those who can read thescript, who can modify the script, and who can execute script, thus, efficiently preventingunauthorized use of the system data and preventing database attack. The followingparagraphs discuss this point in detail.

4.3.2.1 Access Control List

An access control list (ACL) is a table that specifies which permission each userhas to a particular system object. In TEAMDEC, the system objects are the scripts. Eachscript has a security attribute that identifies its access control list. The list has an entry foreach system user with access privileges.

4.3.2.2 Permissions on a Script

The three common permissions on each script are as follows:

Read Permission: The permission to display the name, commands, anddescription of the script in a table, regardless of whether the user has permission to accessthe script.

Modify permission: The permission to change the script's name, edit, and deletethe script only if the user or the group has appropriate privileges to do so.

Execute permission: The permission to execute the commands of the script onlyif the user or the group has appropriate privileges to do that.

An access control list is associated with each script. Each access control list hasone or more access control entries (ACEs) consisting of the name or ID of a user or groupof users. The user ID is assigned according to the user's role in the system. For each ofthese users, groups, or roles, the access privileges are stated in a string. The systemadministrator creates the access control list for each script.

Table 4.1 shows a script table. For simplicity, the table does not list all thecolumns in the script table. Other items, such as Sub Command and parameters, are notlisted.

TimeUser IDUser NameCommandGroup

DescriptionGroupDiscussionsessionSend online

Script Name

4/12/99aliceAliceDiscussionScript a

5/03/99bobBobSend Noticenotice to aliceScript b

Table 4.1 Script Table

The first column is the script name and the second column is the name of theaccess list. In this three-entry table, each entry in the table specifies the access control listfor the script. The system would look at the access control list and determine whether theuser who made the request had access privilege. In Script b, for example, the accessprivilege is defined in ACL2.

Though it is possible to put all the data into one table, it is not logical to do this allof the time. For example, the access control list information could be added in table1;however, the purpose of the script table is to store data on scripts. The solution is tocreate another table, called Table 4.2, which will contain information about the specificaccess control list name and associate it with Table 4.1. Table 4.2 shows a table that tellsthe access control list about scripts.

Script NameScript aScript bScript c

Access Control List Name

ACL1ACL2ACL3

Table 4.2 Script Access Control List

Table 4.3 is another table that shows the content of an access list for each script.Suppose this table shows the content for ACL2. Each entry in the table determines theprivileges for each system user.

User ID/Position ID

bobaliceSystem

Permission to

readReadRead

Permission tomodifymodify

Permission toexecuteexecuteexecuteexecute

Table 4.3 Access Control List Content

In this three-entry ACL example, before reading, modifying, or executing thescript, the system would look at the list and determine whether the user who made therequest had the access privilege. The ID bob, for example, could read the script or modifyand execute it. But the user whose ID is alice could read the script or execute it, butwould not be allowed to modify it.

As seen in the previous example, the three tables are related to each other. Table4.1 contains a column that has the script name. This script name also appears in Table4.2, which relates to Table 4.3. Table 4.3 lists the content of the access control list.Suppose a user whose ID is Tom needs to access Script b. The system would look atTable 4.2 first and identify that ACL2 specifies the access rules for Script b. Then the

system scans every row in Table 4.3 and tries to find a match. If there exists acorresponding entry in Table 4.3 that matches the user's ID, then the system will grantTom access privilege to Script b. In this example, the system cannot find an entry inTable 4.3, so Tom's request to Script b is denied.

4.4 Database Protection

In addition to the three measures discussed above, TEAMDEC's database server

must also be considered for security concerns. As the repository for critical and sensitiveinformation of TEAMDEC, a secure database server is the key technical component inaddressing the overall security requirements of TEAMDEC. Although network servicesand encryption devices also provide important measures, the database server is chieflyresponsible for processing the most valuable and vital portions of the whole system.

TEAMDEC employs a three-tier architecture, adding a middle application server

between the client and the database server. The rationale for this architecture is to isolatethe database server for security. This kind of architecture introduces four advantages.First the database server can only handle a limited number of connections. The middleapplication server can have several clients on one side, while using only one connectionto the actual database server, thus reducing the likelihood of breaks-ins into the systemdata repository. Second, moving the access-control list from the database server to themiddle application server will further secure the database server, so that only certainusers can access certain databases based on the privileges the system gives them. Third,the database server can be physically isolated. Finally, using a commercial off-the-shelf

database package that has more security mechanisms can further improve systemsecurity.

4.5Summary

Based on the analysis of TEAMDEC's security risks, this chapter goes into more

depth on the implementation of the security architecture of TEAMDEC. The threesecurity methods, the user authentication scheme, the key agreement protocol, and thescript access control model, are presented. Finally, database protection is discussed forsecurity concerns. In the next chapter, the security implementation of the system isevaluated and possible suggestions are provided for future development.

Chapter 5Security Evaluation

Security evaluation is one of the important stages in the whole securityarchitecture development. With security evaluation, the strengths and weaknesses of theimplementation can be identified, and the quality of software architecture can bedetermined. Thus, the system can be continually enhanced in the future.

This chapter analyzes the security implementation, which is described in theprevious chapter. The analysis is based on functionality and the ability to preventdifferent types of attacks. In addition, the advantages and disadvantages of the securityalgorithms are evaluated, and possible improvements are suggested for futuredevelopments.

5.1 User Authentication

5.1.1Functionality

Public key based user authentication has been implemented in TEAMDEC to

prevent unauthorized access. The obvious advantage of this scheme is that it is moreconvenient than secret key cryptography, because it is not necessary for two parties toauthenticate each other by sharing a secret key. In addition, one of the most importantaspects of public key cryptography is that it enables digital signatures, which are used foruser authentication.

However, the disadvantage of the public key based method is the performancepenalty incurred. As noted in Chapter 4, to use this method, public/private keys must be

generated, the private key needs to be encrypted and later decrypted, and the signaturemust be generated and verified. The cost of this method is affected by the key size. Table5.1 shows the time needed for the whole authentication procedure. These results aretested on a Pentium II 450MHz system with 128M memory running the Windows 98operating system. The time required to generate DSA Key Pair is obtained by running thesystem administration program in which a pair of DSA keys are generated for each user.The time required for client signing is observed when a client logs into the system. Itincludes the following periods: the time to generate a timestamp, the time to generate arandom number, and the time to generate the signature using his private key. The timerequired for server verifying is examined at the server side when the server receives theinformation and verifies the signature.

Key Size(# of bits)5127681024

GeneratingDSA Key Pair

334003345033560

ClientSigningTime ( ms )

331203317035700

ServerVerifying337403389036410

Table 5.1 Testing Results

Public key algorithms are based on the difficulty of factoring large numbers thatare the product of two large primes[16]. Factoring large numbers is difficult, but with theadvances in computer technology and mathematics, factoring large numbers is requiringless time than in the past. Table 5.2 lists some results from[16].

# of bits5127681024128015362048

Mips-years required to factor

30,0002*1083*10111*10143*10163*1020

Table 5.2 Factoring Using the General Number Field Sieve

Mips-year: a one-million-instruction-per-second (mips) computer running for oneyear.

The table above shows that when the size of the key only increases once or twice,

the time to factor increases dramatically. Thus, the length of the key plays an importantrole in the security of public key based authentication method. It is very difficult todetermine which key size is appropriate. The shorter the key size, the likelier it is to befactored and attacked. The longer the key size, the more difficult it is to attack, but thegreater the computation time needed to generate key pairs and to perform signing andverification.

From the testing results in Table 5.2, large key length doesn’t impose excessiveoverheads on computing time. When the key length increases from 512 bits to 1024 bits,the key generating time, client signing time, and server verifying time only increased0.48%, 7.8% and 7.9%, respectively. But the security benefit is very impressive: theMips-years required to factor increased from 30,000 to 3*1011.

5.1.2 The Difficulty of Attack

Another issue in evaluating an algorithm is the algorithm's ability to resistdifferent types of attacks. The figure below shows the entire authentication procedure.

Client Application Server

Password Signing SignatureVerifying Private Key Public Key

Figure 5.1 Operation of the Authentication Algorithm

Consider the following types of possible attacks.

First the attacker gets only the user's password. Suppose the user's password isstolen or guessed, can the attacker break into TEAMDEC? This possibility does notexist, because the authentication procedure depends not only on the user's password, butalso on the user's private key. Without the private key, all the following authenticationprocedures can not be performed. This is the obvious advantage of the public key basedauthentication method over the traditional password-based authentication method.

Second the attacker gets the user's private key. If the attacker gets the user'sprivate key, can the attacker break into the system? At this time, the possibility ofbreaking into the system is greater than in the previous attack. Because the attacker hasstolen the user's private key, he may try different methods to get the user's password, and

then successfully break into the system. Usually people choose easy-to-rememberpasswords. For example, some people choose their birthdays or other relevant personalinformation as passwords. Sometimes people write down their passwords and keep thisrecord on a little piece of paper in their wallets. All these habits give the attackeropportunities to attack the system. There is a type of attack called \"dictionary attack\"[16]because the attacker uses a dictionary of common keys. By using this system, 40 percentof the passwords on the average computer can be cracked[16] . Hence, how to store andprotect the users' private keys becomes one of the most important issues in theTEAMDEC to improve system security.

As seen in Chapter 2, the physical and electrical properties of the smart card makeit an ideal medium for safely storing private keys. If the user's private key is on a smartcard, and the private key never leaves the smart card, then the system would never be in asituation where it is easily compromised. With the smart card the private key is portableand can be used in different places no matter whether the user is at work, or at home. Inaddition, storing the private key in a smart card is more secure. For example, if theprivate key is stored in a floppy disk and protected by a password, then the private keyfile can probably be attacked by a \"dictionary attack\"[16]. But if the private key is storedin a smart card, the card will normally lock itself up after several consecutive badpassword attempts. Thus \"dictionary attack\" is no longer a feasible way to get the privatekey. However, any security system, including smart cards, is breakable. There alwaysexists a trade-off between cost and performance. Choosing a smart card to protect aprivate key depends on the cost of the equipment and the security level to be achieved.

Third, the attacker gets the user's public key. If this situation happens, the attackerhas the user's public key, but it does not do him any good. Based on the theory of publickey cryptography[4][15][16], it is computationally hard to deduce the private key fromthe public key, because public key cryptography relies on one-way functions; functionswhich are easy to calculate but hard to reverse without prior knowledge. Factorization isone example of a one-way function. It is often difficult to factor large numbers, but easyto verify a factorization. For example, it is harder to factor 6231 than to verify that 67*93= 6231. With the development in computer technology and networks, no one can predictadvances in mathematical theory. The table below shows the number of decimal digitsfactored [16] in different years.

Year198319851988198919931994

# of decimaldigits factored

718090100120129

How many times harder tofactor a 512-bit number

> 20 million> 2 million250,00030,000500100

Table 5.3 Factoring Using the Quadratic Sieve

This is a very fast-developing field. Recently, RSA Data Security, Inc. publishedthe following information[27]:

\"On February 2, 1999, a group of researchers completed the factorization of the140 digit RSA Challenge Number. The work was accomplished with the GeneralNumber Field Sieve.

Sieving was performed on about 125 SGI and Sun workstations running at 175MHz on average, and on about 60 PCs running at 300 MHz on average. Theelapsed time was one month and the total amount of CPU-time spent on sievingwas 8.9 CPU years.\"

With the advances in mathematical theory and computer technology,computational algorithms, once considered infeasible to break, may be breakable in thefuture.

5.2 Secure Communication

Secure communications between two end points of an unsafe communication

channel are achieved through the Diffie-Hellman key agreement protocol[4] whichgenerates a session key first, and then encrypts the remainder of the conversation usingthat session key.

Although using the Diffie-Hellman key agreement protocol[4] is efficient for keyagreement and eliminates the need for prior communication between users, the possibilityof attacks still exists.

If an eavesdropper sits between the two parties and is able to hear the entire keyexchange procedure, will he be able to know the value of the secret key? This questioninvolves the security of the Diffie-Hellman algorithm[4]. During the entire key exchange,the two parties exchange their DH public keys. From the previous discussion, we know it

is computationally hard to deduce the private key from the public key. If the time neededto figure out the private key from the public key is too long, the session maybe already befinished. Thus, the attacker will not succeed.

If an eavesdropper sits between the two parties and is able to get the encryptedmessage, will it be hard for him to recover the session key? This question involves thesecurity of the DES algorithm. DES stands for Data Encryption Standard, which isdescribed in NIST FIPS 46-2 [26]. According to the document, DES has a 64-bit blocksize and uses a 56-bit key during execution (8 parity bits are stripped off from the full 64-bit key). When using DES, there are several practical considerations that can affect thesecurity of the encrypted data.

In our application, a different DES key is generated for each session, and a securekey agreement is provided by the Diffie-Hellman algorithm[4] that will improve thesecurity of DES. Despite the efforts of researchers over many years, no easy attack onDES has been discovered. There is a fact stated in[27]:

\"Most recently, Distributed.Net, a worldwide coalition of computer enthusiasts,worked with the Electronic Frontier Foundation's (EFF) \"Deep Crack,\" a speciallydesigned supercomputer, and a worldwide network of nearly 100,000 PCs on theInternet, to win RSA Data Security's DES Challenge III in a record-breaking 22hours and 15 minutes, beating the previous record of 56 hours\".

Clearly, for a session this kind of attack is normally impractical. But if a session isrecorded, the break in opportunity now exists because the attacker could decrypt the keyin the future and thus get the secret messages between the two parties.

5.3

Database Server Issues

The database server in TEAMDEC system plays an important role, since the

primary goal of TEAMDEC is to provide better decisions based on the past actions andscripts stored in the database. Ideally, database security should enable the system to haveconfidence that its data repository will provide the information requested and expected,while denying accessibility to those who have no right to it. However, issues existrelating to the database server, in particular, speed and security assurance.

The database server used in TEAMDEC is Mini SQL[28]. Mini SQL is alightweight database server for both large and small data sets. In addition to the basicfunctions it provides for manipulating data, the Mini SQL server also provides functionsto control unauthorized access through an access control list. It does not supportencrypted connections, however, and thus is still vulnerable to security breaches. Unlikesome commercial database products, the Mini SQL server does not support powerful andflexible security mechanisms to provide assurance. To prevent possible attacks on thedatabase server, and to improve confidentiality, integrity, and availability, it is better toreplace the current Mini SQL server with commercial products such as Trusted Oracle7[29] from Oracle Corporation in the future.

5.4 Summary

This chapter gives an evaluation of the security implementation. The evaluation

procedure is based on two factors: functionality and the ability to prevent different typesof attacks. In addition, the advantages and disadvantages of the security algorithms areevaluated and possible improvements are suggested.

Chapter 6Conclusion and Contributions

With the growing popularity of the Internet, network security is a foremostconcern for many applications. With proprietary technology, a network security solutioncan secure the application running on an unsafe medium, such as the Internet.

6.1Conclusion

The software architecture proposed in this thesis enables the secure and efficient

operation of TEAMDEC: a team-based decision support system. Based on the system'srequirements and architecture, three types of possible attacks to the system are identified,and a security solution is proposed that includes user authentication, securecommunication, and script access control. The implementation of these features reducessecurity risk, improves the overall system security, and effectively uses the valuablesystem information data. Several advantages are provided by this architecture.

First, TEAMDEC demands a higher level of security than a simple distributed

application. To guarantee that only an authorized user can access TEAMDEC, a publickey based user authorization scheme is employed. The scheme can ensure that the remoteuser is, in fact, an authorized system user. In addition, with a digital signature, the schemeprovides two security services, authentication and integrity.

Second, the Diffie-Hellman key agreement protocol[4] is employed to achievesecure communications among team members in such an open network environment. By

exchanging keys and computing the shared secret key, the two parties can exchange thekeys and messages over an unsafe communication channel.

Third, a generic script access model is defined to provide integrity and secrecy ofscripts in the TEAMDEC. The model allows fine-grained control access to individualscripts and their attributes that is based on the individual's role in the system.

The implementation is accomplished by using existing Java security packages,specifically, JCA and JCE. By using these commercial Java security packages, it is fastand efficient to develop the security features of TEAMDEC.

The development of appropriate security measures for TEAMDEC necessitatedthe evaluation of security performance of the software. While the options adopted forTEAMDEC appear appropriate, it is important to note that computer technologiesadvance every day. As a result, algorithms or applications currently considered securemay not be secure in the future. The evaluation procedure is valuable and it can be usedto maintain and improve the system in the future.

6.2 Contributions

The contributions of this research are twofold. First, the desired collaborative

features of TEAMDEC have been implemented. These features include interactive,simultaneous communications among team members of TEAMDEC and real-time searchand integration capability. The most important contribution is that the implementation ofthe TEAMDEC script system. The system is able to record and track the user's actionsand provide the action suggestion scripts. The second area of contribution of this researchand specifically of this thesis is that the security architecture is proposed and

implemented. These security features enable the secure operation of TEAMDEC and thusimprove the quality and efficiency of TEAMDEC's decision-making capability.

References

[1]. Krause, M., Tipton, H. F., Handbook of Information Security Management, CRCPress LLC, 2000 Corporate Blvd., N.W., Boca Raton, Florida 1999.

[2]. Qian Chen, TEAMDEC: A Group Decision Support System, M.S. Thesis, VPI&SU,Blacksburg, July 1998.

[3]. Eloise Coupey and Mark T. Jones, TEAMDEC: Integrative Decision Solutions WithMultiple Information Sources, Research Proposal, VPI&SU, Blacksburg.

[4]. W. Diffie and M.E. Hellman, New Directions in Cryptography, IEEE Transactionson Information Theory, v. IT-22, n. 6, Nov 1976, pp. 644-654.

[5]. Gregory B. White, Eric A. Fisch and Udo W. Pooch, Computer System and NetworkSecurity, CRC Press, 2000 Corporate Blvd., N.W., Boca Raton, Florida 1996.[6]. R. Atkinson, Security Architecture for the Internet Protocol, RFC 1825, NetworkWorking Group, August 1995.

[7]. Jonathan Knudsen, Java Cryptography, O'Reilly & Associates, Inc. 101 MorrisStreet, Sebastopol, CA 1998.

[8]. Kaufman, C., Perlman, R. and Speciner, M., Network Security, Private

Communication in a Public World, PTR Prentice Hall, Englewood Cliffs, New Jersey,1995.

[9]. \"Virus\http://www.whatis.com/, May 1999.

[10]. Fites, P. and Kratz, M. P. J., Information System Security: A Practitioner'sReference, Van Nostrand Reinhold, New York, New York, 1993.

[11]. Wood, H.M., The Use of Passwords for Controlled Access to Computer Resources,National Bureau of Standards Special Publication 500-9, U.S Dept. of Commerce/NBS,1977.

[12]. \"PKCS#5\http://www.rsa.com/rsalabs/pubs/PKCS/html/pkcs-5.html, RSA Labs, March 1999.

[13]. Russell, D. and Gangemi Sr., G. T., Computer Security Basics, O'Reilly &Associates, 1991.

[14]. American National Standards Institute, American National Standard ANSI/ISO7810-1985: Identification cards - physical characteristics, New York, New York, May20, 1988.

[15]. Nichols, Randall K., ICSA Guide to Cryptography, McGraw-Hill, GahannaIndustrial Park, 860 Taylor Station Road, Blacklick, Ohio 1999.

[16]. Bruce Schneier, Applied Cryptography, Second Edition, Protocols, Algorithms, andSource Code in C, John Wiley & Sons, Inc, 605 Third Avenue, New York, 1996.[17]. Alan O. Freier, Philip Karlton and Paul C. Kocher, \"The SSL Protocol Version 3.0\Online document at http://home.netscape.com/eng/ssl3/draft302.txt, November 18, 1996.[18]. R.L. Rivest, A. Shamir, and L.M. Adleman, A Method for Obtaining DigitalSignatures and Public-Key Cryptosystems, Communications of the ACM, 21(2): 120-126,February 1978.

[19]. \"Glossary: chosen plaintext attacks\

http://www.rsa.com/rsalabs/faq/html/glossary.html, RSA Laboratories.

[20]. National Institute of Standards and Technology (NIST). FIPS Publication 186,Digital Signature Standard (DSS), U.S. Department of Commerce, May 1994.[21]. The Java Tutorial, A Practical Guide for Programmers, Published at

http://java.sun.com/docs/books/tutorial/index.html, Sun Microsystems, May 28, 1999.

[22]. JavaTM Cryptography Architecture API Specification & Reference, Published athttp://java.sun.com/products/jdk/1.2/docs/guide/security/CryptoSpec.html#Introduction,Sun Microsystems, October 30, 1998.

[23]. JavaTM Cryptography Extension 1.2 API Specification & Reference, SunMicrosystems, July 21, 1998.

[24]. George Coulouris, Jean Dollimore, and Marcus Roberts, Role and Task-basedAccess Control in the PerDis Groupware Platform, 3rd ACM Workshop on Role-BasedAccess Fairfax VA 1998 1-58113-113-5/98/10.

[25]. NIST FIPS 180-1 at http://www.nist.gov/itl/div897/pubs/fip180-1.htm.[26]. NIST FIPS 46-2, Data Encryption Standard.

[27]. On-line document published at http://www.rsa.com/rsalabs/, RSA Laboratories, Inc.[28]. Brian Jepson and David J. Hughes, Official Guide to MiniSQL 2.0, Wiley ComputerPublishing, 605 Third Avenue, New York, NY 10158-0012, 1998.[29]. On-line document published at

http://www.oracle.com/database/trusted/html/chapter1.html, Oracle Corporation.

[30]. On-line document at

http://www.microsoft.com/MSJ/0599/security/security0599top.htm, Microsoft SystemJournal, May 1999.[31]. On-line document at

http://www.novell.com/documentation/lg/nw5/docui/index.html, Novell, Inc[32]. OpenVMS documentation published at

http://www.openvms.digital.com:8000/72final/5929/5929pro.html, Digital EquipmentCorporation.

[33]. R. Rivest, The MD5 Message-Digest Algorithm, RFC 1321, Network WorkingGroup, April 1992

[34]. Hyun Park, Randy Chow, Internetwork Access Control Using Public KeyCertificates, Information Systems Security, Facing the information society of the 21stcentury, Chapman & Hall, 2-6 Boundary Row, London SE1 8HN, UK. 1996, pp237-246[35]. Johab S von Solms, Martin S Olivier and Sebastiaan H von Solms, MoFAC: AModel for Fine-grained Access Control, Information Systems Security, Facing theinformation society of the 21st century, Chapman & Hall, 2-6 Boundary Row, LondonSE1 8HN, UK. 1996, pp295-305

[36]. Online published at http://www.zdwebopedia.com/Programming/three_tier.html,ZD Webopaedia, 1999

Vita

Haiyuan Wang received her B.S. and M.S. in Department of ElectricalEngineering from Xi'an Jiaotong University, China in 1992 and 1995. From 1995 to1996, she worked as an Engineer at the No. 41 Institute of China Aerospace Ministry.

She joined the Virginia Tech Information System Center (VISC), Virginia Tech inJanuary of 1998 as a graduate research assistant. While doing research in the VISC lab,she became interested in network-based application design and development. Aftergraduating from Virginia Tech, she will work as a Software Engineer to develop anddesign Java-based applications.

因篇幅问题不能全部显示，请点此查看更多更全内容

查看全文

全部栏目

Security Architecture for the TEAMDEC System By