Security Mechanisms for a Mobile Agent-Based Platform for Electronic Commerce of Internet Domain Names

Frédéric SCHÜTZ <frederic.schutz@cui.unige.ch>
Lassaad GANNOUNE <lassaad.gannoune@cui.unige.ch>
Julien FRANCIOLI <julien.francioli@cui.unige.ch>
University of Geneva
Switzerland

Abstract

Internet domain name management is currently developing into a very significant market. In this paper we present the different security mechanisms that we have designed and implemented for the Domain Name eXchange (DNX) platform, which aims to support an integrated market for Internet domain names. Our platform is based on mobile agent technology, which enables flexible and efficient electronic trade of domain names. The registration model that we have used is Core's Shared Registry System model, which aims at an open and fair registration process.

We have analyzed the different threats relative to the agent's platform, and thus we have defined two sets of security measures. On the one hand, we use cryptographic tools like encryption and digital signatures to ensure the safe transport of the agents between the hosts. On the other hand, we have opted for a secure Java-based platform to guarantee a safe execution of the concurrent agents. Finally, we have examined the different advantages and limitations of the agent's use relative to security.

Introduction

The demand for names is currently increasing very rapidly in line with the commercialization of goods and selling of services using the Internet. Many names will have a short Internet life cycle and will become reusable after a certain period of time. Since there are a limited number of short names, one can expect such names to have a good resale value.

The Domain Name eXchange (DNX) platform [1][2] has been designed and implemented in order to provide value-added registration services for the Internet domain name market. Our platform is based on the Shared Registry System (SRS) model specified by the Internet SRS Draft [3], in which registries (companies that administer one or more gTLDs [generic top-level domains]) and registrars (companies that dispense domain names) are the main actors.

The main focus of our work in DNX has been the construction of an open registration platform leading to the computerized trade of domain names. In order to compensate for the decentralization of domains at the top level, the primary purpose of the value-added services is to support a single market for domain names. We have provided these services using mobile agent technology [4] since they are typical examples of services that can benefit from the flexibility of agents. For instance, agent more easily support the integration of new services into registrar sites and existing systems. Furthermore, an agent can carry a dynamically formulated registrar request to a registry database. This provides the registrar with much flexibility in the type of reservation and registration strategies since he or she does not need to enumerate exhaustive lists of interesting domain names. Agents also facilitate enhanced querying, which can be exploited for domain name market studies.

Stability and security in the conduct of registration activities are critical components that need to be addressed. Currently, in the domain name business area, the registration activity is always performed via e-mail with minimal security features. In this paper, we discuss and present the different security levels that we have established in order to provide a safe and secure mobile agent-based platform for the trade of Internet domain names. We begin with an overview of the DNX architecture, followed with an analysis of the different threats and the security measures needed to prevent them. Then we present some implementation details, and we end with some concluding remarks.

Overview of the DNX architecture

The DNX architecture is a distributed architecture with two kinds of actors, registries and registrars. Each host acting in the agent's network is structured in the same way, with three main parts:

1. an agent space, where the agents are executing and can interact with other agents or with the host through the service space;
2. a services space, which provides the interfaces between the agent and the platform; and
3. a security space, which acts like a firewall controlling the incoming and outgoing agents. Its main role is to ensure that only identified and authorized agents can access the platform. It consists of two main stationary agents: the "sender agent," which encrypts and signs outgoing agents, and the "receiver agent," which decrypts and verifies the signature of incoming agents. The security space also supports some platform management functions (e.g., load control functions) and can refuse entrance to agents if the system is overloaded.

The main difference between a registrar and a registry lies in the services available to the agents.

Registrar architecture

The registrar architecture (fig. 1) is very simple, and only a few services are provided:

• The agent generator service is an interface for the creation of the agents. We have implemented a Web-based interface to handle customer requests and pass them to the agent generator service, which will create an agent encapsulating a customer registration strategy (SRS requests or arbitrarily complex algorithms) and then move it to the agent space.
• The publishing service is an interface that collects replies from received agents, like SRS request acknowledgments (ACKs). This service keeps the state of sent requests by logging all received ACKs and notifies the user when SRS replies are received.

