Citation
REGISTRATION AND AUTHENTICATION PROTOCOL FOR OCEAN:(OPEN COMPUTATION EXCHANGE AND AUCTIONING NETWORK)

Material Information

Title:
REGISTRATION AND AUTHENTICATION PROTOCOL FOR OCEAN:(OPEN COMPUTATION EXCHANGE AND AUCTIONING NETWORK)
Copyright Date:
2008

Subjects

Subjects / Keywords:
Application programming interfaces ( jstor )
Authentication ( jstor )
Cryptography ( jstor )
Data encryption ( jstor )
Data security ( jstor )
Java ( jstor )
Keys ( jstor )
Network security ( jstor )
Oceans ( jstor )
Software ( jstor )

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright the author. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Embargo Date:
8/8/2004
Resource Identifier:
51563753 ( OCLC )

Downloads

This item is only available as the following downloads:


Full Text

PAGE 1

REGISTRATION AND AUTHENTICATION PROTOCOL FOR OCEAN: (OPEN COMPUTATION EXCHANGE AND AUCTIONING NETWORK) By NITIN CHAWLA A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2002

PAGE 2

Dedicated to my mom and dad.

PAGE 3

ACKNOWLEDGMENTS I would like to express my gratitude to Dr. Michael P. Frank for giving me an opportunity to work on his research project. I would also like to thank him for his continuous guidance and encouragement throughout my thesis. I am very thankful to him for his constant feedback and support during the thesis writing. I would like to thank Dr. Tim Davis and Dr. Janise McNair for serving on my supervisory committee. I would like to thank my best buddies Erwin Jansen, Adrian Mascarenhas, Sapanpreet Singh Anand, Manish Malik, Rebecca Ferguson, Rima Gerhard and Michael J. Procopio for their support and expert advice throughout my graduation. I also thank Vijay Manian, Gargi Mahadeb Sur and all members of my research group for sharing their ideas. I would especially like to thank my parents for their love and support, without which nothing could have been possible. iii

PAGE 4

TABLE OF CONTENTS page ACKNOWLEDGMENTS.................................................................................................iii LIST OF TABLES.............................................................................................................vi LIST OF FIGURES..........................................................................................................vii ABSTRACT.......................................................................................................................ix CHAPTER 1 INTRODUCTION............................................................................................................1 1.1 Introduction...............................................................................................................1 1.2 OCEAN.....................................................................................................................2 1.2.1 An Overview...................................................................................................2 1.2.2 Related Projects...............................................................................................3 1.2.3 Security in OCEAN.........................................................................................4 1.3 Structure of the Thesis..............................................................................................6 2 OCEAN ARCHITECTURE.............................................................................................7 2.1 An Overview.............................................................................................................7 2.2 OCEAN Grid – Neutral Architecture.......................................................................9 2.3 Node Architecture...................................................................................................11 2.4 Current Status..........................................................................................................16 3 SECURITY CONCEPTS................................................................................................17 3.1 Introduction.............................................................................................................17 3.2 Security Goals.........................................................................................................18 3.3 Security Levels........................................................................................................19 3.4 Terminologies and basic concepts..........................................................................22 3.5 Attacks....................................................................................................................32 3.5.1 Classification of Attacks...............................................................................33 3.5.2 Attacks on Encryption schemes....................................................................34 3.5.3 Attacks on Protocols.....................................................................................34 3.6 Mobile Agent Concepts..........................................................................................35 3.6.1 Types of Agents............................................................................................36 3.6.2 Security Issues in a Mobile Agent System....................................................36 iv

PAGE 5

3.6.3 Techniques for Preventing Malicious Code..................................................37 3.6.4 Techniques for Protecting against a Malicious Host.....................................40 4 JAVA SECURITY..........................................................................................................43 4.1 Evolution of Java Security......................................................................................44 4.1.1 JDK 1.0 Security – Sandbox Model..............................................................44 4.1.2 JDK 1.1 Security – Trusted Code Model (All or Nothing)...........................44 4.1.3 JDK 2 Security – Fine-Grained Security......................................................45 4.2 Java Security Features.............................................................................................47 4.2.1 Language Features........................................................................................47 4.2.2 Java Virtual Machine....................................................................................48 4.2.3 Java Packages................................................................................................49 4.3 Java Pitfalls.............................................................................................................51 5 PROTOCOL DESIGN....................................................................................................53 5.1 Registration Procedure............................................................................................54 5.1.1 Assumptions..................................................................................................55 5.1.2 Registration Steps.........................................................................................56 5.1.3 Credibility of the Registration Protocol........................................................62 5.1.4 Risk...............................................................................................................63 5.2 Login Module..........................................................................................................63 5.2.1 Features of the Login Module.......................................................................64 5.2.2 How Does the Login Module Work?............................................................65 5.3 Key agreement protocol..........................................................................................69 5.3.1 Diffie-Hellman Protocol................................................................................70 5.3.2 Station-to-Station Protocol............................................................................72 5.3.3 Attacks on the STS protocol.........................................................................74 5.3.4 OCEAN-STS protocol..................................................................................76 6 CONCLUSIONS AND FUTURE WORK.....................................................................79 6.1 Conclusions.............................................................................................................79 6.2 Future Work............................................................................................................81 LIST OF REFERENCES...................................................................................................82 BIOGRAPHICAL SKETCH.............................................................................................85 v

PAGE 6

LIST OF TABLES Table page 5.1 Notations......................................................................................................................54 5.2 Keywords.....................................................................................................................57 vi

PAGE 7

LIST OF FIGURES Figure page 2.1 The OCEAN System......................................................................................................8 2.2 OCEAN Grid-neutral architecture...............................................................................10 2.3 OCEAN Node Architecture.........................................................................................12 2.4 Naming System............................................................................................................15 3.1 Key Agreement Protocols............................................................................................26 3.2 Passive Attacks............................................................................................................33 3.3Active Attacks...............................................................................................................34 3.4 A Mobile Agent...........................................................................................................36 3.5 Security Issues and Solutions in a mobile agent system..............................................39 4.1 JDK 2 Security Architecture........................................................................................46 4.2 Java Security Components...........................................................................................50 5.1 Communication between the clients and the servers (Accounting and Authentication server)..........................................................................................................................55 5.2 The Client Side information.........................................................................................58 5.3 Protocol for registration and creation of a digital certificate.......................................59 5.4 The Server Side Information........................................................................................62 5.5 Location of the Login Information..............................................................................65 5.6 User’s information for different scenarios...................................................................66 5.7 Retrieving login information from the authentication server......................................68 5.8 Diffie-Hellman key agreement protocol......................................................................70 vii

PAGE 8

5.9 STS-MAC protocol......................................................................................................72 5.10 STS-ENC protocol.....................................................................................................73 5.11 Revised STS-MAC protocol......................................................................................75 5.12 OCEAN-STS MAC protocol.....................................................................................77 viii

PAGE 9

Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science REGISTRATION AND AUTHENTICATION PROTOCOL FOR OCEAN: (OPEN COMPUTATION EXCHANGE AND AUCTIONING NETWORK) By Nitin Chawla August 2002 Chairman: Dr. Michael P. Frank Major Department: Computer and Information Science and Engineering A few decades back, computers were rare and expensive. Now, CPU time is so cheap that a vast amount of potential computing capacity remains untapped. Conversely, there are many individuals and organizations that have intense computations to perform, but only have access to limited and restricted resources with which to execute them. The OCEAN (Open Computation Exchange and Auctioning Network) is a major ongoing project at the University of Florida's Computer and Information Science and Engineering Department to develop a fully functional infrastructure supporting the automated, commercial buying and selling of dynamic distributed computing resources over the Internet. Applications within OCEAN can purchase and utilize remote distributed computational resources on demand, while compensating the providers of these resources via a free-market mechanism. Achieving this goal is non-trivial due to factors such as resource heterogeneity, cooperation among heterogeneous platforms, ix

PAGE 10

distributed ownership, wide geographic distribution, varying traffic/reliability/availability conditions, and security. Security in distributed computing deals with the whole range of security issues because accessing decentralized resources means operating in an environment with an untrusted and possibly hostile network. Securing information from unauthorized access in an efficient manner is one of the major problems for any network. The focus of this thesis is to provide a strong basis for authentication, confidentiality and integrity of valuable information exchanged in OCEAN. In this thesis, I will discuss various issues related to mobile code and the existing solutions. I will also talk about the key agreement protocol, the login module and the registration protocol that I have designed. The registration protocol is used to register the users with an authentication server and satisfy an assumption of the key agreement protocol, that before exchanging keys, a user should have his own public-key certificate. The login module authenticates a user (locally) and allows him to access the OCEAN application and deploy jobs on remote machines. I have also modified an existing key agreement protocol to increase the lifetime of shared secret keys. x

PAGE 11

CHAPTER 1 INTRODUCTION 1.1 Introduction Proliferation of workstation-class processors and growth of high-speed networks has made Internet computing pervasive worldwide. Most of the time computers are not involved in any computation intensive tasks, but only tasks like word processing and browsing the Internet, which do not consume much of the available computing power. In many organizations the total computing power may often be severely under-utilized, especially outside of peak business hours, whereas operators of massively parallel applications and services may have trouble in procuring the resources they need, especially if their level of resource utilization over time is huge and highly variable. This overwhelming disparity in resource utilization induced the development of cluster and grid computing paradigms. The key to these high-performance computational frameworks is effective management and exploitation of all available computing resources. These infrastructures, often known as metacomputing systems, transparently integrate geographically distributed resources to provide coordinated resource sharing. The concept of resource sharing is not simply restricted to file exchanges, but rather direct access to computer resources, e.g., memory, CPU, I/O devices, which belong to multiple institutions and organizations. Hence, the need arises for collaborative problem solving and resource brokering strategies. The computing world can potentially be revolutionized if systems can transparently buy, sell, and use remote computing resources via the Internet. The vision is to greatly increase the overall efficiency of the world’s 1

PAGE 12

2 utilization of computing resources, thereby leading to increased productivity. For example, the computing capacity of a large organization may be largely unused overnight. If connected to a grid, that dormant power could be tapped by an unrelated company on the other side of the globe for a variety of tasks. In return, the organization might be given access to extra capacity during its own peak hours. 1.2 OCEAN 1.2.1 An Overview OCEAN (Open Computation Exchange & Auctioning Network) is a major ongoing project [1] at the University of Florida's Computer and Information Science and Engineering department. The OCEAN project was started by a group of MIT students and Stanford alumni in 1997; in 1999 it moved, along with its founder's career, to the University of Florida. OCEAN aims to develop a fully functional infrastructure supporting the automated, commercial buying and selling of dynamic distributed computing resources over the Internet, e.g., CPU time, associated memory usage. The major components of such a market are its users, the computational resources and tasks associated with them, and the underlying market mechanisms that facilitate trade. A user is actually a programmed agent acting on behalf of a human user. Users of computational markets may take the roles of buyers or sellers. The sellers are compensated for the resources they provide and the buyers are able to perform the task without purchasing expensive hardware. A buyer prepares the resource requirements, with the maximum price it can bid. On the other side, a seller prepares a resource offer indicating the minimum price it will accept for the use of its resources. Once a match is found, by the auctioning system,

PAGE 13

3 between a buyer and a seller, then they negotiate to finalize the deal. After signing a contract, the buyer sends a job (and associated data) to the seller’s machine for the computation and wait for the results. The role of OCEAN is to provide an environment in which these interactions may take place in an automatic way. 1.2.2 Related Projects There are many grid projects worldwide, which provide infrastructures for distributed computing. A more complete listing can be found in Rajkumar Buyya’s website [2]. Globus [3] enables users to combine nearly any set of distributed resources into one integrated metacomputing workbench to allow users to run distributed applications, e.g., global climate modeling. Most of the projects [2] currently lack a market mechanism to compensate resource providers, which in our view severely limits the growth of their installed-base of deployed servers. In contrast, OCEAN provides an automated, open market for selling and buying of resources. Entropia [4] and Parabon [5] are examples of ventures that do sell distributed computing resources, but they are closed markets (controlled by these companies), and often may not give the best possible compensation to the resource provider. They also typically present a high barrier to entry to application developers, in terms of not providing a free, open, standard API that any developer can target and test at will. These systems are also much less flexible than OCEAN, since resource usage must be typically contracted (with human interaction) in advance, and cannot be purchased on-demand dynamically by arbitrary applications. They are also less scalable than OCEAN, because of the centralized nature of their resource management, as contrasted with OCEAN's peer-to-peer distributed auction system.

PAGE 14

4 Out of all the current projects we know about, the Economy Grid [6] and Compute Power Market (CPM) [7] are projects of Rajkumar Buyya and colleagues, are the most similar to the OCEAN in their goals and spirit. However, even these projects currently lack an auction mechanism to set prices. Further versions of OCEAN, will be designed to interoperate with these systems. 1.2.3 Security in OCEAN The main focus of my thesis is the security subsystem of the OCEAN project. Security is an important issue in OCEAN for the deployment of applications based on software agent technology. There are numerous security issues [8] in a mobile agent system. In OCEAN, the following security issues have to be dealt with carefully: Securing the host machine. A mechanism should be provided to protect the host’s data (e.g., credit card and other critical information), and resources against a malicious agent who may be using authorized access in disruptive fashion. Ideally, it should ensure that an agent should not be able to exploit more than the agreed-upon amount of resources. A host should be reimbursed for utilizing the resources by the originator of an agent. An agent should not be able to use the host resources to commit other crimes like sending bogus messages to launch denial of service attacks on other hosts. In this thesis, I will be focusing on mutual authentication of clients before exchanging messages, and also confidentiality and integrity of the information exchanged. Securing an agent. An agent should be able to maintain confidentiality and integrity of its data, at all times. Ideally, the host should not be able to extract information from an agent, or corrupt or modify its state, harming its functionality. An agent should not be able to access or modify information from other agents or interfere with them. The

PAGE 15

5 flow of execution of the agent should not be altered while it is executing. These issues are left for future work. As OCEAN involves electronic commerce (buying and selling of resources), a security mechanism should fulfill the following security requirements: 1. A host offer should not be readable by other hosts (depending on the type of auction). It should not be possible for hosts to modify offers or add false offers without being detected. A lot of research [9] is going on for signing the information (e.g., a contract or an offer or a bid) in a XML document. The agent should be able to give selected sensitive information to the host in order to make a purchase, being assured that the information is not disclosed to third parties. The owner of the agent should get the asset bought and a receipt is issued as proof of the purchase. Transaction of money with the financial networks should be done securely. 2. A mechanism should also be provided to prevent falsifying any transactions or information while negotiating a contract e.g., false account or credit card information. The systems should authenticate clients before sending an agent or finalizing a contract. An unauthorized user should not be able to deploy agents or sell resources. The system should also ensure integrity and confidentiality of the information exchanged between the clients. To exchange messages securely, a client should have a public key certificate, a session key (to encrypt and decrypt messages) and a unique ID (for identification). I have designed a registration protocol in which a user can register with an authentication server and retrieves a public-key certificate and a unique ID. I have also designed a login module in which a user is authenticated (locally) and is allowed to access the OCEAN application to deploy mobile agents. I have also proposed a modification in an existing protocol, to exchange secret keys (symmetric) and commence a secure communication. There are a few existing protocols that provide a mechanism to exchange secret keys, for a secret communication between two clients. Some protocols involve a server to exchange the secret keys, and others do not involve a server. It is very important to minimize communication with the server; otherwise the server can be a performance

PAGE 16

6 bottleneck and also a single point of failure. I have chosen a protocol called “Station-toStation protocol,” which is a key agreement protocol and added more functionality in it, to extend the lifetime of the shared secret ke y between the clients and also to prevent a clogging attack . 1 The registration protocol fulfills an assumption of the “Station-toStation” protocol that before exchanging secret keys, each client should has its own public-key certificate. 1.3 Structure of the Thesis In this section I will briefly describe the contents of each chapter. In Chapter 2, I will give an overview of the OCEAN project; discuss its architecture and its current status in detail. Chapter 3 defines what exactly we mean by “security.” In this chapter, I will give an introduction to the basic security concepts, definitions and terminologies commonly used. In the end of this chapter, I will discuss various security issues related to mobile code and existing solutions to prevent malicious behavior of either a host machine or an agent. In Chapter 4, I will discuss the evolution of security in Java, its security features and pitfalls. In Chapter 5, I will discuss the design of my protocols in detail. Firstly, I will discuss the registration protocol, then I will talk about the purpose of the login module and its design. Finally, I will give an overview of the “Station-to-Station” protocol and its functionality. Chapter 6 discusses the pros and cons of the protocols I have designed and the future work. 1 In this attack, an opponent requests a high number of keys. The victim spends considerable resources doing useless modular exponentiation rather than real work. This can be considered as a type of denial-of-service attack.

PAGE 17

CHAPTER 2 OCEAN ARCHITECTURE 2.1 An Overview The name OCEAN is an acronym for "Open Computation Exchange and Arbitration (or Auctioning) Network." The purpose of the OCEAN is to provide a worldwide automated commodities market for the on-demand purchase and remote usage of computing resources (such as CPU cycles, memory, disk space, network bandwidth, access to specialized remote resources) by distributed applications and mobile agents. The main goal of the OCEAN is to make it as easy as possible for users to deploy OCEAN server nodes and to develop and run OCEAN applications at will. It aims to implement the total automation of distributed computation in such a way that anyone can sell or buy the resources [10] to harness a large amount of idle computational power. The OCEAN system attempts to address scalability by implementing a distributed, peer-to-peer based architecture. The OCEAN software system, developed in the Java programming language, is packaged as a single unit, and can be installed on any computer with a Java Virtual Machine (JVM), thereby causing the machine to become a node in the Network. Any node can perform more than one task at a time, e.g., hold an auction, execute a buyer's computation, serve as an application development environment, or as an application launch pad. In OCEAN, an agent acts on behalf of the user. If a user wants to deploy a job, which requires more resources, the agent will contact the auctioning system (local or remote) and search for the desired resources (remote). The auctioning system may 7

PAGE 18

8 contact other auctioning servers to find a best possible match of the required resources. Once a match is found then the negotiation will commence between the seller and the buyer of the resources. After the negotiation is completed (a contract between the two parties has been signed), then the agent will deploy the mobile code to the destination, where the mobile code can run and send results back to the launch point as needed. The seller will be paid, after or before or during the execution of the job, on the basis of the agreed-upon contract. Figure 2.1 The OCEAN System The high level interactions among nodes in the OCEAN system are depicted above in Figure 2.1. As can be seen from the figure, all nodes are connected to one Centralized Accounting Server Financial N etworks Auction Node Firewall/ OCEAN Proxy Application Launch Point Private Intranet ServerNode Authentication Serve r Application Launch Point Public Internet Auction Node and Application Launch Point Auction Node

PAGE 19

9 another in one of two ways. Either they are connected directly via the Internet, or indirectly through a node that operates as a gateway to other nodes in an intranet behind a firewall. Note that specific types of node indicate the role that each one is playing at a given point in time. For example, a node that is acting as an auction server at some point in time can act as a server performing a computation at another time, or both simultaneously. The only exception to the completely distributed nature of the OCEAN system is the presence of the centralized authentication server, which also keeps account information of all clients in a network. 2.2 OCEAN Grid – Neutral Architecture The OCEAN infrastructure is based on a novel multi-layered architecture, as shown below in Figure 2.2, which provides scalability and extensibility over various grid architectures. OCEAN services. It provides various services to other grid infrastructures, e.g., resource discovery, resources auctioning, negotiation, payment and accounting. Various grid-based applications can invoke these services to acquire and share distributed resources. Runtime platforms. Technologies like .Net / Java provides a high degree of hardware and operating system portability. They ease the process of creating and deploying mobile agents. Grid and mobile agent environments. This environment provides solution to basic issues, such as transfer of code and data between different entities, and communication between distributed components of an application. However, OCEAN is designed to be compatible with these technologies. We are developing a simpler version

PAGE 20

10 of mobile agent environments like Globus [3] and MPI [11] are the OCEAN grid environment API. Runtime platforms OCEAN Services Resource Auctioning Peer Discovery Contract N egotiation Payment and Accounting OCEAN Grid Environment API Code Mobility and Secure Communications Mobile agent applications and servers OCEAN-only applications and servers Globus Application and Servers MPI-based applications and servers Globus Toolkit Java VM . NET CLR MPI Library Grid and mobile agent server/applications Grid and Mobile agent environments C-based platforms Legion Toolkit Tryllian ADK platform Ocean reference implementations in Java Figure 2.2 OCEAN Grid-neutral architecture Grid and mobile agent server/applications. There are various technology-specific applications, which consume resources and compute servers, which provide resource to the grid. But, from within any of the grid environments, developers will be able to access any desired features of OCEAN’s infrastructure for auctioning of the resources, negotiating a deal, discovering the potential resource providers (peer-to-peer) and reimbursing them. So, OCEAN can then be used as a huge automated clearinghouse for distributed resources, which can then be utilized by applications using any grid technology. The

PAGE 21

11 resource auctioning process will automatically match jobs to servers that provide the grid technologies that the application requires. 2.3 Node Architecture As shown below in the figure 2.3, there are three external APIs: the Trade Proposal API, the API for the programmer and the Node Configuration and Operation API. These APIs provide human traders and computer agents, a mechanism to interact with the OCEAN node software and the system. Trader API. This API allows a user to specify all trading details like resources being offered or requested, price of the resources, negotiation policy and so on. Application programmer interface. A programmer can use these API’s to create an OCEAN-enabled application. Node configuration and operation API. This API allows a user to change the configuration of a node, e.g., security parameters, trading mechanism. In the OCEAN software there are many components, which work together to achieve the desired goals. They are the following: Trader component. This component acts as an interface between the users and the OCEAN system. The Trader component acts on behalf of a user, which communicates with the Negotiation, Auctioning, and Task Spawning and Migration components. Auctioning component. The main focus of the auctioning process (aided by the Negotiation System) is to match traders with the best possible trading partners. For buyers this means finding sellers who not only offer the best prices, but also provide the resources that closely match buyer’s requirements. For sellers, the Auctioning system is responsible for finding the highest paying buyers, without exceeding the resource

PAGE 22

12 capabilities of the seller. It has been noted that the trade proposals in a computational market can be complex. The buyer may have strict requirements regarding hardware and software resources that must be satisfied. In order to handle the complexity of trade proposals, expressive data description languages were developed in the Extensible Markup Language, or XML [10]. Communication Security Naming Negotiation Task Spawning & Migration Auctioning PLUM Trader OCEAN Node Trade Proposal API Application Programmer API Node Configuration & Operation API Node Node Internet Central Accounting System OCEAN Node Architecture Local Accounting OCEAN Grid Environment API OCEAN Services OCEAN Application API Figure 2.3 OCEAN Node Architecture Authentication / Accounting Server Scheduli Other OCEAN node Other OCEAN node OCEANAPI

PAGE 23

13 When the auctioning system needs to communicate with the auctioning systems of other nodes, it does so with assistance from the Peer List Update Manager (PLUM) and Security components. Peer list update manager component (PLUM). In a distributed system such as the OCEAN auction, it is impractical for nodes to communicate with all others simultaneously in a broadcast fashion. Instead, they must communicate with a selected few peer nodes. It is the responsibility of the PLUM [12] component to determine a list of peer nodes with which a node will communicate. The PLUM maintains a list of addresses of other OCEAN nodes (peers) that it knows about, and associated status information about that node (e.g., present & average accessibility, availability, intercommunication bandwidth & latency). Based on the node administrator's preferences, the PLUM periodically updates its peer list. Negotiation component. Once the Auctioning component determines the potential trading partners then the Negotiation component negotiates with the traders and finalizes the deal (signs a contract). It also resolves conflicts, when a trader has many potential trading partners and tries to automate the process of negotiation. Once an agreement is reached then it contacts the Task Spawning and Migration component to migrate the job. It uses the security and communications components for communicating with the other nodes. Task spawning and migration component. The Task Spawning and Migration (TSM) component is responsible for the proper distribution and execution of the jobs in the Network. After the contract is signed, the TSM component will spawn computing

PAGE 24

14 tasks on remote servers through the Security and Communication layers at each node and execute them. Security component. Security is a major concern in computational markets. Communicating parties should have confidence in the integrity of the documents and the information exchanged. Information like keys, certificates have to be securely stored. This component has to make sure that only authenticated code should be allowed to execute on the remote machine and also restrict the malicious behavior either by the host machine or by the remote code. The security system offers various levels of security, which can be configured by the Node Configuration and Operator API depending on the quality of service required. In this thesis I will be discussing login module, which authenticates a user (locally) and controls an access to the OCEAN application. I will also discuss the registration protocol, which is used to register a user to an authentication server, and a modified mutual authentication mechanism to exchange a secret key to commence a secure communication between two clients. Communication component. The Communication Component is responsible for communication between the OCEAN nodes. The component is primarily responsible for data delivery to the other OCEAN node(s). The communication component can be configured through the Node Configuration / Maintenance / Operation Interface. All information received by the communication component is sent to the security component for verification, before passed to any other component. Naming component. The Naming component is responsible for name resolution of a node in the Network. The Communication component relies heavily on this

PAGE 25

15 component. As we know that IP addresses can change and can be obscured by firewalls and private IP address spaces. Names of OCEAN entities are syntactically defined as extensions to the URL/URI standard. Any resource or process can be located with a URL. This is achieved by using a path-naming scheme as show in figure 2.4: ocean://: /: /.(any additional hosts on private sub-subnets). /@/ Figure 2.4 Naming System Local accounting. Each node uses the Local Accounting component to communicate with the centralized accounting server. When contracts are successfully negotiated, the Local Accounting component will log the payment details locally. Once the resources are consumed, the transaction is logged to the Central Accounting server. Centralized accounting server. It is also known as authentication server, which registers the users and keeps track of the client’s certificate and their private information for verification. In addition to this, it also logs transactions of the business that occurred between the buyer and the seller. Every user registers with the CAS to have an account before commencing any activity. The CAS accrues micro-payments each time a successful transaction takes place, without accessing the external financial networks. This account information is used to make real world transactions with the existing financial networks to debit or credit the traders, periodically or when the balance in the trader’s account exceeds a particular limit.

PAGE 26

16 2.4 Current Status Currently OCEAN is being implemented as a standalone system, using extreme programming approach. The initial reference implementation is being developed in Java platform. The team members are also exploring the possibility of developing the source code for the .NET platform in the near future to ensure compatibility with larger number of applications. In this semester, we planned for three iterations and in the first iteration we have implemented and integrated communication and task migration components. Right now, we are in the second iteration in which we are designing and implementing the negotiation and auctioning components. In the third and the final iteration, we will be focusing on the financial transactions between clients, the client and the server, and between the server and the financial network. We intend to complete the prototype implementation and release a beta version of the software for public testing by the end of the third quarter of 2002. Another important research approach is porting the OCEAN Services Layer to different middleware technologies such as Globus. Globus provides basic mechanisms such as communication, authentication, network information, and data access for building metacomputing grids. It also provides APIs in C, CC++ (Compositional C++ a parallel extension to C++) and Java (known as NexusJava) to develop metacomputing applications.

PAGE 27

CHAPTER 3 SECURITY CONCEPTS 3.1 Introduction Computer systems can never have absolute security in real life. They exist to be used; not to be admired in a locked room sealed away from the outside world. Security is the most important and necessary assurance requirement to consider when deploying a system. Security, in a broad sense, focuses on network, system, information, and physical security. Traditionally, security for stand-alone computers and small networks was handled by physical security and by logging into computers and domains. With open networks like the Internet and distributed computing paradigms including peer-to-peer (P2P), issues concerning security and trust become crucial. Internet P2P applications are built out of computers that do not trust each other, and to succeed, they must operate as part of an untrusted and hostile network. Security is an important issue for the widespread deployment of applications based on software agent technology. In this chapter, I will discuss the following: 1. Security goals. 2. Different levels of security. 3. A few basic concepts and definitions used in security. 4. General attacks, classification of attacks, attacks on encryption schemes and on the protocols. 5. Concepts of a mobile agent, security issues related to mobile agents and the proposed solutions. 17

PAGE 28

18 3.2 Security Goals When we refer to attacks, it is necessary to define what we are trying to protect and against what. The resources that we want to protect are reputations, processes, files and data in transit, and the reputations of the entities providing and using these resources. For such resources, the main security elements are: Authentication. It ensures that the origin of a message or electronic document is correctly identified, with an assurance that the identity is not false. Authentication can be one-way or two-way. In one-way authentication, the user is authenticated to the application or to other user, but not vice-versa. In two-way authentication both users (or the user and the application), authenticate each other. Secrets like passwords or digital signatures are used to authenticate a user. Authorization. It is the process of assigning access rights to each user. The access rights include a specification, such as whether the user is permitted to read, write, or update a given file or any other resource. Access control. It pertains to the process of enforcing access rights for resources. It grants or denies permission to a given user for accessing a resource and protects resources by limiting access to only authenticated and authorized users. Availability. It requires that computer system assets be available to authorized parties when needed. Access control, redundancy, fault tolerance, monitoring, priority mechanisms, and scheduling are used to ensure availability of assets. Confidentiality. It is the process used to protect secret information from unauthorized disclosure. Data has to be protected when it is stored or when it is being transmitted over the network or when it is in memory. To preserve confidentiality,