Figure 1 Registrar architecture

The agent space is used only by mobile agents starting their execution before migrating to remote registries or after coming back from registries for publishing their results.

Registry architecture

On the registry side, the DNX platform is connected to the database's front end, and all communications between them are based on the SRS protocol [3]. No change has to be performed on the front end, which can accept requests from mobile agents as well as from clients using e-mail or a TCP transport channel (fig. 2).

Figure 2 Registry architecture and system integration

A registry typically offers several basic services (e.g., SRS services) and advanced services (e.g., notification of events).

• SRS service: This is the basic SRS registration service by which an agent can submit its SRS requests to the SRS front-end machine. SRS service keeps an agent ID for routing replies and ACKs to corresponding agents.
• Event service: This service provides the ability to notify about two kinds of events, specific events and generic events. For specific events, an agent subscribes to the event service for receiving a special class of events (e.g., release of names). The subscribed agent is then notified with solicited events of a certain class, and local filtering in the agent is performed in order to verify the complex and specific conditions on received events. As a possible extension, the multicast protocol [5] might additionally enable the registry to scale to a large number of registrars wishing to receive generic events.
• Advanced Whois service: This is enabled to search contact information about a set of domain names, such as, Whois cnn*.com. In order to perform this type of request, we propose that the SRS protocol should be extended to handle wildcards (e.g., *) in the set of request inquiries (e.g., for contacts, domains).

Threat analysis

Attacks against DNX can be separated into two categories, which require two different sets of security measures:

1. Exogenous threats, which are attacks that occur outside the agent's platform. These attacks are related to the transport of the agent and are not specific to an agent's system, since they may affect any host on the Internet.
2. Endogenous threats, which are attacks that occur inside the agent's platform. These attacks are related to the execution of the agent and thus are more specific.

Secure transport

Since the system runs on the Internet, agents are vulnerable to attack during their transport from one host to another. Such attacks include the following:

• Loss of confidentiality: At first glance, this kind of attack does not look so important in the domain name market, since all databases are public. But before any domain is registered, a name may be an important trade secret. Presently, when someone wants to create a new company, he or she soon checks whether the Internet domain name is still available. Someone who could read the agent's data, and thus the request's data, could register the domain, trying to sell it later to the company. For example, during the merger of the two Swiss pharmaceutical companies Ciba and Sandoz, which gave birth to Novartis, the name of the new company was highly confidential until all relevant domain names had been bought.
• Lack of integrity and authentication: The importance of these attacks is easy to understand. Authentication is essential to know who will be the owner of the newly registered domain and who will be charged for the cost. Integrity is required to guarantee that the registration order has not been changed during the transport.
• Masquerading ("replay attacks"): Replay attacks are not a big deal in usual domain registration; once a domain is registered, sending again the registration request won't have any effect, because the domain is not free anymore, and the request will just be refused. In contrast, replay attacks are particularly dangerous in a agent's context, where the requests have some intelligence and a replayed agent could behave in a completely different way from one execution to another. For example, an agent played twice could buy two different sets of domains, since the first one wouldn't be free anymore on the second execution.
• Denial of services: Denial of services means use of resources by an entity in a way that interferes with authorized use of those services. These attacks are very important on the Internet as a whole.

In an agent's system, detection of these attacks is not sufficient, and their prevention is required in order to guarantee that unknown agents are not able to enter the platform. Cryptographic protocols are the best solution to avoid the first few threats in the list above: encryption solves the confidentiality problem, while digital signatures solve the integrity and authentication one. Unfortunately, no good solution is known to avoid denial of services attacks, and we can only expect them to be detected after they have occurred.

In the world of computer security, most people know that it is much better to use already known and well-tested algorithms instead of building their own. Several solutions are available for the agent's transport protocol. Standard protocols like Secure Socket Layer (SSL[6]) and Transport Layer Security (TLS) exist for securing transmission of data between two hosts and contain everything needed for our agent's transmission, but they are far too general and too heavy for this purpose, since the agents are supposed to be as small and fast as possible.