PAGE 29

19 encryption and access control are generally used. The task of implementing encryption also requires secure distribution of the keys. Nonrepudiation. It requires that neither the sender nor the receiver of a message be able to deny the transmission and that neither party to an agreement to be able to deny making the agreement. It is the capability to provide proof of the origin or delivery of data. Digital signatures and trusted third parties are used to prevent someone denying a transaction or some activity. Integrity. It ensures that only authorized users are able to modify the system assets or transmitted information. It detects unauthorized modification of data, which may be due to an attack or error. It is often accomplished by using a one-way hash function. Access control, consistency checking, integrity checks, message authentication codes (MAC) and concurrency control are other tools to ensure the integrity of information. In my thesis, I will be addressing the authentication of users both locally and remotely, and the confidentiality and integrity of information exchanged. 3.3 Security Levels There are four general levels of data security concerned with potential threats: Physical (including hardware) Operating system-level Communications Procedural Physical security. Most physical security is concerned with keeping equipment locked up, proper passwords implemented and enforced, and keeping unauthorized people away from local network resources. Essential elements of physical security are

PAGE 30

20 theft prevention, tampering avoidance, and containment of signals that can be monitored. Even within subordinate areas like hardware security, there are differences between hardware containment to prevent physical theft and hardware containment to prevent tampering or inadvertent misuse. Assuming one has effective physical security, the next threat to system integrity is unauthorized access to the network itself. This threat can be depicted in two areas: those seeking access from outside, and those seeking access to the network from inside. For someone with access to the network hardware (inside access), there are three areas of possible network attack: 1. Hardware attack where someone attaches a device to the network to gather and siphon off data 2. Software attack where workstation modules operating systems, Terminate-and-stay-resident programs (TSRs), and application software are modified to gather data from the system and save it for later retrieval or to deny data or network access e.g., Trojan horses, packet sniffers. 3. Masquerade attack where the perpetrator uses the identity of an authorized user to obtain access to the network Operating system-level security. Any multi-user operating system performs several functions that are related to security, which are the following: 1. Authentication of users: The operating systems identify each user who requests access and ensures that the user is actually who he or she purports to be. 2. Protection of memory: They do not allow unauthorized access to protected memory. Generally protection is achieved by a mechanism based on paging or segmentation. 3. File and I/O device access control: The operating system protects user and system files from unauthorized users. It generally uses an access control matrix1 or permission groups to achieve this control. 1 An access control matrix is a table in which each row represents a subject, each column represents an object, and each entry represents access rights for that subject to that object.

PAGE 31

21 4. Allocation and access control to general objects: The operating system permits concurrency and allows synchronization. 5. Enforcement of sharing: It guarantees integrity and consistency of shared resources. 6. Guarantee of fair service: The operating system ensures that no user is starved from receiving service. 7. Protections of operating system protection data: It also maintains data by which it can enforce its security policy. Communications security. Communications is another area of security concern, which primarily consists of two types of attack, tapping and spoofing. 1. Tapping is similar to hardware attack except that it can be done externally. It provides a high risk for any system using wire communications. 2. Spoofing is pretending to be a server or a peer. It requires detailed knowledge of the system, and may be part of an insider attack. A software or hardware component is used to spoof other servers, clients, or users into believing that the software is a valid component of the communications process. Like the client Trojan horse, the spoofing software can gather information without the end-users or servers knowing. Procedural security. Procedural security takes its name from a concern for procedures mounting the wrong media, booting the wrong software, or doing anything else out of the norm. For procedural security to be effective, you must have a well-defined and workable security policy implemented. Besides defining the proper security measures that need to be implemented, you must provide implementation methods that can be achieved with a reasonable amount of effort. You must also provide plans for security implementation for each and every network function that takes place in your environment (such as creating users, adding new resources, providing resource access, and so on). Implementing a successful security policy requires that one should provide adequate controls for assuring that your security policy is being implemented and

PAGE 32

22 enforced. When defining basic procedural security, one should consider the following issues: 1. How software is installed 2. How the system is administered 3. How user rights and privileges are administered 4. How the system is restored 3.4 Terminologies and basic concepts The study of any discipline must be built upon definitions arising from fundamental concepts. What follows is a list of terms and basic concepts [13] used in the subsequent chapters. Definition 1: Symmetric encryption uses a shared key for both encryption and decryption of information. One of the advantages of symmetric encryption is that it is very fast. The main problem with this approach is that the key needs to be shared by both the sender and the recipient of the information. If someone else obtains the key, they can decrypt the message. Symmetric encryption provides confidentiality, but not authentication or non-repudiation. Definition 2: Asymmetric encryption is a cryptographic system that uses two keys-a public key known to everyone and a private key known only to the recipient of the message. An important element to the public key system is that the public and private keys are related in such a way that only the public key can be used to encrypt messages and only the corresponding private key can be used to decrypt them. Moreover, it is virtually impossible to deduce the private key if you know the public key. The ideal use for this technology is for those cases when you need to share information but do not have to send a private or a secret key. The public key is used to encrypt a message, whereas the

PAGE 33

23 private key is used to sign a message. Asymmetric keys provide confidentiality, as well as authentication and non-repudiation when the roles of public and private keys are reversed. Definition 3: A key agreement protocol is a key establishment technique whereby two or more specified parties derive a shared secret key as a function of information contributed by, or associated with, each of these, such that no party can predetermine the resulting value. Definition 4: A protocol is said to provide explicit key confirmation (of B to A) if entity A is assured that the second entity B has actually computed the agreed key. Definition 5: A protocol is said to provide implicit key confirmation (of B to A) if entity A is assured that the second entity B can compute the agreed key. Definition 6: A key agreement protocol is said to provide implicit key authentication (of B to A) if entity A is assured that no other entity aside from a specifically identified second identity B can possibly learn the value of a particular secret key, unless B gives it away. This does not mean that A is assured of B actually possessing the key. Definition 7: A key agreement protocol is said to provide explicit key authentication (of B to A) if both implicit key authentication and (implicit or explicit) key confirmation are provided. Definition 8: A protocol offers perfect forward secrecy (PFS) if compromise of a long-term key(s) cannot result in the compromise of past session keys. Definition 9: A protocol is said to be vulnerable to known-key attack if compromise of session keys allows:

PAGE 34

24 1. A passive adversary to compromise keys of other sessions, or 2. An active adversary to impersonate one of the protocol parties. Definition 10: An unknown key-share attack is one in which an entity A ends up believing he shares a key with B, and although this is in fact the case, B mistakenly believes the key is instead shared with an entity AD . Definition 11: A one-way hash function H (x) = y, where x is an input and y is a fixed length output, has the following properties: 1. For any given code y, it is computationally infeasible to find x, even if H is one-to-one. 2. It is also computationally infeasible to find any pair (x, y) such that H(x) = H(y) and yx. 3. It is relatively easy to compute H (x), making it practical. Definition 12: In Password based encryption (PBE) [14] a password is combined with a salt to produce a key. The salt can be viewed as an index into a large set of keys derived from the password, and need not be kept secret. Although it may be possible for an opponent to construct a table of possible passwords (a so-called dictionary attack), constructing a table of possible keys will be difficult, since there will be many possible keys for each password. An opponent will thus be limited to searching through passwords separately for each salt. Definition 13: Message authentication code (MAC) involves the use of a secret key to generate a small fixed-size block of data, know as a cryptographic checksum that is appended to the message. When receiver receives the MAC, it performs the same calculation on the received message, using the same secret key, to generate a new MAC. If the received MAC matches the calculated MAC then, 1. The receiver is assured that message has not been altered.

PAGE 35

25 2. The receiver is assured that the message is from the alleged sender because no one else knows the secret key. 3. If the message includes a sequence number, then the receiver is assured of the proper sequence because an attacker cannot alter the sequence number. Definition 14: A key agreement protocol is contributory if each party equally contributes to the key and guarantees its freshness. For example, according to this definition, the basic two party Diffie-Hellman protocol [15] is contributory. On the other hand, the ElGamal one-pass [13] protocol is not contributory as only one of the parties contributes a fresh exponent. Definition 15: A Key establishment protocol is a process whereby a shared secret key becomes available to participating entities, for subsequent cryptographic use. It is broadly subdivided into key transport and key agreement protocols. They may use symmetric or asymmetric key cryptography. In key transport protocols, a key is created by one entity and securely transmitted to the other entity (non-contributory). In key agreement protocols, both entities contribute information to generate the shared secret key (contributory). Before securely exchanging messages, clients have to exchange secret keys to maintain confidentiality and integrity of the messages. We know that each client has a public-private key pair and its public-key certificate. The key establishment protocols provide a mechanism to exchange secret keys between clients either symmetrically or asymmetrically, and which may or may not involve a server. Key establishment protocols are categorized on the basis whether entities communicate directly or indirectly, cryptographic techniques involved. Figure 3.1

PAGE 36

26 categorizes different types of protocols with the example. Please refer to [16] for detailed description of the following protocols. Encryption Type Key Transport Key Agreement Figure 3.1 Key Agreement Protocols Cryptographic algorithms There are two categories of cryptographic algorithms: symmetric (conventional) and public/private key (asymmetric). Conventional cryptography, also known as symmetric cryptography, requires the sender and receiver to share a key, which is a secret piece of information used to encrypt and decrypt messages. Only those who have the key may read the message. A problem with this mechanism is that the sender and the receiver must choose a key before communicating in private. Symmetric algorithms like DES are vulnerable to attacks based on differential and linear cryptanalysis. Still DES is used in some places where cost of carrying out a DES attack outweighs the value of the information being protected.

PAGE 37

27 Public key cryptography solves the key exchange problem by defining an algorithm, which uses two keys, each of which may be used to encrypt a message. If one is used to encrypt the message, the other is used to decrypt it. This mechanism makes it possible to securely exchange information without worrying how to share a secret key. In public/private key infrastructure, one key is available publicly (public key) and other one is kept secret (private key). Data can be encrypted using either the public or the private key. The private key is used to create a digital signature, which is generated by applying one-way function to the message (message digest) and encrypt it by using the sender’s private key. The signature is verified by decrypting the data (message digest) using the public key of the sender. The data encrypted using a public key can be decrypted by only one who has the corresponding private key. The sender’s public key is used for authentication of the data, whereas, the receiver’s public key is used for confidentiality. Message digests A message digest is a one-way hash, which is used to create a short, fixed-length representation of a longer and variable length message. They are used as fingerprints for messages and have the following properties: 1. A message digest is designed to produce unique digests for different messages and makes it too difficult to determine the message from the digest. 2. It also makes it infeasible to find two different messages having same digest, which eliminates the possibility of substituting one message for another or modifying the original message. Message digests are used to support the following: 1. Integrity: To detect whether a message has been modified or replaced. 2. Authentication: To verify that a message or other object actually originated from a person or organization with a particular identity.

PAGE 38

28 3. Non-repudiation: To prevent someone from denying that he or she has sent a message or performed an operation on an object. Certificate classes Absolute certificates are logically impossible, as a certificate cannot certify itself. Currently, there are three standards for certificates: X.509, PGP and SKIP. A certificate is based on trust and keys; one can assign keys, but trust is earned, not assigned. Root level certificate Certificates require an issuer to assert the validity of the identity of the certificate subject, yet there must be a top-level certificate authority, which everyone trusts. In this case, the certificate is “self signed,” hence the issuer is same as the subject. The root authority must publish its public key widely. Certificate management There are various issues related to certificates, like validation period, renewing of the certificates, certification revocation lists (CRLs) lists of certificates that have been issued but are no longer valid, which have to be handled to ensure seamless operation when using certificates. All these operations are collectively termed as certificate management. X.509 There are two levels of authentication: 1. Using a password as a verification of claimed identity. 2. Involving credentials formed by using cryptographic techniques. It is the second level that defines a provision of authentication services, under a central control paradigm represented by a “directory.” Certification Authority (CA) [17] implements the “Directory,” which is governed by Certification Practice Statements

PAGE 39

29 (CPS) [18]. Each CA internally defines the CPS but it’s definition lies outside the scope of X.509. Basics of X.509 1. A user certificate has the public keys of a user with other information, rendered unforgeable by encipherment (signing) with the private key of the certification authority that issued it. 2. It allows an association between the “unique distinguishable name (DN)” of the user and the user’s public key. Whether a user’s DN corresponds to identity credentials that are linked to a person or simply to an email address is outside the scope of X.509. 3. A CA needs to be satisfied of the identity of a user before creating a certificate for it, which means that identity validation procedures are to be satisfied in the CA’s frame of reference by following the CA’s self defined rules (CPS). Some CA’s CPS’s can accept indirect references of “soft-trust” when issuing a certificate, which is a security risk. 4. X.509 does not intend to address either the level of effort that is needed to validate the information in a certificate, or the definition of a global meaning for that information outside the CA's management. The CA paradigm is thus, essentially, to rely on an authentication chain that ends in a CA that eventually certifies itself. Therefore, one weak link may compromise a whole chain of certificates. Some causes for a weak link are the following: 1. Most of the servers that use CA certificates force the client to accept the CA’s signatures, which are hardwired into the software. The trust decision from the beginning is removed from the client, which contradicts that the user should be central to the decision process in all steps. 2. The life of a certificate cannot be extended beyond the life of the certificate of the signing CA. The principle here is that after the expiration of the CA's certificate, one should assume that it might have been cracked (which is why they have finite lives in the first place). Anything signed by that key thereafter should be suspected of being a forgery. In other words, if someone presents a certificate today that was signed by a key linked to a certificate that expired last month, one should assume it might be a forgery. However, if the certificate was signed during the lifetime of the signing CA's certificate, one could assume that it was authentic (based on the principle that the private key had not yet been cracked). The trouble is, there is no way to ascertain from the certificate exactly when it was signed in relation to other lifetimes.

PAGE 40

30 3. Generally the lifetime of the certificates is only a few weeks as it depends on various factors [19]. This means more overhead, time and effort to renew the certificates and update information everywhere. 4. A certification revocation list (CRL) is needed to notify that a certificate is not valid. There may be a considerable delay between the actual need to revoke and reflection of this need in a certificate chain with different CA’s. SSL does not check the revocation list, so it is useless in SSL applications. Certificate chains A certificate authority may also issue a certificate for another CA. When examining a certificate, the subject (client) needs to examine the certificate of the issuer, for each parent CA, until reaching one in which the subject has confidence. The subject may decide to only trust a limited chain of issuers. PGP – Pretty good privacy PGP [20] depends on the integrity of a chain of authenticators, the users themselves. The users and their keys are referred from one user to the other, forming an authentication ring does not denote a closed structure but is loosely modeled as a trusted list or “web of trust.” One may have different rings, with “contact points” which guarantee the referrals but no user can know for sure that everyone in his ring is valid. The authenticators themselves do the maintenance of this chain – connected rings, which can be multiply connected. There is no file locking mechanism, so PGP enforces a model of “hard trust” with “trust is intransitive” to setup entries, but it uses “soft trust” to upkeep entries, without discussing its validity nor allowing for time factors such as lack of synchronization. PGP can interoperate with a CA fully trusted by all the parties in a domain that is willing to guarantee certificates, as a trusted introducer. There is no entity responsible if something goes wrong and no well-defined contracts with loss responsibilities and fines.

PAGE 41

31 It is also not scalable because of the asynchronous maintenance difficulties of the web of trust over time. The main difference PGP and X.509 is that PGP allows certificates to be stacked up, i.e. signatures upon signatures, whereas in X.509, certificates are linked to one another as a linked list. PGP allows an association between keys and the real world by the web-of-trust but not transitive trust, whereas X.509 binds keys to names and accepts transitive trust. SKIP (Simple key management for Internet protocol) SKIP implements a linked chain of two-sided node authenticators. Each node authenticator derives its information from a type of directory service. The SKIP authentication process happens at the protocol level (not at the message level), so it needs to be complemented by a second authentication protocol, in a higher layer, for non-repudiation and other security features. It is transparent to the user, hence lacks control like rejection, revocation or choice of certificates. There is a “Directory service” which is a type of “central administration of SKIP –” which is needed to guarantee accountability, coherence, dependability and correct authentication. We know that a given packet will not have a unique path, even if similar packets are used for a series of requests. (In PGP, authentication is done at the fixed endpoints). Therefore, the user has no control over the process to decide which node authenticator is reliable and cannot exclude nodes if they are attacked, or even the certificates. Meta-certificates As we can infer from the above discussion that X.509 Certificates, CA, PGP and SKIP need some type of centralized control systems, which is a conflict with the Internet

PAGE 42

32 architecture – which is totally decentralized. A solution to the certification problem, which would not need any type of centralized certification control system, is offered by MCG – Meta certification group [21]. MCG describes a layered certification protocol called “meta certificates” to enhance security and flexibility either as a standalone technology or interoperable with current technologies. 3.5 Attacks Threats to computing systems are circumstances that have the potential to cause loss or harm. The threats, which exploit vulnerabilities of the assets in computing systems, are: 1. Interruption: An asset of the system is destroyed or becomes unavailable or unusable. This is an attack on availability. For example, erasure of a program or data file, or malfunctioning of an operating system file manager, denial of service. 2. Interception: An unauthorized party gains access to information. This is an attack on confidentiality. The unauthorized party can be a person, person or a computing system. Traffic analysis or Wiretapping or Eavesdropping is the simplest type of attack. A host is configured to "listen" to and capture a copy of data not belonging to it. Carefully written eavesdropping programs (packet sniffers) can take usernames and passwords from sessions using plain text protocols on user login network connections. Broadcast networks like Ethernet are especially vulnerable to this type of attack. 3. Fabrication: An unauthorized party inserts counterfeit objects into the system. This is an attack on authenticity. For example, the insertion of spurious messages in a network or the addition of records to a file. Authenticity can be provided during the following events: a. Single message: Proof that a message is sent by the alleged sender. b. At connection setup each entity proves their identity. 4. Modification: An unauthorized party not only gains access to but also tampers the asset. This is an attack on integrity. For example, a communicated data item, such as a Java class file, is changed, deleted, or substituted while in transit. A mechanism should be provided to prove that messages are sent and

PAGE 43

33 received untampered, with or without duplication, insertion, deletion, modification, reordering, or replays. 5. Repudiation: Both entities involved in an exchange of information can reproduce and prove that the exchange took place, and the exact messages exchanged. 3.5.1 Classification of Attacks Attacks on the cryptographic primitives and protocols have been identified. A useful categorization of these attacks is in terms of passive and active attacks. 1. Passive attacks: Can be prevented but are hard to detect, Figure 3.2. a. Eavesdropping: explained above, in interception. b. Traffic analysis: explained above, in interception. 2. Active attacks: Can (usually) be detected but are hard to prevent, Figure 3.3. a. Masquerade: Masquerade takes place when one entity pretends to be a different entity. It is form of an active attack. For example, capturing authentication sequences and replaying afterwards to gain unauthorized access. b. Replay: This involves copying (passive) legitimate messages, re-sending these messages or pieces of them later to gain access. c. Modification of messages: This means the portion of a legitimate message is altered, or delayed or reordered to produce an unauthorized effect. Traffic Analysis Eavesdropping Interception of a message Passive Attacks Figure 3.2 Passive Attacks d. Denial of service or resource exhaustion : This attack prevents the normal use of communication facilities. Disruption of network can be done by disabling it or by overloading it with messages so as to degrade the performance.

PAGE 44

34 Fabrication Modification Interruption Active Attacks Figure 3.3Active Attacks 3.5.2 Attacks on Encryption schemes The objective of the following attacks is to systematically recover plaintext from ciphertext, or even more drastically, to deduce the decryption key. 1. A ciphertext-only attack is one where the adversary tries to deduce the decryption key or plaintext by only observing ciphertext. 2. A known-plaintext attack is one where the adversary has a quantity of plaintext and corresponding ciphertext. This type of attack is typically only marginally more difficult to mount. 3. A chosen-plaintext attack is one where the adversary chooses plaintext and is then given corresponding ciphertext. Subsequently, the adversary uses any information deduced in order to recover plaintext corresponding to previously unseen ciphertext. 4. An adaptive chosen-plaintext attack is a chosen-plaintext attack wherein the choice of plaintext may depend on the ciphertext received from previous requests. 5. A chosen-ciphertext attack is one where the adversary selects the ciphertext and is then given the corresponding plaintext. One way to mount such an attack is for the adversary to gain access to the equipment used for decryption (but not the decryption key, which may be securely embedded in the equipment). The objective is then to be able, without access to such equipment, to deduce the plaintext from (different) ciphertext. 3.5.3 Attacks on Protocols The following is a partial list of attacks, which might be mounted on various protocols. Until a protocol is proven to provide the service intended, the list of possible attacks are: 1. Known-key attack: In this attack an adversary obtains some keys used previously and then uses this information to determine new keys.

PAGE 45

35 2. Replay: In this attack an adversary records a communication session and replays the entire session, or a portion thereof, at some later point in time. For stored files, the analogue of a replay attack is a restore attack, whereby a file is replaced by an earlier version. 3. Impersonation: Here an adversary assumes the identity of one of the legitimate parties in a network. 4. Dictionary: This is usually an attack against passwords. Typically, a password is stored in a computer file as the image of an un-keyed hash function. When a user logs on and enters a password, it is hashed and the image is compared to the stored value. An adversary can take a list of probable passwords; hash all entries in this list, and then compare this to the list of true encrypted passwords with the hope of finding matches. 5. Interleaving attack: It is an impersonation or other deception involving selective combination of information from one or more previous or simultaneously ongoing protocol executions (parallel sessions), including possible origination of one or more protocol executions by an adversary itself. 6. Reflection attack: It is an interleaving attack involving sending information from an ongoing protocol execution back to the originator of such information. 7. Forced delay: A forced delay occurs when an adversary intercepts a message (typically containing a sequence number), and relays it at some later point in time. Note the delayed message is not a replay. 8. Chosen-text attack: It is an attack on a challenge-response protocol wherein an adversary strategically chooses challenges in an attempt to extract information about the claimant’s long-term key. 3.6 Mobile Agent Concepts Mobile code is a general term used to refer to processes (executable code, figure 3.4) that can migrate and execute at remote hosts. We define a mobile agent as an entity having the following four attributes: 1. Identification: Each mobile agent can be uniquely identified by its identity. 2. Data space: The agent’s data buffer, which carries the agent’s state information, input data and computed results. 3. Itinerary: The state information contains route information, which may be modified as the agent migrates. It can be fixed or dynamically determined by the agent at runtime.

PAGE 46

36 4. Method: The processing task (or execution code) carried with the agent. 3.6.1 Types of Agents Agents can be categorized on the basis of number of hops, as explained below: 1. One-hop Agents (weak mobility), e.g., Java applet, are sent on demand from a server to a client machine and executed. After execution, the agent’s results, or the agent itself is returned to the agent owner that sent it. 2. Multi-hop Agents are those, which may visit multiple platforms and also communicate with other mobile agents. They are used to perform a series of tasks and are strongly mobile as compared to the one-hop agents. 3. Replicating agents, which spawn multiple copies of themselves (or variations) on multiple nodes. Each copy may be single-hop or multiple-hop. These can be used for massively parallel-distributed computations. 3.6.2 Security Issues in a Mobile Agent System There are four security issues specific to a mobile agent, figure 3.5. They are: 1. Protection of the host against agents, 2. Protection of agents from each other, 3. Protection of the agents from the host, and 4. Protection of the underlying network. A secure agent and host must provide services to counter these threats. However, there is no countermeasure if the attacker exploits system flaws or security weaknesses such as bypassing controls, exploiting trapdoors, or introducing Trojan Horses [22]. Mobile A g ent Data Code Execution State Figure 3.4 A Mobile Agent

PAGE 47

37 The security architecture must enforce the following functionality: 1. Protecting agent transfer and communication as required by the security policy. 2. Performing the required access control and auditing of an agent’s execution. 3. Preventing (groups of) agents from interfering with each other or gaining unauthorized access to each other’s state 4. Preventing agents from interfering with their host system. In mobile systems [23], one aspect of security is the protection of the host and another is to protect the mobile agent against host attack. Some of the security mechanisms developed in this field, either in operating systems or programming languages, can be applied to agent systems. 3.6.3 Techniques for Preventing Malicious Code Many techniques [8] have been proposed to prevent the malicious behavior of mobile code. A few of them are discussed below: 1. Code blocking a. Disabling applications: In this, the applications are disabled that cause malicious behavior. It is not easy to administer in a large environment as it relies on users complying with security policy. b. Filtering of packets: It does not rely on user compliance and management can be centralized, e.g., firewalls to filter packets from a particular IP or some file patterns. 2. Safe interpreters a. Interpreted code is preferred over compiled executables, as an interpreter can enforce a security policy. Commands considered harmful can be made safe for or denied to an agent. b. Each instruction is executed only if it satisfies the security policy. c. Examples of safe interpreters are: Safe-Tcl [24]

PAGE 48

38 Java Virtual Machine (though some holes discovered are listed in the next chapter). 3. Authentication through code signing is based on the assurance obtained when the source of the code is trusted. a. On receiving mobile code, the client verifies that it was signed by an entity on a trusted list. b. Once the signature is verified, the code has full privileges. Deciding which sources are good or bad can be difficult in the authentication scheme. The following problems are faced in authentication to avoid malicious code: a. Limits users: Even untrusted code might be useful and benign. b. Code from a trusted source may still be unsafe and thus corrupt the host. 4. Code inspection The features of code inspection are: a. Content inspection/byte-code scanning against known lists of malicious code. b. Validation of certificates and hash values. c. Blocking an unwanted source or client. d. Monitoring traffic. The following commercial solutions intercept and inspect mobile code such as Java applets and Active X controls: a. Finjan’s Surfing Gate b. Network Associates WebScanX 5. Proof carrying code (PCC) PCC is a prevention technique by which a host can determine if it is safe to execute a program from an untrusted source. A host decides upon a safety policy, which is then codified in for example the Edinburgh Logical Frame (LF). An author of the

PAGE 49

39 mobile code generates a proof that the code confirms to the safety policy (certification). Code consumer validates the proof and executes the code if it passes (validation). Any attempt to manipulate either a code or its safety proof results in a verification error. There are various issues related to PCC based on LF; they are the following: a. PCC sacrifices platform independence for performance. b. What program properties are expressible in LF logic is still an open problem. functions Mobile Code Security Security against Malicious Host Security against Malicious Code Malicious Code (Executing useful code while protecting systems from malicious one) Malicious Host (Protect agents from malicious servers) 1. Execution Tracing 2. Partial Result Authentication 3. Mutual itinerary recording 4. Computing with Encrypted 5. Multi-hop trust models 6.Code Obfuscation 1. Code Blocking 2. Authentication 3. Safe Interpreters 4. Code Inspection and Verification 5. Proof Carrying code 6. Path Histories 7. Trapping system calls Figure 3.5 Security Issues and Solutions in a mobile agent system. 6. Path histories A client decides how much privilege should be given to an agent, depending on the prior platforms visited by an agent. This information is authenticable i.e. each agent platform adds a signed entry to the current path and also the next platform. The receiving

PAGE 50

40 platform takes decision after verifying the signature and reviewing the list. This technique has some disadvantages: a. It does not prevent a platform from behaving maliciously. b. Path verification becomes costly with increase in the path history length. 3.6.4 Techniques for Protecting against a Malicious Host The protection of a mobile agent from attacks by a malicious host is also very important. A malicious host can attack an agent in the following ways: 1. Spying out code, data or flow control. 2. Manipulation of code, data or flow control. 3. Masquerading of the host 4. Denial of execution 5. Spying out interaction with other agents 6. Manipulation of interaction with other agents 7. Returning wrong results of system calls issued by the agent There are various techniques for tamper detection and management, which include: 1. Execution tracing In this technique, the agent’s behavior is recorded during it’s execution to detect unauthorized modifications. It involves creation of the following: a. A non-repudiatable log file of the operations performed by an agent. b. A cryptographic hash of the log information. A trusted third party retains the trace for the agent’s entire itinerary. If there is any suspicion then the trace is analyzed and a malicious host is identified. The main problem

PAGE 51

41 with this technique is the size and number of the log files. The analysis of the trace is not a trivial task. 2. Mutual itinerary recording This technique is a variation of path histories, as discussed in previous section. It assumes that there are a few malicious platforms and the platform is not likely to collaborate with another malicious platform being visited by an agent. It involves one or more cooperating agents, which keep track of itinerary of an agent i.e. its last, current and next platform, to the cooperating peer through an authenticated channel. If any discrepancy is found then the cooperating agent takes an appropriate action. 3. Partial result authentication codes a. An agent is sent out with a set of secret keys K1, K2... Kn b. At the ith server, the agent state uses Ki to sign the result of its execution and producing a PRAC. c. Erase Ki from agent state before moving to the next server. d. A malicious server cannot forge the partial results from previous hops. e. PRACs allow an agent’s owner (who has the keys K1, K2... Kn) to cryptographically verify each partial result contained in a agent. f. These messages guarantee perfect forward integrity. If a mobile agent visits a sequence of servers S = S1 Sn, and the first malicious server is sc, then none of the partial results generated at servers Si, i < c, can be forged. 4. Computing with encrypted functions In this technique, a mobile code can compute cryptographic primitives (safely), like a digital signature, even though code is executing in an untrusted environment and operates autonomously without interacting with the home platform. It does not prevent denial of service, replay and other form of attacks against the agent [25]. There is a trick