An easy solution is to use a Key Exchange Protocol with slight modifications to exchange agents instead of keys. We suppose here that A and B have exchanged their public key before the communication take place. "E_A" means "encryption using A's public key," "S_A" means "signature using A's secret key," Hash is a usual hash function like MD5 or SHA-1, and r is a random number.

1. A --> B: E_B(S_A(Agent))
2. A <-- B: S_B(Hash(S_A(Agent))),E_A(r)
3. A --> B: r

The first transaction is the transport of the signed and encrypted agent. The receiver sends back a signed "return receipt" to acknowledge the good reception of the agent, along with the random number r sent encrypted as a challenge to test the freshness of the agent (i.e., to test that it has not already been played).

This general protocol works fine, but it has several defects in our agent's context, the most important being the fact that the three communications need to be completed before the agent can be accepted into the platform. If the transaction is not completed for any reason, the receiver cannot securely execute the agent, even if it has been well received.

Instead, we decided to use a two-way protocol with time stamps:

1. A --> B: E_B(Agent,Time stamp, S_A(Hash(Agent,Time stamp)))
2. A <-- B: S_B(S_A(Hash(Agent,Time stamp)))

After the first transmission, the receiver has enough information to authorize or not authorize the entry of the agent into the system and the only remaining task is to acknowledge its reception. If the sender does not receive this acknowledgment, he or she should send the agent again.

The receiver has to keep a database of received time stamps for a determined time. If a new agent comes with an obsolete time stamp, it is automatically rejected. Otherwise, whether the agent's time stamp is already in the database is checked. If the time stamp isn't already in the database, the receiver has a guarantee that the agent has not been already sent and can thus accept and execute it. The time before a time stamp is obsolete depends on the degree of synchronization between the clock of the sender and clock of the receiver and on the time needed by the agent to go from one host to the other. If we allow a large window of time, we need less synchronization and we can accept a longer time of transport for the agent, but the database gets bigger and attacks that cause delays in the agent's transport are more difficult to notice.

With these security measures, the security control located at the entry of the agent's platform is able to guarantee that only authorized and identified agents can gain access to the platform.

Secure execution

The main security problems introduced by the use of a mobile agent system are related to the execution of the agents. These problems include the following:

• Unauthorized disclosure: Data stored within an agent or the platform are read by an unauthorized entity (another agent of the platform itself).
• Unauthorized modification: An entity in the system modifies the code or the data of another entity. This can lead to the introduction of malicious code (like a "Trojan horse") into the system or change the data an agent collected on another platform.
• Denial of service: An entity consumes all available resources, preventing the execution of other entities.

These different attacks are not very different from the ones discussed above, but we need completely different security measures in order to avoid them. It is worth noting that as we have seen above, no anonymous or unauthorized agent is able to enter the system. The problem has two parts:

1. An agent should not be able to threaten in any way another agent or the platform.
2. The platform should not be able to threaten in any way any agent.

It is easy to see that there is a fundamental asymmetry between these two parts: since the platform is the entity that executes the agent, it must have some control on it, and the second part of the problem is likely to be more difficult to solve than the first one.

To ensure that an agent cannot threaten any other entity, we decided to use the JavaSeal agent platform [7]. JavaSeal is based on Java and has been developed by the Object Systems Group at the University of Geneva. The main goal of JavaSeal was security, and it is achieved by satisfying three requirements:

1. Secure execution environment for user agent: Agents are represented by seals (sets of objects and classes), and no user classes are shared with other seals. In addition, to ensure an isolation of the seals, only restricted and "safe" sets of JVM classes are shared between seals (a class is safe if it has no static variables).
2. Controlled communication between agent environments: Seals have channels that allow for synchronous interseal communication and that are the only way that seals may send or receive information.
3. Security policy enforcement for agents: Seals are hierarchically organized, and while a seal may possess any number of children seals, it may only have one parent seal. Channels can exist only between parent and child, in order to allow the parent to intercept communication between children and to enforce a security policy over children's interaction.

On the other hand, it is difficult to guarantee anything about the execution of a program on a system that you don't control.

Since the program is executed on the distant computer, it has to be intelligible sometimes. A manufacturer of DVD systems recently learned that one of its[8] DVD players had been reverse engineered, revealing the keys needed to decrypt a DVD in order to play it, despite the numerous cryptographic protections (which by the way were weak even if you were not able to find the key). This shows that "code that you don't control cannot remain secret," and this rule is especially true if you use Java, whose compiled bytecode is quite easy to disassemble, even if the time to disassemble an entire program may be quite long.

An often proposed solution is to use tamperproof hardware, but good tamperproof hardware is difficult to make. Moreover, people are usually not very keen on running "black box" systems over which they have no control. If the specifications of the system are known, it may be possible to write a software simulator of the system and force the agent to run on it.

While protecting the content of a program running on a distant host looks clearly like an impossible task, it is possible in some cases to cryptographically hide the function performed by the program. For example, imagine an agent requesting if the novartis.com domain is free, the name "novartis" being secret at that time. Instead of asking "is novartis.com free?" the agent looks at every registered domain name, computes a hash function on this name, and compares the result with a hashed name stored in its data. If the two hash values correspond, it means that the domain name is already registered -- the platform can then know what this name was, but it is not so important anymore. If no correspondence is found, the agent knows that the domain is free, but the platform has no information about which domain it was looking for. The agent doesn't know the name either and thus cannot register it but only report the information to its owner.

Research conducted on this subject [9] seems promising but for the time being remains limited and of little practical use.

The nonrepudiation problem

A very important security property in the context of electronic commerce is nonrepudiation, the impossibility for a party to deny a transaction. This is usually provided by the use of digital signatures. Signatures made by a registry to confirm an operation are nonrepudiatable. However, in our agent's context, a registrar never signs directly any request, since requests are made by his or her agent on the registry's platform and a registrar could pretend that his or her agent did not sign a request but the registry used the agent's private key to sign it. As we have seen, this may be a difficult task for the registry, but there is no good known technical solution to prevent the registrar from doing this and thus no guarantee of nonrepudiation.

The solution to this problem is actually more organizational than technical and relies on the fact that we are working in a closed market, where only known and authorized actors are operating. In this situation, an actor found guilty of fraudulent behavior would be quickly ejected from the market, and the actor's loss would certainly be greater than the gain obtained from such behavior.

It is worth noting that registries must in any case be fully trusted by the registrars since they are in charge of the domain name databases, and it is thus reasonable for the registrars to assume that the registries are fair. The system should work with a gentleman's agreement like the ones used in practice by the banks or credit card companies by allowing a short time to revoke any erroneous request.

Implementation details

A working implementation has been finished at the end of 1999, and we used it for test purposes without access to a real domain name database. Further tests were scheduled with Switch (registration service for .ch and .li domains) and CORE (Council of Registrars) to allow our prototype to access their databases in order to use it in real situations, but we have not been able to conduct these tests yet.

Cryptographic tools

The draft of the SRS protocol proposed the use of PGP [10] (Pretty Good Privacy) 5.0 to handle cryptographic issues like the signature of the requests. We decided to use GPG [11] (Gnu Privacy Guard) 1.0 instead for the requests' signatures as well as the encryptions and signatures needed for the transport of the agents. GPG went out in the beginning of September 1999 and is fully compatible with PGP. Contrary to PGP, which is no longer free for commercial use, GPG is available under the GNU General Public License (GPL), doesn't use patented algorithms, and has been developed in Europe and is thus not constrained by any export restrictions. In addition, it can easily be integrated with Java or another platform and used as a security tool.

Actually, as long as the specification of the SRS protocol and the DNX platform have not been definitely decided, we call GPG from Java as an external process. While this approach is much less efficient than using an internal library, it is much simpler and more flexible, especially since high performance was not our main goal. We'll use another system when the specifications are settled.