PAGE 52

42 to find an appropriate encryption scheme that can transform arbitrary function as intended. 5. Code obfuscation a. Generate an executable agent from an agent specification so that it is not vulnerable to leakage and manipulation attacks. b. It involves scrambling the code in such a way that no one is able to understand its function i.e. specification and data. c. Such an agent has black box property, that code and data of the agent specification cannot be read or modified. 6. Multi-hop trust models a. Every host has an agency, which is assigned a level of trust through an Access Control List (ACL). b. Worst-case assumption, i.e. each host can be malicious. c. On each hop, a mobile application’s ACL prior to the hop is merged with the ACL of the receiving agency in such a way that the security privileges decrease or remain the same. d. www.jumpingbeans.com is a framework for mobilizing Java applications.

PAGE 53

CHAPTER 4 JAVA SECURITY In this chapter, I will discuss the security features of the Java Language and runtime on which OCEAN is currently based. Sun Microsystems designed and implemented Java in 1995 for distributed networked computing with the goals of hardware portability, operating system (OS) independence and extensibility for secure web based applications. Java is a portable proprietary single programming language that manages distributed network security challenges of mobile code or executable content downloaded from the web. Java's security model is one of the language's key architectural features that make it an appropriate technology for networked environments. Security is important because networks provide a potential avenue of remote attack to any computer hooked to them. Java security makes Java suitable for networks because they establish a needed trust in the safety of network-mobile code. To accomplish this goal, Java provides a customizable "sandbox" in which Java programs run. Programs can do anything within the boundaries of its sandbox, but it can't take any action outside those boundaries. The sandbox prevents activities like (except as authorized): 1. Reading or writing to the local disk. 2. Making a network connection to any host. 3. Creating a new operating system process. 4. Loading a new dynamic library or directly calling a native method. 43

PAGE 54

44 Java security has evolved over time; recent releases provide fine-grained security features that enable implementation of a flexible policy decoupled from the implementation mechanism. In this chapter, I will discuss the following issues: 1. Evolution of Java Security 2. Java Security Features 3. Java Packages 4. Java Pitfalls 4.1 Evolution of Java Security 4.1.1 JDK 1.0 Security – Sandbox Model The sandbox model confines Java applets, potentially dangerous or not, to a strictly defined arena where they cannot affect other system resources. The sandbox model deems all code downloaded from the network untrustworthy, and confines the code to a limited area of the browser -the sandbox. While this may seem a very secure approach, there are inherent problems. First, it dictates a rigid policy that is closely tied to the implementation. Security needs to be layered for depth of defense and flexible enough to accommodate different policies the sandbox model is neither. 4.1.2 JDK 1.1 Security – Trusted Code Model (All or Nothing) Due to the inflexibility in JDK 1.0 sandbox model, it was refined and introduced a concept of signed applet. A signed applet is an applet packaged as a Java Archive (JAR) file and signed with a private key. The signed applet enjoys unlimited access, just like a local application, provided the corresponding public key is trusted in the executing environment. Unsigned applets were confined to the restricted access in the sandbox model. This concept was more flexible than the previous one but had a major disadvantage: a code either received unlimited access or was confined to the sandbox.

PAGE 55

45 4.1.3 JDK 2 Security – Fine-Grained Security JDK 2 has many improvements over earlier versions, they are: 1. Security checks for all Java programs: A departure from the concept that built-in code should be completely trusted. (It is this capability that serves to erase the once-important distinction between applets and applications.) 2. Fine-grained access control: The ability to specify that code with proper permissions be allowed to step outside the sandbox constraints gradually (for example, an applet signed by a trusted key might be allowed to open arbitrary network connections). 3. Configurable security policy: The ability for application builders and Java users to configure and manage complex security policies. 4. Extensible access control structure: The ability to allow typed permissions and to group such permissions in logical, policy-oriented constructs. 5. Domains: Domains are used to group a set of classes, whose instances are granted with the same set of permissions. 6. Code source: As a piece of code can be downloaded over a network, so a code source encapsulates the origin, which is specified as an URL, and the set of digital certificates containing public keys corresponding to the set of private keys used to sign the code. 7. Protection domain: It's possible to associate permissions with individual classes; however, it's more economical to group classes into protection domains and associate permissions with those domains. A class's mapping to a domain occurs before the class is usable and is immutable thereafter. For instance, system classes can be effectively grouped under the system domain. This relationship between the class and the permissions via the protection domain provides for flexible implementation mechanisms. 8. Permissions: Permissions are at the very core of Java security and represent access to various system resources such as files, sockets, and so on. Permission classes are additive in that they represent approvals, but not denials. 9. Policy: The numerous mappings of permissions to classes are collectively referred to as policy. A policy file is used to configure the policy for a particular implementation. A simple text editor or , a tool bundled with the Software Development Kit (SDK), can be used to write a policy. 10. Access controller : The java.security.AccessController class is used for three purposes:

PAGE 56

46 a. To decide whether access to a critical system resource should be allowed or denied, based on the security policy currently in effect. b. To mark code as privileged, thus affecting subsequent access determinations. c. To obtain a snapshot of the current calling context, so access-control decisions from a different context can be made with respect to the saved context. Bootstrap class files System class files Bytecode Verifier ClassLoader System ClassLoader Access Controller Operating System Permissions Keystore Security Manager Protection Domains User class files Figure 4.1 JDK 2 Security Architecture While the SecurityManager can be overridden, the static methods in AccessController are always available. If you wish a particular security check to always be invoked, regardless of which security manager is in vogue, the AccessController methods should be called. 11. The keystore: The keystore is a password-protected database that holds private keys and certificates. The password is selected at the time of creation. Each database entry can be guarded by its own password for extra security. Certificates accepted into the keystore are considered to be trusted. Keystore information can be used and updated by the security tools provided with the SDK.

PAGE 57

47 4.2 Java Security Features 4.2.1 Language Features The Java language is a simple, object-oriented language with syntax similar to C++. Since the language was created for developing programs in a heterogeneous network-wide environment so security is extremely important. Therefore, Java has several security features built in the language, which helps to protect the integrity and security of the system, and also prevent some common attacks. Those features are described below. 1. Security through strict compile-time checking: The Java compiler performs extensive, stringent compile time checking so that as many errors as possible can be detected by the compiler. The Java language is strongly typed, that is: a. Objects cannot be cast to a subclass without an explicit runtime check. b. All references to methods and variables are checked to make sure that the objects are of the appropriate type. c. Integers and objects are not interconvertible, and array bounds are checked. 2. Security through access controls: Java provides access controls on variables and methods in the object. The access modifiers, public, private and protected contribute to the visibility of members. Java also provides final, which disallows subclassing when applied to class definitions and disallows overriding when applied to method definitions. If final is used with a variable whose type is primitive, the value of that variable is immutable. 3. Security through lack of pointer arithmetic: The Java language does not have pointer arithmetic, so Java programmers cannot forge a pointer to memory. All references to methods and instance variables in the class file are via symbolic names. The user cannot create code that has magic offsets in it that just happen to point to the right place. Users cannot create code that bashes system variables or that accesses private information. 4. Security through garbage collection: Garbage collection makes Java programs more secure and robust. Two common bugs in C/C++ programs are: a. Failing to free memory once it is no longer needed. b. Accidentally freeing the same piece of memory twice.

PAGE 58

48 4.2.2 Java Virtual Machine Java achieves its "Write Once, Run Anywhere" capability by introducing a JVM. It is an abstract computer that resides on top of the host system and responsible for executing Java applications. It provides a layer of abstraction between the program and the underlying hardware and operating system. Since Java allows users to download and execute untrusted applications, it must establish and implement a certain kind of security mechanism in the JVM to restrict the actions of the remote code. The JVM has the following components to achieve its goals: ClassLoader. A ClassLoader loads every class in the Java runtime system. Multiple ClassLoaders can exist in the same runtime environment, each for loading classes from different locations (local or remote). If a malicious class could successfully trick the JVM into believing it was a trusted class from the Java’s API, then the malicious class could potentially break through the sandbox barrier and compromise the security of the Java runtime. Java guards the borders of the trusted class libraries by making sure untrusted classes cannot pretend to be trusted by providing protected name-spaces for classes loaded by different class loaders. A name-space is a set of unique names for loaded classes that is maintained by the JVM. Classes in different name-spaces cannot communicate with each other unless an explicit mechanism is provided. This can prevent a malicious class from accessing other classes currently loaded by the JVM. Byte-code verifier. The byte-code verifier, sometimes referred to as a mini-theorem prover, tries to prove that a given series of Java byte codes are legal. It verifies the remote code to be sure that a trustworthy compiler produced it. It verifies the following things in a class file: 1. It has right length, magic numbers, and no stack overflows or underflows.

PAGE 59

49 2. It conforms to the Java language specification and does not violate any Java language rules or name-space restrictions. 3. It does not access objects through an illegal cast; circumvent access restrictions and so on. 4. Byte code instructions all have parameters of the correct type. 5. All register accesses and stores are valid. SecurityManager. The most important component implemented in the JVM and Java’s security model is the security manager. It is used to enforce the boundaries around the sandbox. It performs run-time verification of all so-called "dangerous methods" such as requesting file I/O, network access, and so on. The security manager is responsible for the following actions: Managing all socket operations. 2. Guarding access to protected resources including files, personal data, etc. 3. Controlling the creation of, and all access to, operating system programs and processes. 4. Preventing the installation of new class loaders. 5. Maintaining thread integrity. 6. Controlling access to Java packages and groups of classes. Once the security manager is loaded, it cannot be extended, overridden or replaced. 4.2.3 Java Packages Java includes a special security related Application Programming Interface, Java Security API, as shown below in figure 4.2. JCA. It provides an infrastructure for performing basic cryptographic functionality. The cryptography is used to protect data against corruption for the sake of data integrity using basic cryptographic functions and algorithms. The cryptographic

PAGE 60

50 signature scheme is used for identifying sources of data and code. API’s to handle keys and certificates are also built into JCA. Core Java 2.0 Security Architecture Java Cryptographic Extension (JCE) Java Secure Socket Extension (JSSE) Java Authentication and Authorization Service (JAAS) Java Cryptography Architecture (JCA) Figure 4.2 Java Security Components JCE. Sun adheres to the definition of cryptography that designates the provision of the basic data integrity and source identity functions supported by the JCA. Encryption is used to mean those functions used to encrypt blocks of data for the sake of added confidentiality until the data can be subsequently decrypted by the intended receiver. JCE is provided for these auxiliary encryption purposes. JCE is provided due to export restrictions on encryption technology. If it were included as a core part of the Java platform, exportability of the Java platform itself would be hampered. Hence, JCE gives strong encryption and JCA does not. JSSE. It provides a standard interface along with an underlying reference implementation for building Java applications with Secure Socket Layer (SSL). The JSSE is more generically defined to provide a standard interface to support other secure socket protocols such as Transport Layer Security (TLS) and Wireless Transport Layer Security (WTLS).

PAGE 61

51 JAAS. It provides a standard way for limiting access to resources based on an authenticated user identity. Standard API’s for login and logout are provided. In these, a standard interface for passing around secure user credentials and context makes it possible to swap in and out different underlying authentication model implementations. Thus, whether someone uses Kerberos or Smart Cards, the same API is provided. We can see that Java provides extensive security APIs. I will be using JCA and JCE to implement the protocols, which I will explain in Chapter 6. JSSE will be used when an accounting server wants to communicate with the financial institution to commit the transactions. JAAS can be used in future versions of OCEAN, to provide an authentication mechanism using smart cards or any biometric medium. 4.3 Java Pitfalls This section summarizes the Java security flaws that have been discovered so far, for latest bugs see [26]. The dates listed are the dates that the bugs [27] were corrected. Here is the list of bugs reported: DNS Attack (February, 1996, fixed in JDK 1.0.1) ClassLoader Implementation Bug (March, 1996, fixed in JDK 1.0.1) Verifier Implementation Bug (March, 1996, fixed in JDK 1.0.2) URL Name Resolution Attack (April, 1996, fixed in JDK 1.0.2) ClassLoader Attack Variant (May, 1996, fixed in JDK 1.0.2) Illegal Type Cast Attack (June, 1996, fixed in JDK 1.1) Inconsistency in javakey (December 1996, fixed in JDK 1.1 beta) Virtual Machine Bug (March 1997, fixed in JDK 1.1) Disclosure of IP addresses (March 1997, fixed in JDK 1.0.2) Signing Flaw (April 1997, fixed in JDK 1.1.2)

PAGE 62

52 Verifier Bugs (May 1997 and June 1997, fixed in JDK 1.1.2) RSA PKCS1 Risk in SSL (June 1998) Princeton ClassLoader Attack (July 1998, fixed in JDK 1.2) Execution of Unverified Code (March 1999) – affected JDK 1.1.x and Java 2. Locally Installed Applet Classes (February 2000, fixed in JDK 1.3) Brown Orifice Exploit (August 2000, fixed in JDK 1.2) Java Runtime Environment vulnerability (February 2001, October 2001, January 2002, March 2002) – not yet fixed Even though Java does not provide complete security, it still has lots to offer. It's the most viable attempt so far to provide secure mobile code. Java is deeply tied to the Web and comes with many advanced networking features. Java is powerful and can be used to write full-fledged programs. Java is a more portable application language than any other on the market today. Java includes advanced language features that all developers should have access to. To top it off, Java is truly concerned with security.

PAGE 63

CHAPTER 5 PROTOCOL DESIGN Code signing and sandboxing offer two different paradigms for securing and preventing malicious activity by mobile code. Sandboxing uses a compiler and code checker that actively forbids many potentially malicious activities. Code signing verifies the source and the integrity of incoming mobile code. Based upon this information, the user is responsible for authorizing its execution. Any mobile code that is properly signed and accepted by the local user will be allowed to run. "Signed" code is encrypted with the authenticator's private key. Hence, the code is guaranteed to have originated from a known source and have been unmodified between the sender and the recipient. The premise of security via authentication is that no one would deliberately release malicious code with his or her signature, for fear of legal and other repercussions. Properly signed mobile code from reputable certified sources can thus be trusted by the user, allowing the mobile code to run with fewer constraints on its functionality. The construction of a perfect java sandbox is very difficult; witness the unintended loopholes in java, for details see [26, 27]. Of course, the bugs in Java only affect the difficulty of the Java sandbox, not of sandboxes in general. So, Java sandbox model is not enough to provide a secure system. In this chapter, first, I will focus on a protocol I have designed in which a user can securely register with authentication server and retrieve its public-key certificate. Then I will discuss the login module I have designed and its features. Finally, I will discuss a mechanism (Station-to-Station protocol or STS [28]) in which clients can mutually 53

PAGE 64

54 authenticate and exchange a secret key, to commence a secret session between them. I have modified the STS protocol in such a way that it increases the lifetime of the shared secret keys. Before analyzing any protocol, it is necessary to discuss the goals of the registration protocol and the OCEAN-STS (Station-To-Station) protocol, which are the following: 1. The clients should be able to register with the authentication server, securely. 2. The server should assign a unique ID to each client and securely send the public-key certificate to a client. The unique ID is used to uniquely identify a client, when they communicate with each other to exchange information. 3. The registration protocol satisfies the basic assumption of the STS-MAC protocol (explained later) that prior to the secret key exchange, a client should have its own public-key certificates and a unique identity. 4. Extend the lifetime of the public-private key pair and shared secret keys. The following notation is used throughout this chapter. Table 5.1 Notations A, B Honest Entities (M) KPrivate-Client or SB (M) Signing message M, using client’s (B) private key (M) KPublic-Client Encrypting message M, using client’s public key CertPublic-Client Certificate of the public key of a client. It contains details of a client, its public key and the name of the certificate creation authority. T1 Timestamp generated by a client. EK (M) Encrypting a message using a secret key K. MACK (M) Message authentication code of a message M, using a secret key K. 5.1 Registration Procedure During the installation of the OCEAN software, a client, on behalf of the local user, will send the user’s information to the authentication server (figure 5.1) and request to be registered. The server will check whether the requesting user has already been registered or not. If not, then the authentication server will return the client’s unique

PAGE 65

55 identity and the public-key certificate to the client, signed by the server’s private key. Otherwise, the server will send a signed rejection message to the client. To achieve this goal, both client and server will go through various phases. Before discussing the registration steps, I will talk about the underlying assumptions that I have taken before designing the protocol. Authorization Server Financial N etwork Centralized Accounting Server Client B Security Layer Client A Security Layer Figure 5.1 Communication between the clients and the servers (Accounting and Authentication server) 5.1.1 Assumptions To implement the registration protocol, I have made the following assumptions: 1. While installing the OCEAN software, the public-key certificate of the authentication server is stored on the client machine. 2. The authentication server is highly secured i.e. no one can compromise the server and retrieve its private key. 3. Information about the user e.g., user details, password, keys will be stored in the user’s home directory, in files not readable by other users. 4. A multi-user operating system provides sufficient security such that no user should be able to view or modify the files of the other users (unless appropriate privileges are given to them).

PAGE 66

56 5. No one can eavesdrop on the users GUI during the registration procedure (e.g., during password entry). 5.1.2 Registration Steps 1. On the client side, a keystore1 will be initialized to store the client’s public-private key pair, session keys and certificates. 2. The client will create a configuration file, which a user can use to change the security parameters, e.g., the encryption algorithm or the size of the key. 3. The client will ask the user to enter the following information: a. Passphrase/Password b. Mother’s maiden name c. Login Id d. User Name e. Valid e-mail address f. Organization g. Home phone number h. Permanent and mailing address i. City j. State k. Country l. A secret question2 m. The answer to the secret question. First and Last Name General Information, this information will be sent to the server during registration process. 1 In Java, a public-private key pair and their associated public-key certificate are stored in password-protected databases called keystores. A keystore can contain two types of entries: the trusted certificate, and key/certificate entries, each containing a public-private key pair and the corresponding public key certificate. Each entry in a keystore is identified by an alias. A person who receives the certificate can import it into the keystore as a trusted certificate, to verify signatures generated using the corresponding private key. 2 The reason for having a secret question and the answer to the secret question is explained in the Login Module section.

PAGE 67

57 4. When a user clicks a button to register, the client will generate a public-private key pair and store it securely in the keystore, using the above password, table 5.2 below shows the keywords used in this chapter. Table 5.2 Keywords Login ID A user to login and access the OCEAN application will use it. User Name This refers to the first and the last name of a user who wants to register with the authentication server. Login Info This refers to the Secret Question and General Information (see step (3) above), which will be encrypted by a built-in encryption mechanism and stored locally in the users home directory. Pass ID This file contains the message digest (MD) of the password and the login ID. It will be stored in the user’s home directory. Client ID This is a unique ID generated by the authentication server to uniquely identify a user in a network. Secret Info This file contains the MD of the mother’s maiden name and the secret answer. 5. The client will take the following steps to create the login information of a user: a. The client will encrypt the general information and the secret question, using a built-in encryption mechanism. We refer to this information as login info , which will be stored in the user’s home directory. b. The system will generate a message digest (MD) of the password and the login ID, and store it locally in a file, call this PassID . 3 c. As we know that a message digest is created using a one-way hash function i.e. even if someone is able to retrieve the MD of the PassID , he or she cannot retrieve the password. It is dangerous to store or send the password (in a plaintext or in an encrypted form), but, due to the inherent properties of a message digest, we can store the PassID , locally, without any danger. d. Before sending the user details to the server, the client will create a MD of the “Mother’s maiden name” and “the Answer to the secret question” and store it in the user’s home directory, say Secret-Info . 4 As the Secret-Info is a secret of a user or a group, so it should not be accessible to the server, see above in figure 5.2 below for the client side information. 3 The purpose of having a PassID is explained in Login Module section. 4 The purpose of having Secret-Info is explained in the Login Module section.

PAGE 68

58 Figure 5.2 The Client Side information. 6. A client will request the server to register the user and also create its public-key certificate, see below in figure 5.3 flow (1). The request will be encrypted using the server’s public key, ensuring that only the server can decrypt the information. The client will send the following information to the server: a. A request message. b. The client’s public key. c. A timestamp. d. Registration Details, which includes the secret info , message digest of the login ID, the general information and the secret question (as shown above in the registration step (3)). A timestamp is an important entity for the client-server communication; it prevents denial of service and replay attacks against the client. An adversary can intercept communication between the client and the server, and it can determine the response of the server ( i.e. whether it is a confirmation or rejection, based on the size of the message), this is called traffic analysis . The following scenario explains the denial of service attack and replay attack against the client: P ass ID Secret Info Password and login ID Stored in a file as a message digest. 1. Mother’s Maiden Name 2. Secret Answer Stored in a file as a message digest. They are stored in a keystore, which stores keys and certificates using the password. On top of that, keystore is encrypted using PBE. K eys And Certificates 1. Secret Question 2. General Information Stored locally by using a built-in encryption L ogin Info Stored locally using a built-in encr yp tion mechanism. The server sends this information. Client ID

PAGE 69

59 the message), this is called traffic analysis . The following scenario explains the denial of service attack and replay attack against the client: Figure 5.3 Protocol for registration and creation of a digital certificate. Denial of service (DOS) attack . When the authentication server registers the client, it sends a confirmation message with other details to the client. If a client doesn’t receive the response from the server, timeout occurs (on the client side) and the client again sends the registration request to the server. An adversary listening to the communication between a client and the server can remove the message (server’s confirmation response) from the network, resulting in a time out on the client side. The client will again sent a request to the server to be registered. As a result, the server will again get a registration request from the client, who has already been registered. The server will assume that someone has replayed the previous message, so it will send a rejection message to the client. Now if an adversary Flow1 (Registration Request, Registration Details, KPublic-Client, T1) KPublic-Server Flow2 (M, (M) KPrivate-Server) KPublic-Client OR (Rejection Message, T1, (Rejection Message, T1) KPrivate-Server) KPublic-ClientWhere, M (Client ID, CertPublic-Client, Confirmation Message, T1) T1 the timestamp generated by the client. Flow2 Flow1 Client Server

PAGE 70

60 doesn’t interrupt the rejection message, then the client will not receive confirmation and registration details from the server, even though the server has already registered it. Preventing DOS attack. If we use a timestamp, then every time the client sends a registration request to the server (after timeout), it sends an updated timestamp with the rest of the information. When the authentication server receives the registration message from the same client (after timeout), who has already been registered, then the server will compare the timestamp. If the timestamp is same as the previous one then the server knows that it’s a replay of the previous message, and won’t respond to it. But if the server receives the message from a registered client with a different timestamp then the server will again send the confirmation and the details (the server will assume that the confirmation message was lost during transmission) to the requesting client. This mechanism also prevents the authentication server to respond to the replay of the previous message. In the response message the server will also send the timestamp sent by the client. The client will check the timestamp to make sure that it received the message corresponding to the most recent request. The following scenario explains this attack on the client: Replay attack. It may be possible that due to an exception condition in the authentication server, it sends a rejection message with an exception message to the client and requests again to send the registration request. An adversary listening to the communication between the client and the server, can copy the rejection message from the server. When the client receives the rejection message, the user will change the login ID or some other information and the client will again send a request to the server.

PAGE 71

61 Suppose, the server registers the client and sends the confirmation message to the client. Now, if an adversary, listening to the communication channel, removes the confirmation message from the network and replays the previous rejection message, the client will not be able to get registration details. If a client verifies the timestamp sent by the server, then the client can be sure that the response it got from the server is corresponding to the latest request not a replay of the server’s previous response. 7. On receiving the registration request from a client, the server will create a unique ID5 ( Client ID6) from the information provided by the user. The server will then compare the Client ID client with locally stored Client ID; if match is a success ( i.e. client is already registered) then the server will verify the timestamp (as explained in step (6)) and take appropriate ac tions. If a client is not registered then the server will do the following actions: a. Create a public-key certificate of the client’s public key, which contains the public-key signed by the server’s private key, the client’s and the server’s unique identifier, validity period, a serial number and the client’s information ( e.g., city, state, country, users name, organization, email address). b. Store the user information in the server’s database and the Keystore, as shown below in Figure 5.4. 8. To ensure confidentiality, the server’s response is encrypted by the client’s public key. In the last phase of this protocol (see above figure 5.3 flow (2)), if a confirmation has to be sent, the server will send the following information: a. The Client ID, a confirmation message, the timestamp of the client and a public-key certificate. b. The digital signature of the above information using the server’s private key. 5 Taking one-way hash of “all” information provided by the user will create a Client ID. As we know properties of a hash function, so for two users even a small change in the information will create a unique ID. If a user wants to register on multiple machines then he can use the same information to register. In this case, the server will return a copy of the registration details e.g. , unique client ID and the public-key certificate. 6 Client ID is used to associate an agent with a user who deployed it. It is also used while exchanging secret keys to exchange secret information.

PAGE 72

62 Figure 5.4 The Server Side Information If a rejection has to be sent then the server will send the following information: a. The rejection message and the timestamp of the client. b. The digital signature of the rejection message using the server’s private key. 9. On receiving this information from the server, the client will compare the timestamp, and if the response from the server is “fresh” then the client will store (Figure 5.2 above) the public-key certificate in the keystore. The client ID will be stored locally in a file. A mechanism called “password-based encryption” (PBE) will be used to encrypt the keystore. 5.1.3 Credibility of the Registration Protocol The first step ensures that only the server will be able to decrypt the information. Someone can decrypt the information only if he/she is able to compromise the server and access its private key. The Following Client Information Will Be Stored In A Database On The Authentication Server. Secret Info The Following Information Will Be Stored In A Keystore. L ogin ID (MD file of the user Login) User Name E mail Address Organization P hone Numbe r A ddress City, State and Country A Secret Question This information will be stored in the database, in a p laintext format. They are stored in a keystore using the server’s p assword. On top of that, the keystore is encrypted using PBE. Server’s Keys Clients Public-Key Certificate Client ID 1. Mother’s Maiden Name 2. Secret Answer Stored in a file as a message digest. Client Id Generated by the server and stored locally in the database.

PAGE 73

63 In the second step (the server’s response), encrypting the message using the client’s public key ensures that only the requesting client can decrypt the information. By signing the message using the server’s private key gives an assurance to the client that the server generated the message. Using a timestamp between the client and the server gets rid of replay and denial of service attacks on the client; for details see step (6) above. If we don’t sign (using the server’s private key) the rejection message, then anyone can encrypt a false rejection message by using the requesting client’s public key and send to the client. Someone can also fake the confirmation message, so signing the confirmation or rejection message using the server’s private key, ensures that only server has sent the message. 5.1.4 Risk Someone can initiate a man-in-the-middle attack if and only if he or she is able to compromise the server and access its private key. 5.2 Login Module The first line of defense against illegal entry to the OCEAN application is the user identification and authentication. It follows that the easiest way to gain illegal entry to the system is by obtaining a valid login ID and password. The problem with keeping passwords secret has been around since passwords were invented. With the pace at which technology is advancing, hopefully secured mechanisms will be readily available in the near future to authenticate a user by using fingerprint, retina scan or some other biometric means. The OCEAN login module requires a user to enter a “passphrase.” A passphrase can be just a few characters or as long as a complete sentence. In this case, a user can

PAGE 74

64 easily remember a favorite quote or something related to it, and does not have to scribble on a piece of paper, eradicating a basic problem of security. It specifies minimum length of a passphrase and also enforces usage of special characters. The login module provides much more than just a simple login mechanism. The following sections discuss design of the login module and the features it will provide. 5.2.1 Features of the Login Module It offers following simple and flexible mechanism for a user to access the OCEAN application: 1. Depending on the access mode, a single user or group of users can access the application. The private-public key pair, certificates and other user info will be stored in the user’s home directory. If a group of users were accessing the application then information will be stored in a shared directory, 7 see below figure 5.5. 2. Passphrase is the most important entity, as it is used to encrypt the secret information of the user, using Password based encryption (PBE). 3. A user has an option to either save his login ID and password or enters both login ID and passphrase, so that he can access the OCEAN application to deploy mobile agents. 4. If a user opts for saving the passphrase and the login ID then the system will give suitable warnings (security risk). It will encrypt the login information, using a built-in encryption mechanism and store it locally, so that it can be displayed to the user before he logs in. 5. It provides a mechanism for a user to retrieve the login information if it is corrupted or mistakenly deleted by a user. 6. A user can change the passphrase, at his own convenience, and can also set a new passphrase, if he forgets the old one. 7 A user will be prompted to select a dir ectory in which a directory will be created “OceanShared,” where the shared information will be stored. Then he has to enter or select the user ID’s of the users with whom he wants to share the information. For Unix systems, the system will alter the privileges (using appropriate commands) of the directory and makes sharable among the specified users.

PAGE 75