Key management and certification

The use of a closed market makes key certification easier. Since any actor must be known by others, no external certification is really needed. If the system were opened, trusted third parties (TTPs) would become necessary in order to guarantee key certification. The registries could easily act as TTPs, since they have a central place and must already be trusted by all users, as we've seen above. We propose elsewhere a more general model where the role of TTP is assumed by specific actors different from the registries.

The use of agents complicates key management, since private keys may move with the agents. To minimize the danger of stolen keys, each agent must carry its own, and even if two agents belong to the same entity, they cannot share a set of keys.

Conclusions and future perspectives

The design of the DNX platform shows that it is possible to use mobile agents to provide value-added services for the Internet domain name market with a reasonable level of security. This model could easily be adapted to other markets, and it requires only slight modifications to an existing system to work with mobile agents, since the communication between the agent's platform and the system can be based on already used protocols, like SRS in DNX. Several other electronic commerce applications for which security is a critical component could be envisaged from the DNX model, such as an agent-based platform for electronic auctions.

In the remaining part of the Internet domain name market, the part not covered by DNX, the relations between the user who wants to buy domains (registrant) and a registrar are by definition open. Due to the limitations we discussed above, it is unlikely that an agent's system like this one could be used in a fully opened market. However, we have studied other models and have considered opening this market, but this is not described in this paper (see [12]).

While the use of the JavaSeal kernel solves most of the security problems related to the execution of the agent, its philosophy of hiding most Java classes and allowing only strictly controlled communications between agents makes it quite difficult to program and use and limits its performance. We have to keep in mind that JavaSeal remains an experimental system. However, the quick evolution in the mobile agent's platform seems encouraging with regard to future developments and better performance in this field.

Acknowledgments

The authors would like to thank Jarle Hulaas and Prof. Jürgen Harms for their contribution to this project. The research described in this paper was funded by the Swiss National Scientific Foundation under grant SPP-ICS-ElCom 5003-054540.

References

1. Home page of the DNX project: http://cui.unige.ch/DNX/.
2. L. Gannoun, J. Hulaas, J. Francoli, S. Chachkov, F. Schütz, and J. Harms, "Mobile Agent-Based Shared Registry System for Electronic Commerce of Internet Domain Names," Proceedings of the Sixth IEEE International Workshop on Mobile Multimedia Communications (MOMUC'99), San Diego, California, USA, November 1999.
3. Crispin et al., Internet Engineering Task Force Internet Draft of CORE SRS Protocol, November 1998.
4. M.J. Wooldridge and N.R. Jennings, "Software Engineering with Agents: Pitfalls and Pratfalls," IEEE Internet Computing, May-June 1999, pp. 20-27.
5. Multicast Transport Protocols home page: http://hill.lut.ac.uk/DS-Archive/MTP.html.
6. Netscape page on SSL: http://developer.netscape.com/tech/security/ssl/protocol.html.
7. J. Vitek, C. Bryce, and W. Binder, "Designing JavaSeal or How to Make Java safe for Agents," in Electronic Commerce Objects, D. Tsichritzis (Ed.), Centre universitaire d'Informatique, University of Geneva, July 1998, pp. 105-126.
8. Quick description of the DVD technical details: http://www.eff.org/pub/Intellectual_property/DVD/dvd-bogk.html.
9. T. Sander and C.F. Tschuddin, "Protecting Mobile Agents Against Malicious Hosts," in Mobile Agents and Security, G. Vigna (Ed.), LNCS 1419, Springer-Verlag, 1998, pp. 40-60.
10. PGP international version available at http://www.pgpi.com.
11. GPG available at http://www.gnupg.org.
12. H. Häuschen, H. Stormer, and J.G. Hulaas, Secure Trading of Assigned Names and Numbers: Domain Names and Beyond, http://cui.unige.ch/DNX/public-documents/DNX-haeuschen/index.html.