65 Users shared directory User’s home directory Single User User Group Figure 5.5 Location of the Login Information 5.2.2 How Does the Login Module Work? As we know that the OCEAN application will provide a mechanism by which a user can either sell or buy his computing resources. If an illegitimate user is able to access the application without any login mechanism, he can access any information that the application can access or may use the application for his own use. When a user enters his user ID and passphrase, the client will create a message digest of the login ID and the password. Then the system will compare it with the locally stored MD file, pass ID. If the comparison is a success then the user is allowed to access the application otherwise access is denied. There are 3 scenarios in which appropriate action has to be taken to make sure that a legitimate user is able to access the application. These scenarios are: 1. When a user wants to change the passphrase. 2. When a user forgets his passphrase. 3. When the login information is corrupted or mistakenly deleted by a user or by a malicious code (a virus, denial of service attack). I have assumed that any of the following files could be corrupted or deleted, e.g., Pass ID, Secret Info, Login Info, and the Client ID.

PAGE 76

66 Old Passphrase Login ID General Information N ew Passphrase Mother’s Maiden Name A secret Question A secret answer to the question Old Passphrase and the loginID are used in the1 st scenario. This information is used in the 2n d scenario. Figure 5.6 User’s information for different scenarios. As we know that the keystore stores the client’s public-private key pair, its public-key certificate, secret keys, session keys and certificates of other clients. If this file were corrupted then the client will again generate new keys and sends a registration request to the authentication server. If a user opts (during installation of the software) to take a backup, periodically, of the keystore then the system can restore the information (even though it won’t have the latest information). There are few problems with this solution, which are: 1. There will be a high storage requirement on the client side. 2. It is difficult to decide, how frequent the client should take the backup? For the first scenario, see above in figure 5.6, the client will ask a user to enter the loginID, the old passphrase and the new passphrase. It will take the following actions on the information provided by the user: 1. Create a MD of the old passphrase and the login ID, and compare it with the locally stored MD file, PassID. If the above information is incorrect then the user will be given an appropriate rejection message, otherwise the following actions will be taken: 2. MD of the new passphrase will replace the old MD file, PassID.

PAGE 77

67 3. As we know that information in the keystore is encrypted using the passphrase and keystore is encrypted using PBE. So, everything will be re-encrypted using the new passphrase. For the second scenario, if a user forgets his passphrase then he cannot retrieve his old passphrase but can assign a new one. In this case, the user will be asked to enter all information (the login ID, the general information, the mother’s maiden name, the new passphrase and an answer to the secret question), excluding the old passphrase. The system will compare information provided by a user with the stored one, if everything matches then the client will do actions as explained above (in the first scenario, step (2)), regenerate public-private key pair, reinitialize the keystore and sends a request to the authentication server to generate a public-key certificate, otherwise it will decline the request of a user. In the third scenario, if only PassID is corrupted then the client will follow the same procedure as it followed when a user forgets his passphrase. In addition to that, it will recreate MD of the login ID. In other cases, where an individual or combination of files can be corrupted, the client will ask all information (as shown in step 3) from the user. The client will communicate (as shown below in figure 5.7) with the server to authenticate the user and retrieve the corrupted login information (e.g., secret info, client ID). The client will do the following actions with the information provided by the user: 1. The client will create an MD of the mother’s maiden name and the secret answer and the login ID. 2. The client will request the server for changing the passphrase and will send the following details to the server, encrypted by the server’s public key: a. A request to the server, to retrieve the “corrupted” information. b. Information in part “a” above and the secret question. c. The general information.

PAGE 78

68 d. The timestamp to the server. 3. After verification, the server will send back the following details to the client (depending on which corrupt information was requested by the client): a. The Client ID, the Secret info or the Login info. The details are signed by the server’s private key and encrypted using client’s public key to ensure that only the client can decrypt the information. 4. After receiving and verifying the confirmation message, the client restores the user details in the user’s home directory. It recreates the MD of the new passphrase and also login info. Flow 1 (M1, (M1) KPrivate-Client) KPublic-Server Flow 2 (M2, (M2) KPrivate-Server) KPublic-Client OR (M3, (M3) KPrivate-Server) KPublic-Client Where, M1 Request, Timestampclient, User Details M2 Confirmation, Requested Information, Timestampclient (Requested Information Is Either The Client Id or Secret Info or Login Info or All of Them) M3 Rejection, Timestampclient Server Client Flow 2 Flow 1 Figure 5.7 Retrieving login information from the authentication server.

PAGE 79

69 5.3 Key agreement protocol It is very important that clients who want to exchange secret information should have access to a secret key by which they can encrypt and decrypt the information without any security risk. In a key agreement protocol, two or more parties derive a shared secret as a function of information contributed by each of these, such that no party can predetermine the resulting value. This also guarantees that the resulting key is fresh. Whereas in a key transport protocol one party creates a secret value and securely transfers it to the other. This cannot be done with the help of a previously agreed-on secret that is used to encrypting the new session key. In chapter 3, I have given an overview of different key establishment protocols. Out of those protocols, I have chosen Diffie-Hellman (DH) key agreement protocol [29] because it allows two parties, never having met in advance or shared keying material (even a public key), to establish a shared secret by exchanging messages over an open channel. Moreover, it does not involve the authentication server to assist clients to exchange a secret key between them. The security rests on the intractability of the Diffie-Hellman problem and the related problem of computing discrete logarithms. The basic version provides protection in the form of secrecy of the resulting key from passive adversaries (eavesdroppers), but not from active adversaries capable of intercepting, modifying, or injecting messages. Neither party has assurances of the source identity of the incoming message or the identity of the party that may know the resulting key, i.e., entity authentication or key authentication. Station-to-Station (STS) protocol is a variation of DH protocol, which provides protection against active attacks. It also provides mutual authentication and explicit key confirmation. In this section, I will be

PAGE 80

70 explaining the DH and STS protocol in detail, and in the end of this section I will discuss my proposed OCEAN-STS protocol and its pros and cons in chapter 7. 5.3.1 Diffie-Hellman Protocol In a simple key agreement protocol, one party simply encrypts a session key using the public key of another party and then sends the encrypted key to that party. Secret communication takes place when both sender and receiver share a secret key, and the messages are encrypted and decrypted using the shared secret key. Here is a brief introduction of this protocol, see figure 5.8. 1 2 3 Figure 5.8 Diffie-Hellman key agreement protocol The protocol has two system parameters p and g. They are both public and may be used by all the users in a system. Parameter p is a prime number and parameter g (usually called a generator) is an integer less than p, with the following property: for every number n between 1 and p-1 inclusive, there is a power k of g such that n = gk mod p. Suppose Alice and Bob want to agree on a shared secret key, using the Diffie-Hellman key agreement protocol. They proceed as follows: First, Alice generates a random private value XA and Bob generates a random private value XB. Both XA and XB are drawn from the set of integers. Then they derive their public values using parameters p and g and their private values. Alice's public value is and Bob's public pXgAmod

PAGE 81

71 value is . They then exchange their public values. Finally, Alice computes gab = , and Bob computes gba = . Since gab = gba = S, Alice and Bob now have a shared secret key S. pXgBmodpXAmod XgB pXXgBAmod Due to the difficulty of calculating discrete logarithms over a large finite field, it is computationally infeasible for someone to calculate XA from YA or XB from YB. Diffie-Hellman has the following attractive features: 1. Secret keys are created only when needed. There is no need to store secret keys for a long period of time, exposing them to increased vulnerability. 2. The exchange requires no preexisting infrastructure other than an agreement on the global parameters and a strong random-number generator. 3. The shared key (the secret) itself is never transmitted. 4. It is secure against passive attacks; an adversary can see the public values but cannot extract any useful information. However, there are number of weaknesses to Diffie-Hellman protocol, for details see [30]: 1. It does not provide any information about the identities of the parties. 2. It is computationally intensive and is vulnerable to a clogging attack (a kind of a denial-of-service attack). 3. It is subject to a man-in-the-middle attack, in which a third party D (dishonest) impersonates B while communicating with A and impersonates A while communicating with B. Both A and B end up negotiating a key with D, which can listen to and pass on traffic. The attack proceeds in the following way: a. B sends his public value YB in a message addressed to A, figure 5.8. b. The dishonest entity (D) intercepts this message. D saves B’s public key and sends a message to A that has B’s user ID but D’s public key (YD). It appears as though it was sent from B’s host system. On receiving D’s message, A stores D’s public key with B’s user ID. Similarly B does on the other side with D’s public key, purporting to come from A.

PAGE 82

72 c. B computes a secret key K1 based on B’s private key and YD. A computes a secret key K2 based on A’s private key and YD. D computes K1 using D’s secret key XD and YB and computes K2 using XD and YA. d. Now D is able to relay messages from A to B and vice versa, possibly eavesdropping on them or altering them. 4. No authentication and you cannot sign anything. This last vulnerability is present because Diffie-Hellman key exchange does not authenticate the participants. Possible solutions include the use of digital signatures and other protocol variants; e.g., Oakley Key Determination protocol [31], Station-to-Station protocol [28]. 5.3.2 Station-to-Station Protocol The STS protocol is an extension of the Diffie-Hellman protocol that provides mutual key authentication (implicit), mutual key confirmation and forward secrecy. There are two variants of the STS protocol, STS-MAC (station-to-station message authentication code) and STS-ENC (station-to-station encryption); for details see [32]. STS-ENC provides (explicit) key confirmation by using the agreed key K in a symmetric-key encryption scheme, whereas STS-MAC provides (explicit) key confirmation by using agreed key K in a MAC algorithm. The STS-MAC protocol and STS-ENC protocols are depicted below in figure 5.9 and figure 5.10 respectively. )),((),,(,)3)),((),,(,,)2,)1ABABABABBAXgXgAS K MACXgXgASACertBAXgXgBSKMACXgXgBSXgBCertBAXgABA Figure 5.9 STS-MAC protocol

PAGE 83

73 )),((,)3)),((,)2,)1ABABBAXgXgAS K EACertBAXgXgBSKEXgBCertBAXgABA Figure 5.10 STS-ENC protocol In the above figures, (A B X) and (B A X) mean that A sends a message X to B and vice versa. In the STS-MAC protocol the following actions are taken at client A and client B: 1. The initiator i.e. A, sends its identity (A) and the public value () to client B, see step (1) in figure 5.9 above. AXg 2. On receiving request, B generates a public value () and computes the shared secret (K =), as explained above in the Diffie-Hellman protocol. B then sends (figure 5.9 step (2)) its public-key certificate, public value, signed (using B’s public key) public values of A and B, and MAC of the signature (using shared secret K) to A. BXg pXXgABmod 3. On receiving response from B, A verifies the signature (after extracting the public key from the certificate) and the MAC. If verification is a success then it computes the shared secret (K =), as explained above in the Diffie-Hellman protocol. A then sends (figure 5.9 step (3)) its public-key certificate, signed (using A’s public key) public values of A and B, and a MAC of the signature (using shared secret K) to B. pXXgBAmod In this protocol, a certificate is used to verify the authenticity of B’s and A’s signing key. MAC is used to verify the integrity of the messages exchanged between clients and also provide mutual key confirmation, as shared secret (K) is used to generate the MAC. If at any stage verification performed by either A or B fails, then that entity terminates the protocol run and rejects the request. STS-ENC also works in the same way as STS-MAC protocol but it is not preferred over STS-MAC due to existing export or usage restrictions on secure encryption.

PAGE 84

74 5.3.3 Attacks on the STS protocol Both STS-ENC and STS-MAC protocols are prone to public key substitution attacks , for details see [28]. In this attack, an adversary D registers A ’s public key PA as its own, i.e. , PD = PA. When A sends message to B , D intercepts it and replaces identity A with its own identity D , figure 5.9 flow (1). D then passes the message from B to A unchanged in flow (2). Finally, D intercepts the message from A to B , flow (3), and replaces CertA with CertD for the signature verification. This attack can be on either against the initiator or the responder. To preven t these attacks entities have to prove to the certificate issuing authority possession of the private keys corresponding to their public keys during the certification (registration) process. In 1999, S. Blake-Wilson and A. Menezes proposed a new attack on STS-MAC protocol, called “DSKS-UKS” attack, which is based on the DSKS (Duplicate-Signature Key Selection8) property of signature schemes. In a DSKS-UKS attack, after A sends the message, in figure 5.9 flow (3), D intercepts it and selects a public and private key pair (PD, SD) so that ) , (A BX g X g A S is also D 's signature on the message ) , (A BX g X g. D then obtains a certificate CertD for PD, and sends the message with the certificate to B . If A sends its certificate, as in figure 5.9 flow (1), a UKS attack against the responder cannot be launched; however the attack still succeeds against the initiator. Also, it should be noted that D is assumed to be capable of obtaining his certified public key during an execution of the STS-MAC protocol, i.e. , this 8 Suppose that PA (A’s public key) and A’s signature SA on a message M are known. Then the adversary is able to select a key pair (PE, SE) with respect to which SA is also E’s signature on the message M. RSA, Rabin, DSA, ElGamal signature schemes all possess the duplicate-signature key selection property in certain situations.

PAGE 85

75 attack is on-line. This assumption is plausible since delays can occur during transmission of messages even though the CA is on-line. In December 2000, Joonsang Baek and Kwangjo Kim revised the STS-MAC protocol; see figure 5.11. They pointed out vulnerabilities in the protocol and proposed solutions to prevent UKS attacks, which are: 1. Both parties should exchange certificates prior to key agreement protocol. This is not feasible in a situation where low bandwidth is required, as it increases the number of protocol flows. 2. The certification authority should issue certificates after checking that each entity possesses a private key corresponding to its public key. This scheme is fruitless if the signature schemes like RSA, DSA, ElGamal, etc. possess duplicate-signature key selection property in certain situations. ),,3),,,,,3((),,,,,3(,)3),,2),,,,,2((),,,,,2(,,)2,)1BABAXgXgAS K MACBAXgXgASACertBAABABXgXgBSKMACABXgXgBSXgBCertBAXgABAABABABABBA Figure 5.11 Revised STS-MAC protocol 3. Flow numbers9 and identities of the entities should be included in the message being signed and the MAC. The online UKS attacks cannot be launched on STS-ENC because the signatures ),(ABXgXg A S and are not known by the adversary. It is possible to launch, although unlikely, an (offline) attack on the STS-ENC protocol. To launch an attack on STS-ENC, an adversary should have the following information: ),(BAXgXgBS a. A complete specification of the underlying symmetric-key encryption and signature schemes, together with a statement of the security properties. 9 Mitchell and Thomas [33] explain how flow numbers can guard against certain attacks.

PAGE 86

76 I preferred to use STS-MAC protocol for sharing the secret key because STSENC assumes that clients have a shared key to encrypt the certificates (to avoid public key substitution attack), which is an additional overhead. Because of the mathematical properties of the MAC, it is less vulnerable to being broken than encryption (for detail, see definition of MAC in chapter 3). Moreover, MAC is unlikely to be subjected to the export restrictions as an encryption scheme. 5.3.4 OCEAN-STS protocol We have seen that the STS protocol provi des protection against different kinds of attacks, but someone can still launch a clogging attack on a client. In this section, I will discuss a modification that I have done in the existing STS protocol (figure 5.11 above) that prevents clogging attacks to some extent and also enhances the lifetime of the shared secret (generated by using Diffie-Hellman protocol) and public-private keys pair. Before discussing the OCEAN-STS, first I will talk about the lifetime of keys ( e.g., public-private key pair, session key) to understand the modification done by me. The keys have limited lifetimes for a number of reasons. The most important reason is protection against cryptanalysis. 10 Each time the key is used, it generates a number of cipher texts. Using a key repetitively allows an attacker to build up a store of cipher texts (and possibly plaintexts), which may prove suffi cient for a successful cryptanalysis of the key value. Thus keys should have a limited lifetime. For example, recommended RSA key lengths are increased every few years to ensure that the improved factoring algorithms do not compromise the security of messages encrypted with RSA. 10 Cryptanalysis is the flip-side of cryptography: it is the science of cracking codes, decoding secrets, violating authentication schemes, and in general, breaking cryptographic protocols.

PAGE 87

77 The recommended key length depends on the expected lifetime of the key. Temporary keys, which are valid for a day or less, may be as short as 512 bits. Keys used to sign long-term contracts for example, should be longer, say, 1024 bits or more. Another reason for limiting the lifetime of a key is to minimize the damage from a compromised key. Relatively frequent key changes will limit any potential damage from compromised keys. As shown below in figure 5.12 step (3), to extend the lifetime of the publicprivate key pair and the secret key (generated by the DH protocol), RK (Random Key) is added in the step (3), which is sent by the client A (initiator of the communication) by encrypting it using the shared secret. We can call this random key as a session key . The following scenario will explain the purpose of using a session key: ) , , 3 ), , , , , , 3 ( ( , ), , , , , , 3 ( , ) 3 ) , , 2 ), , , , , 2 ( ( ), , , , , 2 ( , , ) 2 , ) 1 B A RK B A X g X g A S K MAC RK B A X g X g A S A Cert B A A B A B X g X g B S K MAC A B X g X g B S X g B Cert B A X g A B AA B A B A B A B B A Figure 5.12 OCEAN-STS MAC protocol. When two clients are communicating for the first time , they exchange a secret key using the OCEAN-STS MAC protocol. In the last step of this protocol, the initiator will save the secret key in the keystore and generates a random session key ( RK , key length of this random key can vary according to the security parameters chosen by a user), which will be sent (by encrypting it using a shared secret, K) to the other client along with rest of the message, Figure 5.12 step (3) above. At this moment, both clients will have access to the session key (randomly generated) and the secret key (generated by the OCEANRK ) RK ), 3, A, B ) , K (RK ),

PAGE 88

78 STS MAC protocol). Thereafter, the clients will exchange information by encrypting and decrypting messages using a session key. This session key will be used for a single session between clients and destroyed after use. In future, if an entity wants to exchange information then it does the following things: 1. The initiator will check in the keystore whether it has an un-expired shared secret with the destination or not. 2. If a client does not have the shared secret (with the destination) in the keystore or it is expired then the client will initiate the OCEAN-STS MAC protocol to compute a shared secret with the destination, as explained above. Otherwise, it will regenerate a random key (session key) and encrypt it by using the shared secret. This encrypted session key will be sent to the destination, which will be decrypted by the destination. Thereafter, messages will be encrypted and decrypted by using the session key, and discarded at the end of the session. As we can see that a client computes the shared secret only when it does not exist in the keystore or expired. Thus it will prevent a client to go through computationally expensive secret key generation (Diffie-Hellman) and avoid a clogging attack. Moreover, the shared secret is used less frequently (to send the session key) as compared to the session key; this enhances the lifetime of the shared secret and it can be used for a longer period of time.

PAGE 89

CHAPTER 6 CONCLUSIONS AND FUTURE WORK 6.1 Conclusions We saw in chapter 3, that there are many ways in which clients can exchange session keys to commence a secret communication. From the discussion in chapter 5, I conclude that the OCEAN-STS protocol, along with the registration and login modules is suitable to a distributed environment like OCEAN. The advantages and disadvantages are discussed below: Advantages 1. This scheme limits the impact of a cryptosystem compromise. If a non Diffie-Hellman cryptosystem (e.g., RSA) is broken, or if a secret key is compromised, then all the primary keys and message traffic protected under the private key system are compromised. However, if a Diffie-Hellman derivation is compromised, only the traffic protected under the one primary key is compromised, and authentication is unaffected. Moreover it preserves the perfect forward secrecy of a key. 2. This algorithm is highly secure as it relies on the fact that, while it is relatively easy to calculate exponentials modulo a prime, it is believed to be very difficult to calculate discrete logarithms (without a quantum computer). 3. It increases the lifetime of the secret key and the public-private key pair, as they are not used often, only when two parties communicate for a short time. 4. It achieves distributed key exchange methodology and is very useful in a distributed environment. In any authentication protocol, it is preferred to have less communication with the server. There are number of advantages and disadvantages regarding the use of server, which are discussed later. 5. It prevents certain attacks on a client, e.g., the OCEAN-STS protocol prevents a clogging attack and the registration protocol prevents denial of service attack on a client. 79

PAGE 90

80 Disadvantages: 1. One of the disadvantages of this system is that it uses public keys, which require significantly more computational power (to compute modular exponentials) than traditional private-key systems such as Data Encryption Standard (DES). 2. If there is any dispute regarding the information exchange then it will be very difficult to settle, as the server is not included in the key exchange protocol. 3. In the OCEAN-STS protocol, a client is supposed to remember the public key, public-key certificate and the shared secret (till they expire) of peers with whom it communicates. This increases the storage requirement on the client side but it prevents a client from a clogging attack. The following are the advantages and disadvantages of using an authentication server. Advantages: 1. There is a central place that administrates all access rights. This makes various administrative tasks easier. 2. Revocation of access is automatically supported by the system. No separate revocation mechanism is necessary. 3. The central server can keep comprehensive auditing logs of security related operations. Disadvantages: 1. Performance : The authentication server (CAS) must be highly available and be able to handle high traffic volume. Suppose there are 100,000 users and if only 10,000 want to initiate a secret session at one time, this would affect the performance of the CAS. Even if we have a hierarchical structure of distributed servers, then the problems related to communication between CAS’s, replication of information should be considered carefully. 2. A single point of failure : The server must be reachable from across the network, and must be reliable, as nothing can work without a functioning server. Redundant server structure with fail-over can be used, so that a second server takes over when the first fails. A fail-over structure protects against technical errors, but does not necessarily protect against denial-of-service attacks. 3. Compromise : Confidentiality of the CAS is so critical that if an individual were able to gain read-only access to the data housed on the CAS, the CAS would be considered compromised, since the CAS contains all users’ private authentication credentials.

PAGE 91

81 4. Congestion: The CAS should be able to handle heavy traffic due to the registration and secret key distribution. 5. The system is effectively a closed system. Only users who are registered at the server can partake in the system. It is not clear how two users that belong to different servers would communicate. 6.2 Future Work Security is a complex issue which cannot be completely covered in one thesis. I have discussed and designed some of the most important aspects of security in OCEAN (authentication, a distributed key exchange mechanism and a login module). There are various security issues yet to be resolved, e.g., how to restrict the utilization of resources, how to prevent stealing data from the mobile agent or from the host. It is also very important to penalize a client who repudiates any transaction. So, on what factors a client will be penalized and what actions should be taken and by whom? Trust is one of the most important issues in security. A protocol has to be developed to handle trust issues between clients (i.e. how trust will initiate and propagate). Security policies (authorization issue) have to be clearly defined, to restrict the functionality of a mobile agent on the remote machine. As the authentication server contains critical information, so the security of the server should be considered carefully. Conventional cryptography encrypts a complete document. We know that XML documents contain the bid information; encrypting the complete document is not recommended, as a receiver can see offers (after decrypting) proposed by other sellers. Recently, Verisign is working on a technology (XML signatures) in which a client can sign information and encrypt information contained in a document, rather than encrypting the complete document. This technology should be used in OCEAN to sign and encrypt information within a XML document.

PAGE 92

82 LIST OF REFERENCES [1] Michael P. Frank, Open Computation Exchange And Auctioning Network , http://www.cise.ufl.edu/research/ocean , accessed: 04/02/2002. [2] Grid Computing Information Centre, Grid Computing Infoware , http://www.gridcomputing.com , accessed: 03/20/2002. [3] Ian Foster and Carl Kesselman, Globus: A Metacomputing Toolkit, International Journal on Supercomputer Applications, 11(2), pp: 115-128, 1997. [4] Entropia Inc., Distributed Computing , http://www.entropia.com , accessed: 02/15/2002. [5] Parabon Computation Inc., Computing Outside The Box , http://www.parabon.com , accessed: 02/17/2002. [6] Rajkumar Buyya, Economy Grid (EcoGrid) Project , http://www.csse.monash.edu.au/~rajkumar/ecogrid , accessed: 10/24/2001. [7] The Compute Power Market (CPM) Project, An Economic/Market-Based Computing Over The Internet-Wide Resources , http://www.computepower.com , accessed: 01/06/2002. [8] Wayne Jansen and Tom Karygiannis, NIST Special Publication 800-19 Mobile Agent Security , http://csrc.nist.gov/mobileagents/publication/sp800-19.pdf , accessed: 04/03/2002. [9] VeriSign, Inc, XML Trust Center , http://www.xmltrustcenter.org/index.htm , accessed: 4/12/02. [10] Mark J. Tobias, Resource And Requirement Schemas Applied To Auctioning In A Computational Market , http://www.cise.ufl.edu/research/ocean/MarkTobias/mjtobias_th.pdf , accessed: 1/04/2002. [11] MPI Forum, Message Passing Interface , http://www.mpi-forum.org , accessed: 01/08/2002.

PAGE 93

83 [12] Heeyong Park, Peer List Update Manager (PLUM) Implementation In Open Computing Exchanging And Arbitration Network (OCEAN) , http://www.cise.ufl.edu/research/ocean/designs/PLUM/PLUM_hpark_10_25.pdf , accessed: 12/12/2002. [13] A. Menezes, P. van Oorschot and Scott A. Vanstone, Handbook Of Applied Cryptography , http://www.cacr.math.uwaterloo.ca/hac , accessed 04/01/2002. [14] RSA Security, Password Based Cryptography Standard , http://www.rsasecurity.com/rsalabs/pkcs/pkcs-5 , accessed 11/02/2001. [15] W. Diffie, P. van Oorschot and M.Wiener, Authentication And Authenticated Key Exchanges , Designs, Codes and Cryptography, 2, pp: 107-125, 1992. [16] Boyeng Song and Kwangjo Kim, Comparison Of Existing Key Agreement Protocols , http://caislab.icu.ac.kr/paper/2000/bysong/cisc2000_bysong.pdf , accessed: 01/11/2001. [17] Marc Branchaud, A Survey Of Public Key Infrastructures , http://home.xcert.com/~marcnarc/PKI/thesis/x509.html , accessed: 02/12/2001. [18] Sharon Boeyen, Certificate Policies And Certification Practice Statements , http://www.entrust.com/resources/pdf/cps.pdf , accessed 3/15/2002. [19] Ian Simpson, Modeling The Risks And Costs Of Digitally Signed Certificates In Electronic Commerce , http://www.ini.cmu.edu/NETBILL/pubs/certlife/certlife.html , accessed: 20/12/2001. [20] The International PGP (Pretty Good Privacy) Homepage, Overview Of PGP , http://www.pgpi.org/doc/overview , accessed 2/20/2002. [21] Meta Certificate Group, Internet Open Group On Certification And Security , http://www.mcg.org.br , accessed 10/15/2001. [22] D. Chess, Things That Go Bump In The Net , http://www.research.ibm.com/massive/bump.html , accessed: 12/15/2001. [23] W.M. Farmer, J.D. Guttman and V. Swarup, Security For Mobile Agents: Issues And Requirements , http://csrc.nist.gov/nissc/1996/pape rs/NISSC96/paper033/SWARUP96.PDF , accessed: 10/11/2001. [24] Tcl Developer Xchange, Safe-Tcl , http://tcl.activestate.com/software/plugin/safetcl.html , accessed: 10/12/2001. [25] T. Sander and C. Tschudin, Protecting Mobile Agents Against Malicious Hosts , http://www.icsi.berkeley.edu/~tschudin , accessed 02/02/2002.

PAGE 94

84 [26] Sun Microsystems, Security Bulletin Archive , http://sunsolve.sun.com/pubcgi/secBulletin.pl , accessed: 19/02/2002. [27] Sun Microsystems, Chronology Of Security-Related Bugs And Issues , 3/19/02 http://java.sun.com/sfaq/chronology.html , accessed 03/21/2002. [28] Joonsang Baek, A Study On Provable Security Of Public-Key Encryption Schemes And Key Agreement Protocols , http://caislab.icu.ac.kr/pub/thesis/down/mohi.ps , accessed: 08/06/2001. [29] S. Blake-Wilson and A. Menezes, Authenticated Diffie-Hellman Key Agreement Protocol , http://www.cacr.math.uwaterloo.ca/~ajmeneze/publications/sac98.ps , accessed: 09/30/2001. [30] C. Huiteman, IPv6 The New Internet Protocol , Prentice Hall, Upper Saddle River, NJ, 1998. [31] H. Orman, The OAKLEY Key Determination Protocol , http://downloads.securityfocus.com/library/rfc/1998/2412.txt , accessed: 12/10/2001. [32] S. Blake-Wilson and A. Menezes, Unknown Key-Share Attacks On The Station-ToStation (STS) Protocol , http://www.cacr.math.uwaterloo.ca/~ajmeneze/publications/sts.ps , accessed: 10/21/2001. [33] C. Mitchell and A. Thomas, Standardization authentication protocols based on ppublic key techniques , Journal of Computer Security, 2, pp: 23-36, 1993.

PAGE 95

BIOGRAPHICAL SKETCH Nitin Chawla was born in Faridabad, Haryana (India), on August 6th 1976. Nitin attended C.R State College of Engineering, Murthal (Sonepat), Haryana, where he received his Bachelor of Engineering degree in computer science and engineering in 1999. Before pursuing his master’s research in computer engineering at University of Florida, he worked in a start up company in Faridabad for 6 months. During his master’s research he was a teaching assistant for a Java course for one year and attended school full time. His research interests include security in distributed systems and XML. Recently, he got a job offer from DELL as an International Product Support Engineer for the servers and the storage area networks. He is looking forward to this challenging job offer from DELL. 85