1: \documentclass[twocolumn,twoside]{IEEEtran}
2: \usepackage{amsfonts}
3:
4: \begin{document}
5:
6: \title{A Public-key based Information\\Management Model for Mobile Agents}
7:
8: \author{Diego Rodr\'{\i}guez and Igor Sobrado\thanks{ D. Rodr\'{\i}guez is
9: with the Technical School of Computer Sciences (EUITIO), University of
10: Oviedo, Oviedo (Asturias), Spain. E-mail: diego@string1.ciencias.uniovi.es .
11: I. Sobrado is with the Computer Sciences Department, University of
12: Oviedo, Oviedo (Asturias), Spain. E-mail: sobrado@acm.org . Authors' names
13: appear in alphabetical order.}\thanks{This work has been submitted to the
14: IEEE for possible publication. Copyright may be transferred without
15: notice, after which this version may no longer be accessible.}}
16:
17: \markboth{IEEE Transactions On Networking, Vol. XX, No. Y, Month 2000}
18: {Rodr\'{\i}guez and Sobrado: A Public-key based Information Management
19: Model for Mobile Agents}
20:
21: \maketitle
22:
23: \begin{abstract}
24: Mobile code based computing requires development of protection schemes
25: that allow digital signature and encryption of data collected by the
26: agents in untrusted hosts. These algorithms could not rely on carrying
27: encryption keys if these keys could be stolen or used to counterfeit data
28: by hostile hosts and agents. As a consequence, both information and keys
29: must be protected in a way that only authorized hosts, that is the host
30: that provides information and the server that has sent the mobile agent,
31: could modify (by changing or removing) retrieved data. The data management
32: model proposed in this work allows the information collected by the agents
33: to be protected against handling by other hosts in the information
34: network. It has been done by using standard public-key cryptography
35: modified to support protection of data in distributed environments without
36: requiring an interactive protocol with the host that has dropped the
37: agent. Their significance stands on the fact that it is the first model
38: that supports a full-featured protection of mobile agents allowing remote
39: hosts to change its own information if required before agent returns to
40: its originating server.
41: \end{abstract}
42:
43: \begin{keywords}
44: Assurance, Asymmetric ciphers, Cryptography, Data protection, Distributed
45: networks, Information retrieval, Mobile agents.
46: \end{keywords}
47:
48: \section{Introduction}
49:
50: \PARstart{G}{lobal-networking} and world-wide communications are changing
51: computing concepts as were established some years ago. In the past,
52: information was stored in trusted hosts where data was managed. In that
53: case, it is easy to see that information security depends on the
54: protection of the hosts themselves. Protection of hosts should be
55: considered as a part of the operating systems design and not as an add-on.
56: In fact, to ignore last approach opens a wide variety of security holes in
57: modern computer systems \cite{ritchie:security}. In any case, hosts
58: protection is more advanced that mobile code protection at present time.
59: Distributed computing requires information to be managed in untrusted
60: ---and sometimes unknown--- hosts in the network; consequently, new data
61: management models must be developed for distributed environments
62: \cite{hohl:mess,sander:hosts,sobrado:otp}. Some protection schemes based
63: in the use of Partial Result Authentication Codes (PRACs) ensures a
64: \textit{perfect forward integrity\/} but does not assures backward
65: integrity \cite{yee:sanctuary}. In these cases, the mobile agent carries
66: the keys that will be used to protect the messages. Each key could be
67: applied to protect only one message being removed from the agent data area
68: after using. Even forward integrity could be compromised. For example
69: suppose that an agent follows a route ${\cal H} = \{{\rm H}_{1},
70: {\rm H}_{2}, \ldots, {\rm H}_{i}^{\rm \ast}, {\rm H}_{i+1}, \ldots,
71: {\rm H}_{j-1}, {\rm H}_{j}^{\rm \ast}, \ldots, {\rm H}_{n}\}$, where both
72: ${\rm H}_{i}^{\rm \ast}$ and ${\rm H}_{j}^{\rm \ast}$, with $i, j \in \{
73: 1, 2, \ldots, n \}$ and $i < j$, are malicious hosts. The first hostile
74: node in the route of the agent, that is ${\rm H}_{i}^{\rm \ast}$, could
75: provide a copy of the keys not removed from the mobile agent to the second
76: malicious host, ${\rm H}_{j}^{\rm \ast}$. The second host could use this
77: information to counterfeit data provided by the hosts that apply these
78: keys. This fact makes all the hosts in the subset ${\cal H'} = \{
79: {\rm H}_{i+1}, {\rm H}_{i+2}, \ldots, {\rm H}_{j-1}\} \subset {\cal H}$
80: vulnerable. The same problem will happen if the agent returns to the first
81: malicious host later, showing that backward integrity cannot be assured in
82: any case.
83:
84: The term \textit{message\/}, as applied in this paper, stands for each
85: block of information provided by the remote hosts to either other hosts or
86: mobile agents. The word \textit{field\/} identifies a chunk of the message
87: itself.
88:
89: We want to note some differences that can be found between mobile agents,
90: mobile code and intelligent agents, to show in detail the problem that
91: could be solved by using the threat described in our work:
92:
93: \begin{itemize}
94: \item\textit{Mobile agents.\/} A mobile agent is a software object that
95: have a code area and a data part. Both code and data areas will convey
96: from a host to another one but the execution thread will not be preserved.
97: Mobile agents could be easily implemented by using serialization in
98: programming languages as Java.
99:
100: \item\textit{Mobile code.\/} The most important difference between mobile
101: agents and mobile code is that the latter allows the execution thread to
102: be preserved when the agent goes from one host to the next one. As the
103: execution thread will be changed in each host visited by the mobile code,
104: to protect this area is not easy.
105:
106: \item\textit{Intelligent agents.\/} An intelligent agent is a software
107: object that have the ability of process information retrieved
108: autonomously. These agents does not require to be mobile. Intelligent
109: agents are an active field of study in \textit{artificial intelligence\/}
110: (AI) at present.
111: \end{itemize}
112:
113: A given agent could be classified in more than one of the groups described
114: above. For example, a mobile agent could be programmed in a way that
115: allows it to decide the route that it will follow by evaluating the
116: information provided by the \textit{peer\/} (remote) hosts, making it both
117: a mobile and an intelligent agent simultaneously.
118:
119: The threat we propose in our work allows an agent to be protected against
120: both malicious hosts and other agents. These hosts and agents could try to
121: make unauthorized modifications on either the code area or the data space
122: of the agent or even to remove the information provided by other hosts.
123: Our goal is to protect code and data areas against both counterfeit and
124: erasing. Our technique is based in the use of standard public-key
125: encryption algorithms ---also known as asymmetric ciphers--- instead of
126: symmetric ciphers. We will not propose nor recommend the use of a specific
127: cipher over others in our work.
128:
129: We are not developing a protection algorithm for the execution thread. The
130: execution thread is changed by each host where the mobile code arrives. As
131: a consequence, it cannot be easily protected without using a logging
132: system. In our opinion, encryption techniques could not be used to provide
133: full protection of mobile code.
134:
135: \section{Notational Conventions}
136:
137: In this section, we will introduce the notation used in our work. This
138: notation will be applied to describe digital signature and encryption of
139: data in both the agent server and the peer hosts.
140:
141: To describe the routes followed by the agents we will define the set
142: ${\cal H}^{r} = \{{\rm H}_{1}^{r}, {\rm H}_{2}^{r}, \ldots,
143: {\rm H}_{n_{r}}^{r}\}$, where $r = 1,2,3,\ldots$ and
144: $n_{r}\in\mathbb{N}$; this set will denote the $n_{r}$ hosts followed by
145: the mobile agent released by a given agent server in its $r$-th route. In
146: this set, ${\rm H}_{i}^{r}$, where $i\in\{1, 2, \ldots, n_{r}\}$ and
147: $r\in\mathbb{N}$, determines the $i$-th host in the $r$-th route followed
148: by the agent sent by the server ${\rm S}$.
149:
150: \textit{Digital signature\/}---$\!$ Digital signature of data can be used
151: to protect the information provided against counterfeiting and erasing by
152: allowing, at the same time, to be read and authenticated by other hosts.
153: It could be useful when agents are used in negotiation processes between
154: hosts. In this case, only the private/public key pairs related with the
155: remote hosts are used to protect the data stored in the agents allowing
156: the information to be read and authenticated by any host or agent without
157: a knowledge of the private-key used to digitally sign the message. We will
158: denote the digital signature of any given message ${\rm M}_{i, j}^{r}$
159: using the expression:
160: \begin{equation}
161: {\rm S}_{i, j}^{r} \stackrel{\rm def}{=}
162: f_{{\rm pri}_{{\rm H}_{i}^{r}}}
163: \left[
164: {\rm M}_{i, j}^{r}
165: \right] \enspace ,
166: \end{equation}
167: where ${\rm M}_{i, j}^{r}$ and ${\rm S}_{i, j}^{r}$ are the plain-text
168: message and its signature respectively, ${\rm pri}_{{\rm H}_{i}^{r}}$
169: identifies the private-key associated with the host ${\rm H}_{i}^{r}$, and
170: $f$ stands for the digital signature algorithm applied to protect the
171: information provided by the peer hosts against unauthorized modifications.
172:
173: The message ${\rm M}_{i, j}^{r}$ can be authenticated by using the
174: public-key associated with the $i$-th host in the agent route
175: ${\cal H}^{r}$. That public-key may be available to any host. The security
176: of the host ${\rm H}_{i}^{r}$ is not compromised by storing a copy of that
177: public-key in a public-key server. As we will shown below, the use of
178: \textit{certification authorities\/} (CAs) to authenticate the public-keys
179: itself is highly recommended. We must apply
180: \begin{equation}
181: {\rm M}_{i, j}^{r}
182: = f_{{\rm pub}_{{\rm H}_{i}^{r}}}^{-1}
183: \left[
184: {\rm S}_{i, j}^{r}
185: \right]
186: = f_{{\rm pub}_{{\rm H}_{i}^{r}}}^{-1}
187: \left[
188: f_{{\rm pri}_{{\rm H}_{i}^{r}}}
189: \left[
190: {\rm M}_{i, j}^{r}
191: \right]
192: \right]
193: \nonumber\enspace ,
194: \end{equation}
195: where ${\rm M}_{i, j}^{r}$ and ${\rm S}_{i, j}^{r}$ are the plain-text
196: message and the digital signature of ${\rm M}_{i, j}^{r}$ again,
197: ${\rm pub}_{{\rm H}_{i}^{r}}$ stands for the public-key associated with
198: the host ${\rm H}_{i}^{r}$ and $f^{-1}$ identifies the digital signature
199: authentication algorithm.
200:
201: \textit{Data encryption\/}---$\!$ A mobile agent based infrastructure
202: would require an additional security level. Suppose that a server drops an
203: agent that will retrieve information that must be covered to any host in
204: the network except the server that has released the agent itself. In this
205: case, data encryption should be used to hide the information stored in the
206: agent data area. Data encryption requires the use of an additional key
207: pair, the private/public key pair related with the agent server.
208: Encryption of data requires the use of the public-key provided by the
209: agent server to the remote hosts as a part of the mobile agent itself
210: (${\rm pub}_{\rm S}$), and the private-key associated with the remote host
211: that provides information to the agent. We will show below that the
212: private/public key pair related with the server that has released the
213: agent cannot be counterfeited without invalidating the agent itself
214: because it is a part of the code area. We will define the encryption
215: process as:
216: \begin{equation}
217: {\rm C}_{i, j}^{r} \stackrel{\rm def}{=} f_{{\rm pub}_{\rm S}}
218: \left[
219: f_{{\rm pri}_{{\rm H}_{i}^{r}}}
220: \left[
221: {\rm M}_{i, j}^{r}
222: \right]
223: \right]
224: \enspace .
225: \label{eq:encryption}
226: \end{equation}
227: In this case, ${\rm M}_{i, j}^{r}$ and ${\rm C}_{i, j}^{r}$ are the
228: plain-text message and its cipher-text respectively. The symbols
229: ${\rm pub}_{\rm S}$ and ${\rm pri}_{{\rm H}_{i}^{r}}$ in equation
230: (\ref{eq:encryption}) stand for the public-key related to the agent server
231: ${\rm S}$ and the private-key associated with the $i$-th host in the
232: $r$-th route followed by an agent dropped by the server ${\rm S}$
233: respectively. In order to decrypt the cipher-text we must use the
234: private-key associated with the agent server (${\rm pri}_{\rm S}$), and
235: the public-key provided by the peer host that has encrypted the message
236: ${\rm M}_{i, j}^{r}$:
237: \begin{eqnarray}
238: {\rm M}_{i, j}^{r}
239: &\!\!\!=\!\!\!& f_{{\rm pub}_{{\rm H}_{i}^{r}}}^{-1}
240: \left[
241: f_{{\rm pri}_{\rm S}}^{-1}
242: \left[
243: {\rm C}_{i, j}^{r}
244: \right]
245: \right]
246: \label{eq:decryption} \\
247: &\!\!\!=\!\!\!& f_{{\rm pub}_{{\rm H}_{i}^{r}}}^{-1}
248: \left[
249: f_{{\rm pri}_{\rm S}}^{-1}
250: \left[
251: f_{{\rm pub}_{\rm S}}
252: \left[
253: f_{{\rm pri}_{{\rm H}_{i}^{r}}}
254: \left[
255: {\rm M}_{i, j}^{r}
256: \right]
257: \right]
258: \right]
259: \right]
260: \nonumber\enspace .
261: \end{eqnarray}
262: The elements that appear in equation (\ref{eq:decryption}) must be
263: interpreted in the same way as shown in other equations in this section.
264: In this case, ${\rm pri}_{\rm S}$ and ${\rm pub}_{\rm S}$ are,
265: respectively, the private and the public keys for the agent server;
266: ${\rm pri}_{{\rm H}_{i}^{r}}$ and ${\rm pub}_{{\rm H}_{i}^{r}}$ are the
267: private and the public keys for the remote host ${\rm H}_{i}^{r}$. The
268: message that has been covered by using public-key cryptography is
269: ${\rm M}_{i, j}^{r}$, that is the $j$-th message provided by the $i$-th
270: host in the route followed by the agent, and the cipher-text itself is
271: ${\rm C}_{i, j}^{r}$.
272:
273: \section{Code and Data Areas Protection}
274:
275: Classical protection schemes do not allow a mobile agent to protect its
276: own code area against unauthorized modification easily. Suppose that a
277: server digitally signs the code of an agent before dropping it. This
278: server must provide copies of the public-key used to other hosts. This
279: public-key is required to authenticate the code area itself. This can be
280: done easily by providing a copy of this key to a key-server or by using a
281: CA. Obviously, the agent should be instructed to get this key showing at
282: least the address of both the server that has released it and the host
283: that stores a copy of the key. At this moment a malicious host, let us say
284: ${\rm H}_{i}^{r,{\rm \ast}}$, could change the agent code area and sign it
285: by using its own private/public key pair. It is not difficult to prove
286: that this modification will not be discovered by the remote hosts if the
287: code is changed in such a way that the agent points to the new
288: public-key. The hostile host only needs to assure that the signed code
289: area provided by the agent server is recovered before the agent returns to
290: the server that has dropped it.
291:
292: It is easy to see that code protection could not depend on classical
293: cryptography even if the keys used to authenticate this area are certified
294: and are provided by external trusted authorities. We need to develop a way
295: to link the data provided by the peer hosts with the code part of the
296: agent at the same time. This will allow us to protect data and code areas
297: simultaneously.
298:
299: Other protection threats have been proposed in recent years. For example,
300: the use of both code and data areas mess up techniques as described in
301: \cite{hohl:mess}. In this reference, Hohl recommends the use of variable
302: names that does not means anything. He also proposed that the code should
303: not be modularized (\textit{i.e.\/}, it must be written without using
304: subroutines) and to choose a data representation that makes the program
305: difficult to understand. This author proposed the use of \textit{variable
306: recomposition\/} techniques, conversion of \textit{compile-time control
307: flow elements\/} into run-time data dependent jumps and the
308: \textit{insertion of dead code\/}, that is code that will not be executed
309: when the agent is running, into the agents. These techniques are based in
310: mixing up the contents of the variables and creating new variables that
311: contains a few bits of data of some of the original variables. These are
312: recovered by changing the way the code of the agent handles the access to
313: the variables. Another alternative could be to develop a secure
314: infrastructure for mobile agents \cite{yee:sanctuary}. The use of
315: \textit{encrypted functions\/}\footnote{By using mathematical functions
316: with homomorphic properties. An example is the exponential function where
317: the addition and mixed multiplication between $x, y \in \mathbb{C}$ could
318: be obtained without any explicit knowledge of $x$ providing ${\rm exp}
319: \left[ x \right]$ instead of $x$ in:
320: \begin{eqnarray}
321: {\rm exp} \left[ x + y \right] &\!\!\!=\!\!\!&
322: {\rm exp} \left[ x \right] \cdot {\rm exp} \left[ y \right] \nonumber\cr
323: {\rm exp} \left[ x \cdot y \right] &\!\!\!=\!\!\!&
324: \left( {\rm exp} \left[ x \right] \right) ^{y}
325: \enspace ,
326: \end{eqnarray}
327: allowing us to represent the encrypted program as a polynomial. An
328: important requeriment is that these functions should not be easily
329: inverted. At present, there are not known one-way homomorphic functions.}
330: and \textit{execution environments\/} (EE) with a fully separated
331: interpreter\footnote{Where each agent have its own address space.} has
332: been proposed in \cite{sander:towards,tschudin:security}. At present, we
333: do not have a way of protecting the code against unauthorized modification
334: using encrypted functions because these techniques could not be easily
335: applied to real agent systems. We need protection schemes that do not rely
336: on hiding the algorithms used in code handling or on building trusted
337: environments for agent execution. Another problem is that the execution of
338: encrypted functions requires the development of one-way homomorphic
339: functions. These functions are unknown at present.
340:
341: In order to protect both the message provided by the remote host, that we
342: have denoted by ${\rm M}_{i, j}^{r}$, and the mobile agent code area we
343: propose that each host must obtain the next field:
344: \begin{equation}
345: {\rm M}_{{\rm CRC}_{i, j}}^{r} \stackrel{\rm def}{=}
346: \underbrace{
347: {\rm crc}
348: \left[
349: {\rm pub}_{\rm S}
350: \right]
351: + {\rm crc}
352: \left[
353: f_{{\rm pri}_{\rm S}}
354: \left[
355: {\rm M}_{\rm code}^{r}
356: \right]
357: \right]}_{\rm provided\,by\,the\,agent\,server\, S}
358: + {\rm F}_{i, j}^{r}
359: \enspace ,
360: \label{eq:crc}
361: \end{equation}
362: where $f_{{\rm pri}_{\rm S}} \left[ {\rm M}_{\rm code}^{r} \right]$ stands
363: for the digital signature of the code area ${\rm M}_{\rm code}^{r}$. The
364: code area includes both the agent code and an identification number (ID)
365: for the agent. Therefore, this identification number is unique because it
366: is generated from the agent server identificator, which is unique in the
367: network (for example the IP-address in IPv4 or IPv6 format of the agent
368: server itself), and an agent number, which is unique for that server. In
369: our case, we will obtain ${\rm ID} = {\rm server}_{\rm ID} +
370: {\rm agent}_{\rm ID}$. Obviously, $f_{{\rm pri}_{\rm S}} \left[
371: {\rm M}_{\rm code}^{r} \right]$ could not be evaluated in the remote
372: hosts. To obtain this field, a knowledge of the private-key associated
373: with the server that has dropped the agent (${\rm pri}_{\rm S}$) is
374: required. This field must be provided as a part of the agent in a way that
375: cannot be falsified. To manage it, a field ${\rm F}_{i, j}^{r}$ must be
376: added by the host ${\rm H}_{i}^{r}$ to the field
377: ${\rm M}_{{\rm CRC}_{i, j}}^{r}$ shown in equation (\ref{eq:crc}). This
378: field must change with each message provided in a way that it is unique
379: for that host/agent pair. The code part must be authenticated by comparing
380: its digital signature with the signature carried by the agent by each peer
381: host before accepting it. The \textit{cyclic redundancy check\/} (CRC) of
382: both the public-key associated with the agent server and the signature of
383: the agent code in (\ref{eq:crc}) can be obtained by each remote host by
384: using a hash algorithm. This information must be matched with the CRCs of
385: both the public-key of the agent server and the digital signature provided
386: as a part of the data area.
387:
388: In this section the term \textit{improved\/} (as appears in both
389: \textit{improved digital signature\/} and \textit{improved data
390: encryption\/}) stands for digital signature and encryption processes that
391: include information about the mobile agent code area. In fact, information
392: about the code part of the agent will be included by each peer host in the
393: field ${\rm M}_{{\rm CRC}_{i, j}}^{r}$, as shown in equation
394: (\ref{eq:crc}), allowing remote hosts to detect unauthorized modifications
395: of the code part of the agents. \textit{Partial data encryption\/} will
396: also provide a signed copy of the field ${\rm M}_{{\rm CRC}_{i, j}}^{r}$.
397: In this case, both the field ${\rm M}_{{\rm CRC}_{i, j}}^{r}$ and the
398: message ${\rm M}_{i, j}^{r}$ will be digitally signed but only the message
399: ${\rm M}_{i, j}^{r}$ itself will be encrypted, allowing each host to
400: detect code tampering but protecting information against reading by
401: unauthorized hosts at the same time.
402:
403: \textit{Improved digital signature\/}---$\!$ In our opinion it is possible
404: to protect both the agent code area and the information provided by the
405: host itself simultaneously. To manage it, the field
406: ${\rm M}_{{\rm CRC}_{i, j}}^{r}$ must be used. This field must be stored
407: as a part of each message provided to the mobile agents before being
408: digitally signed:
409: \begin{equation}
410: {\rm S}_{i, j}^{r} = f_{{\rm pri}_{{\rm H}_{i}^{r}}}
411: \left[
412: {\rm M}_{{\rm CRC}_{i, j}}^{r} + {\rm M}_{i, j}^{r}
413: \right]
414: \enspace ;
415: \end{equation}
416: this step assures data integrity while avoiding the possibility to
417: overwrite a new message provided by a remote host with an old one
418: provided to another mobile agent in the past. The information protected in
419: this way is authenticated by applying the public-key
420: ${\rm pub}_{{\rm H}_{i}^{r}}$ of the host that has signed it:
421: \begin{eqnarray}
422: {\rm M}_{{\rm CRC}_{i, j}}^{r} + {\rm M}_{i, j}^{r}
423: &\!\!\!=\!\!\! & f_{{\rm pub}_{{\rm H}_{i}^{r}}}^{-1}
424: \left[
425: {\rm S}_{i, j}^{r}
426: \right] \\
427: &\!\!\!=\!\!\!& f_{{\rm pub}_{{\rm H}_{i}^{r}}}^{-1}
428: \left[
429: f_{{\rm pri}_{{\rm H}_{i}^{r}}}
430: \left[
431: {\rm M}_{{\rm CRC}_{i, j}}^{r} + {\rm M}_{i, j}^{r}
432: \right]
433: \right] \nonumber\enspace .
434: \end{eqnarray}
435:
436: \textit{Improved data encryption\/}---$\!$ The information about the code
437: area of the mobile agent obtained by using (\ref{eq:crc}) will be
438: added to the message provided by the remote host. To encrypt a message for
439: the agent server we must apply the next algorithm to the message itself:
440: \begin{equation}
441: {\rm C}_{i, j}^{r} = f_{{\rm pub}_{\rm S}}
442: \left[
443: f_{{\rm pri}_{{\rm H}_{i}^{r}}}
444: \left[
445: {\rm M}_{{\rm CRC}_{i, j}}^{r} + {\rm M}_{i, j}^{r}
446: \right]
447: \right] \enspace .
448: \end{equation}
449: In order to recover the full message, ${\rm M}_{{\rm CRC}_{i, j}}^{r} +
450: {\rm M}_{i, j}^{r}$, the agent server should apply its own private-key,
451: ${\rm pri}_{\rm S}$, and the public-key provided by the host that has
452: encrypted the message, ${\rm pub}_{{\rm H}_{i}^{r}}$, obtaining:
453: \begin{equation}
454: {\rm M}_{{\rm CRC}_{i, j}}^{r} + {\rm M}_{i, j}^{r} =
455: f_{{\rm pub}_{{\rm H}_{i}^{r}}}^{-1}
456: \left[
457: f_{{\rm pri}_{\rm S}}^{-1}
458: \left[
459: {\rm C}_{i, j}^{r}
460: \right]
461: \right]
462: \enspace .
463: \end{equation}
464: The main disadvantage of this method is that the code can be counterfeited
465: in such a way that only the agent server knows that it has been falsified.
466: If a part of ${\rm C}_{i, j}^{r}$ is not encrypted, but is digitally
467: signed, all the hosts in the route of the agent will have a way to
468: determine whether the code area or other data in the agent have been
469: falsified by any host.
470:
471: \textit{Partial data encryption\/}---$\!$ A better answer to the problem
472: of data encryption is to provide information publically about the CRC of
473: both the public-key related with the agent server (${\rm pub}_{\rm S}$)
474: and the signature of the agent code, $f_{{\rm pri}_{\rm S}} \left[
475: {\rm M}_{\rm code}^{r} \right]$. It is possible to do it and, at the same
476: time, to hide the message in such a way that only the authorized host (the
477: agent server) could decrypt it. We propose to partially encrypt a
478: digitally signed message using:
479: \begin{equation}
480: {\rm C}_{i, j}^{r} = f_{{\rm pri}_{{\rm H}_{i}^{r}}}
481: \left[
482: {\rm M}_{{\rm CRC}_{i, j}}^{r} + f_{{\rm pub}_{\rm S}}
483: \left[
484: {\rm M}_{i, j}^{r}
485: \right]
486: \right]
487: \enspace ;
488: \end{equation}
489: assuring that the code area cannot be changed by a malicious host because
490: each one can authenticate the CRC of the digital signature, provided by
491: the agent server using (\ref{eq:crc}), and the public-key of that server
492: simultaneously. This information can be verified by any host but the
493: message ${\rm M}_{i, j}^{r}$ can only be decrypted using the private-key
494: of the agent server, ${\rm pri}_{\rm S}$. We propose to apply the next set
495: of equations to check the code and data areas of the agent and decrypt the
496: message:
497: \begin{eqnarray}
498: {\rm M}_{{\rm CRC}_{i, j}}^{r} + f_{{\rm pub}_{\rm S}}
499: \left[
500: {\rm M}_{i, j}^{r}
501: \right]
502: &\!\!\!=\!\!\!& f_{{\rm pub}_{{\rm H}_{i}^{r}}}^{-1}
503: \left[
504: {\rm C}_{i, j}^{r}
505: \right]
506: \label{eq:certify}\\
507: {\rm M}_{i, j}^{r}
508: &\!\!\!=\!\!\!& f_{{\rm pri}_{\rm S}}^{-1}
509: \left[
510: f_{{\rm pub}_{\rm S}}
511: \left[
512: {\rm M}_{i, j}^{r}
513: \right]
514: \right] \enspace .
515: \label{eq:addec}
516: \end{eqnarray}
517: The former equation (\ref{eq:certify}) can be used by any host because the
518: public-key related with the $i$-th host in the $r$-th route followed by an
519: agent sent by the server ${\rm S}$ (${\rm pub}_{{\rm H}_{i}^{r}}$) is
520: available publically to all the hosts that need it. This equation will be
521: required to check data and code integrity at the same time. Equation
522: (\ref{eq:addec}) is applied by the agent server using its own private-key,
523: ${\rm pri}_{\rm S}$, to decrypt the information provided by the host ${\rm
524: H}_{i}^{r}$, after checking the cipher-text by applying
525: (\ref{eq:certify}).
526:
527: \section{Public-key Propagation}
528:
529: One of the main goals of our work is to provide a threat that allows
530: mobile agents to be protected against attacks like those described in
531: Section V-A. We propose to use public-key ciphers, also known as
532: asymmetric cryptosystems, instead of symmetric ciphers because the latter
533: allows a simplified key management in distributed environments.
534: Public-keys can be shared between hosts in a network without requiring
535: secure communication channels like these obtained using, for example, the
536: \textit{Transport Layer Security\/} (TLS) protocol. Detailed information
537: about the TLS protocol can be found in \cite{dierks:tls,lawrence:tls}.
538:
539: Some important requeriments must be considered in the development of a
540: public-key propagation infrastructure for mobile agents:
541:
542: \begin{itemize}
543: \item\textit{Certification authorities.\/} It is easy to see that
544: uncertified public-keys cannot be trusted. It is not a good practice to
545: send keys directly to the servers that need them. We need a network
546: infrastructure that allows the nodes to assure what host owns each
547: private/public key pair. For example middleman attack, the greatest known
548: vulnerability of public-key based ciphers, can be avoided by using a
549: trusted third party to verify and sign the keys transmitted over the
550: network.
551:
552: \item\textit{Non-interactive protocol.\/} As pointed out it
553: \cite{sander:towards} a security model for mobile agents should conceive
554: protocols that require minimal interaction between the agent and the
555: server that has sent it. The server may want to go off-line, consequently,
556: the public-key should be provided by an independent host. Our threat
557: allows the public-key related with the agent server (${\rm pub}_{\rm S}$)
558: to be provided as a part of the agent.
559: \end{itemize}
560:
561: Our threat to protect mobile agents offers some important advantages too.
562:
563: \begin{itemize}
564: \item\textit{Secure communication channels are not required.\/} This is a
565: common advantage of public-key cryptography. As only public-keys are
566: transmitted over the network untrusted communication channels can be
567: established to share the keys. These keys cannot be used to falsify
568: information or decrypt data provided to the agents.
569:
570: \item\textit{We do not need to know what host owns each public-key.\/}
571: Obviously, this fact is only true if different access privileges are not
572: assigned to each agent in function of the server that has released it. If
573: different access permissions are required CAs must be used to authenticate
574: the keys provided to the remote hosts and to assign the right access
575: privileges to each agent server.
576: \end{itemize}
577:
578: Certified public-keys are required even if different access permissions
579: are not assigned to mobile agents in function of the server that has
580: dropped it. In fact, each peer host must identify other hosts in the
581: network in soon a way that it does not allows host impersonation
582: techniques. Trusted third parties are needed to avoid well known threats
583: like the middleman attack. We must consider that changing the public-keys
584: carried by mobile agents ---the public-keys associated with the agents
585: servers--- will invalidate data retrieved by the agents. If the
586: information stored in the mobile agent data area is removed from the agent
587: when this public-key is falsified other hosts will not have a way to
588: determine that the agent have been modified without authorization. But
589: this fact will be discovered by the agent server after the agent return.
590: These keys does not require to be authenticated using a CA. Changing
591: public-key for a given agent must be avoided once they have been provided
592: to the \textit{route servers\/} (RSs).
593:
594: As we noted in Section III, both code and data areas can be protected
595: against counterfeiting and erasing by malicious hosts and agents. This can
596: be achieved by adding a field ${\rm M}_{{\rm CRC}_{i, j}}^{r}$ to each
597: message retrieved by a mobile agent as presented in (\ref{eq:crc}). This
598: field, ${\rm M}_{{\rm CRC}_{i, j}}^{r}$, will provide information about
599: both the code part of the agent and the public-key of its originating
600: server. This field will be stored in such a way that it does not allow
601: changing the code of the agent without invalidating it.
602:
603: Each agent have its own ID to avoid the possibility of overwriting the
604: information provided by peer hosts with old data retrieved by other agents
605: sent by the same server. This field is stored as a part of the code area.
606: As a consequence, ${\rm crc} \left[ f_{{\rm pri}_{\rm S}} \left[
607: {\rm M}_{\rm code}^{r} \right] \right]$ changes when new agents are
608: dropped. Even obsolete information provided to the same agent in the past
609: cannot be used to cover new data. Each host must generate a field, we
610: called ${\rm F}_{i, j}^{r}$, unique for each message. All these fields
611: should be sent to the RSs:
612: \begin{eqnarray}
613: {\rm F}_{i}^{r}
614: & \!\!\!=\!\!\! & {\rm ID} + {\rm F}_{i, 1}^{r} + {\rm F}_{i, 2}^{r}
615: + \ldots + {\rm F}_{i, m_{i}^{r}}^{r} \cr
616: & \!\!\!=\!\!\! & {\rm ID} + \sum_{j=1}^{m_{i}^{r}} {\rm F}_{i, j}^{r}
617: \enspace ,
618: \label{eq:idmess}
619: \end{eqnarray}
620: where ${\rm ID}$ is the agent identification number mentioned above. The
621: field ${\rm F}_{i}^{r}$ must be sent to RSs digitally signed by applying:
622: \begin{equation}
623: {\rm S}_{{\rm fields}_{i}}^{r} =
624: f_{{\rm pri}_{{\rm H}_{i}^{r}}}
625: \left[
626: {\rm F}_{i}^{r}
627: \right]
628: \enspace ,
629: \end{equation}
630: using the private/public key pair for the host that provides that
631: information. Any host can check each message provided by ${\rm H}_{i}^{r}$
632: by using the ${\rm F}_{i, j}^{r}$ fields, where $i \in \{1, 2, \ldots,
633: n_{r}\}$ and $j = 1, 2, \ldots, m_{i}^{r}$, stored in ${\rm F}_{i}^{r}$.
634: Those fields must be authenticated by using:
635: \begin{equation}
636: {\rm F}_{i}^{r} =
637: f_{{\rm pub}_{{\rm H}_{i}^{r}}}^{-1}
638: \left[
639: {\rm S}_{{\rm fields}_{i}}^{r}
640: \right] =
641: f_{{\rm pub}_{{\rm H}_{i}^{r}}}^{-1}
642: \left[
643: f_{{\rm pri}_{{\rm H}_{i}^{r}}}
644: \left[
645: {\rm F}_{i}^{r}
646: \right]
647: \right]
648: \enspace .
649: \end{equation}
650: To assure the integrity of the message ${\rm F}_{i}^{r}$ each RS should
651: send a random message to the host that wants to provide a new (or an
652: updated) message ${\rm F}_{i}^{r}$. This random message must be digitally
653: signed and returned to the RS that released it. The random message
654: signature must be checked before the RS accepts ${\rm F}_{i}^{r}$. In
655: other case, a malicious host can provide an obsolete message
656: ${\rm F}_{i}^{r, {\rm \ast}}$ to the RSs overwriting the mobile agent data
657: area with old information corresponding to the false message
658: ${\rm F}_{i}^{r, {\rm \ast}}$ simultaneously.
659:
660: \section{Attacks against Mobile Agents Infrastructures}
661:
662: In this section we classify the attacks that is possible to try against
663: the mobile agents and other hosts in the network. We show how our
664: protection threat allows us to protect the agents and, in some cases, even
665: remote hosts against these attacks.
666:
667: \subsection{Attacks against Mobile Agents}
668:
669: The main goal of our investigation is to protect the mobile agents against
670: both malicious hosts and other agents that can counterfeit the code part
671: and/or data areas of the agents. These hostile agents and hosts can try to
672: remove information carried by the agents too. As noted, these attacks
673: could arrive from both other agents and the hosts where the agents are
674: stored. In both cases, we will protect the agent using the same threat.
675:
676: \subsubsection{Attacks against the Code Part}
677:
678: As we shown in Section III the agent code area can be protected by adding
679: two CRCs to each message provided by the peer hosts. These CRCs provides
680: information that allows peer hosts to authenticate both the public-key
681: associated with the agent server and the digital signature of the code
682: area of the agent, that has been provided by the agent server itself.
683: These fields must be matched with each message stored in the data area by
684: the hosts followed in the agent trip, as appears in the set ${\cal
685: H}^{r}$. At last, each host authenticates the code area of the agent too
686: before running it using that digital signature previously checked. As both
687: the CRC related with the digital signature of the code area and the CRC
688: for the public-key of the agent server cannot be changed during agent
689: trip, but the latter is unique for a given agent, data area is protected
690: at the same time. As a consequence, the attacks described below can be
691: avoided.
692:
693: \subsubsection{Attacks against the Data Area}
694:
695: The attacks against the information carried by mobile agents can be
696: classified in three groups: (\textit{i\/}) attacks trying to erase data
697: carried by the agents (also known as a mobile agent ``brainwashing'' in
698: bibliography), (\textit{ii\/}) attacks trying to falsify data provided by
699: other hosts and (\textit{iii\/}) attacks trying to uncover non-public
700: information carried by the agents.
701:
702: \textit{Removing information\/}---$\!$ To avoid a mobile agent
703: ``brainwash'' each host must provide information about the number of
704: messages stored in a particular agent to the RSs as we described in
705: Section IV. It is easy to see that all the information needed to protect
706: the data area cannot be stored in the agent. Suppose for example that a
707: mobile agent carries a set of signed messages
708: \begin{eqnarray}
709: {\cal D}^{r} = \{
710: {\rm S}_{1, 1}^{r}, {\rm S}_{1, 2}^{r}, \ldots, {\rm S}_{1, m_{1}^{r}}^{r},
711: {\rm S}_{2, 1}^{r}, {\rm S}_{2, 2}^{r}, \ldots, {\rm S}_{2, m_{2}^{r}}^{r},
712: \ldots, \cr
713: {\rm S}_{i, 1}^{r}, {\rm S}_{i, 2}^{r}, \ldots, {\rm S}_{i, j}^{r}, \ldots,
714: {\rm S}_{i, m_{i}^{r}}, \ldots, \cr
715: {\rm S}_{n_{r}, 1}^{r}, {\rm S}_{n_{r}, 2}^{r},
716: \ldots, {\rm S}_{n_{r}, m_{n_{r}}^{r}}^{r} \}
717: \enspace ,
718: \label{eq:dasgn}
719: \end{eqnarray}
720: in its data area. The set ${\cal D}^{r}$ in (\ref{eq:dasgn}) stands for
721: the signed data area of the $r$-th agent released by a server. All the
722: messages are signed in a way that only the hosts that has provided these
723: messages can change its contents. If the RSs do not provides information
724: about the number of messages given by each host to the agent server or,
725: more generally to other hosts that requests it, any hostile node (any
726: malicious host in the network) can remove a message, let us say
727: ${\rm S}_{i, j}^{r}$ where $i \in \{1, 2, \ldots, n_{r}\}$ identifies the
728: host that provides the message removed and $j \in \{1, 2, \ldots,
729: m_{i}^{r}\}$ stands for the $j$-th message provided by that host. In this
730: case, the set of messages carried by the agent, ${\cal D}^{r}$, is changed
731: to
732: \begin{eqnarray}
733: {\cal D}^{r, {\rm \ast}} = \{
734: {\rm S}_{1, 1}^{r}, {\rm S}_{1, 2}^{r}, \ldots, {\rm S}_{1, m_{1}^{r}}^{r},
735: {\rm S}_{2, 1}^{r}, {\rm S}_{2, 2}^{r}, \ldots, {\rm S}_{2, m_{2}^{r}}^{r},
736: \ldots, \nonumber\cr
737: {\rm S}_{i, 1}^{r}, {\rm S}_{i, 2}^{r},
738: \stackrel{\wedge ^{{\rm S}_{i, j}^{r}}}{\ldots},
739: {\rm S}_{i, m_{i}^{r}}, \ldots, \cr
740: {\rm S}_{n_{r}, 1}^{r}, {\rm S}_{n_{r}, 2}^{r}, \ldots,
741: {\rm S}_{n_{r}, m_{n_{r}}^{r}}^{r} \}
742: \enspace ,
743: \end{eqnarray}
744: without invalidating the data area. In this case, the set
745: ${\cal D}^{r, {\rm \ast}}$ is the falsified data area of the agent. The
746: same problem happens when encryption is used if the number of messages
747: carried by a mobile agent is not provided to the RSs in any way. In this
748: case the encrypted data area of the agent:
749: \begin{eqnarray}
750: {\cal D}^{r} = \{
751: {\rm C}_{1, 1}^{r}, {\rm C}_{1, 2}^{r}, \ldots, {\rm C}_{1, m_{1}^{r}}^{r},
752: {\rm C}_{2, 1}^{r}, {\rm C}_{2, 2}^{r}, \ldots, {\rm C}_{2, m_{2}^{r}}^{r},
753: \ldots, \cr
754: {\rm C}_{i, 1}^{r}, {\rm C}_{i, 2}^{r}, \ldots, {\rm C}_{i, j}^{r}, \ldots,
755: {\rm C}_{i, m_{i}^{r}}, \ldots, \cr
756: {\rm C}_{n_{r}, 1}^{r}, {\rm C}_{n_{r}, 2}^{r},
757: \ldots, {\rm C}_{n_{r}, m_{n_{r}}^{r}}^{r} \}
758: \enspace ,
759: \label{eq:daencr}
760: \end{eqnarray}
761: can be modified by removing one of the cipher-texts provided by the remote
762: hosts. For example, the cipher-text that corresponds to the $j$-th message
763: provided by the $i$-th host in the agent route can be erased by changing
764: the agent data area to:
765: \begin{eqnarray}
766: {\cal D}^{r, {\rm \ast}} \!=\! \{
767: {\rm C}_{1, 1}^{r}, {\rm C}_{1, 2}^{r}, \ldots, {\rm C}_{1, m_{1}^{r}}^{r},
768: {\rm C}_{2, 1}^{r}, {\rm C}_{2, 2}^{r}, \ldots, {\rm C}_{2, m_{2}^{r}}^{r},
769: \ldots, \nonumber\cr
770: {\rm C}_{i, 1}^{r}, {\rm C}_{i, 2}^{r},
771: \stackrel{\wedge ^{{\rm C}_{i, j}^{r}}}{\ldots},
772: {\rm C}_{i, m_{i}^{r}}, \ldots, \cr
773: {\rm C}_{n_{r}, 1}^{r}, {\rm C}_{n_{r}, 2}^{r}, \ldots,
774: {\rm C}_{n_{r}, m_{n_{r}}^{r}}^{r} \}
775: \enspace .
776: \end{eqnarray}
777: Even if information about the number of messages carried by the agent is
778: provided in a way that an hostile peer host cannot change it, data area
779: can be altered by overwriting it with a \textit{bit-copy\/} of an old data
780: area.
781:
782: To avoid attacks based in the techniques described above we propose to
783: send information about the number of messages provided to the agent to the
784: RSs shown in the code area of the mobile agent itself. These hosts cannot
785: be changed without invalidating the agent itself. A copy of the fields
786: ${\rm F}_{i, j}^{r}$, as shown in equation (\ref{eq:crc}), is all the
787: information needed to manage it; in fact, these fields are required to
788: authenticate data provided by each host visited by the mobile agent as
789: shown above.
790:
791: \textit{Counterfeit of data\/}---$\!$ Even if data have been digitally
792: signed or encrypted information provided can be falsified. As noted above,
793: data area can be protected against ``brainwashing'' by storing information
794: about the amount of messages provided by each host visited by the agent in
795: separated hosts. We need a way to protect the information provided by peer
796: hosts to the agent against being overwritten with old signed data provided
797: by those hosts in the past. In Section III we propose to link data
798: provided as a part of the agent, the fields in
799: ${\rm M}_{{\rm CRC}_{i, j}}^{r}$ as shown in (\ref{eq:crc}), with each
800: messages retrieved by the agent. If this field is not included any hostile
801: host can change the data area of the agent as appears in (\ref{eq:dasgn}),
802: overwriting a valid signed message ${\rm M}_{i, j}^{r}$ with an old
803: message signed by the same host using the same private/public key pair,
804: let us say ${\rm M}_{i, j}^{r, {\rm \ast}}$:
805: \begin{eqnarray}
806: {\cal D}^{r, {\rm \ast}} = \{
807: {\rm S}_{1, 1}^{r}, {\rm S}_{1, 2}^{r}, \ldots, {\rm S}_{1, m_{1}^{r}}^{r},
808: {\rm S}_{2, 1}^{r}, {\rm S}_{2, 2}^{r}, \ldots, {\rm S}_{2, m_{2}^{r}}^{r},
809: \ldots, \nonumber\cr
810: {\rm S}_{i, 1}^{r}, {\rm S}_{i, 2}^{r}, \ldots,
811: {\rm S}_{i, j}^{r,{\rm \ast}}, \ldots, {\rm S}_{i, m_{i}^{r}}, \ldots, \cr
812: {\rm S}_{n_{r}, 1}^{r}, {\rm S}_{n_{r}, 2}^{r},
813: \ldots, {\rm S}_{n_{r}, m_{n_{r}}^{r}}^{r} \}
814: \enspace .
815: \end{eqnarray}
816: The same problem happens with encrypted messages if the field ${\rm
817: M}_{{\rm CRC}_{i, j}}^{r}$, obtained by applying (\ref{eq:crc}), is not
818: provided as a part of the messages. In this case, the encrypted data area
819: of the mobile agent in (\ref{eq:daencr}) can be counterfeited by changing
820: one of the cipher-texts provided by the remote hosts, for example the
821: message ${\rm C}_{i, j}^{r}$ can be changed to
822: ${\rm C}_{i, j}^{r, {\rm \ast}}$:
823: \begin{eqnarray}
824: {\cal D}^{r, {\rm \ast}} \!=\! \{
825: {\rm C}_{1, 1}^{r}, {\rm C}_{1, 2}^{r}, \ldots, {\rm C}_{1, m_{1}^{r}}^{r},
826: {\rm C}_{2, 1}^{r}, {\rm C}_{2, 2}^{r}, \ldots, {\rm C}_{2, m_{2}^{r}}^{r},
827: \ldots, \nonumber\cr
828: {\rm C}_{i, 1}^{r}, {\rm C}_{i, 2}^{r}, \ldots,
829: {\rm C}_{i, j}^{r,{\rm \ast}}, \ldots, {\rm C}_{i, m_{i}^{r}}, \ldots, \cr
830: {\rm C}_{n_{r}, 1}^{r}, {\rm C}_{n_{r}, 2}^{r},
831: \ldots, {\rm C}_{n_{r}, m_{n_{r}}^{r}}^{r} \}
832: \enspace .
833: \end{eqnarray}
834: To avoid information provided by peer hosts to be overwritten by using a
835: bit-copy with old signed data obtained in the same trip we propose to add
836: another field to ${\rm M}_{{\rm CRC}_{i, j}}^{r}$. This field is
837: introduced in Section III. Each host can provide a field in each message.
838: We denoted this field as ${\rm F}_{i, j}^{r}$. This field is changed when
839: the remote host wants to sign or encrypt a new message for the agent. This
840: field will be provided to the RSs and must be matched against the copies
841: stored in ${\rm F}_{i, j}^{r}$ by each host that wants to check data and
842: code integrity. Each host visited by the agent provides a set of fields
843: ${\rm F}_{i, j}^{r}$, where $j = 1, 2, \ldots, m_{i}^{r}$ to the RSs as
844: presented in (\ref{eq:idmess}).
845:
846: \textit{Cryptanalysis\/}---$\!$ In our work we propose to protect data
847: provided by using standard cryptographic techniques that can be attacked
848: by using cryptanalysis\footnote{Two powerful techniques to attack ciphers,
849: known as \textit{differential\/} and \textit{linear\/} cryptanalysis, were
850: elaborated and are being currently used. The former was developed by Adi
851: Shamir and Eli Biham of Technion Israel Institute of Technology. The
852: latter was introduced by Mitsuru Matsui of Mitsubishi Electric
853: Corporation.}. We are not making assumptions about the encryption
854: algorithms used to cover data nor the keys length that may vary in
855: function of the security requirements. As noted in
856: \cite{zimmermann:cryptography}, the fact that public-key based ciphers
857: allows predictable patterns to survive the encryption process making this
858: technology vulnerable to cryptanalysis is well known to cryptanalysts; as
859: a consequence, standard compression techniques should be applied before
860: encryption to increase data security.
861:
862: \textit{Middleman attack\/}---$\!$ The man-in-the-middle attack is
863: probably the greatest known vulnerability of asymmetric cryptosystems.
864: Mobile agent based infrastructures can be attacked by using a middleman
865: attack variant. In this case, a malicious host will intercept both the
866: public-key send to the RSs by the remote host and the agent itself. This
867: host will generate a private/public key pair to falsify data provided by
868: that host and provide a copy of the false public-key to the RSs. To avoid
869: the attacks based on this threat the use of CAs to verify and sign the
870: keys used by the hosts to protect its own data is recommended.
871:
872: \subsubsection{Attacks against the Agents itself}
873:
874: The mobile agents can be attacked in a way that do not require to modify
875: either the code area or the data part of the agents. The main goal of
876: these attacks can be to damage the agent infrastructure itself by
877: destroying the agents or releasing new agents instead of the original one.
878:
879: \textit{Removing agents\/}---$\!$ Any malicious host can remove the agents
880: when arrive to it. There are no-way to avoid this attack against the
881: agents but or protection threat allows other host to try to discover what
882: host has killed the agent by requesting information about the route
883: followed by the agent.
884:
885: \textit{Releasing new agents\/}---$\!$ A hostile host can remove all the
886: information stored in the mobile agent and change the code area. Modifying
887: the code area requires gathering a fake private/public key pair for the
888: agent server but now it is possible because all the
889: ${\rm M}_{{\rm CRC}_{i, j}}^{r}$ fields have been removed from the data
890: area of the agent. The new private/public key pair can be used to sign a
891: modified code area of the agent. This fact can be discovered, at least, by
892: the server that has released the agent when it comes back. If other hosts
893: have a copy of the public-key of the agent server, either obtained by
894: other channels or sent in the past, these hosts can discover the
895: unauthorized modification of the agent too.
896:
897: \subsection{Attacks against Peer Hosts}
898:
899: Our goal is to protect mobile agents against attacks from both peer hosts
900: and other agents. We are not trying to develop a threat to protect hosts
901: against malicious agents. Attacks against remote hosts could be initiated
902: from both agents and hosts.
903:
904: The code area protection allows an agent to be protected against malicious
905: changes that could affect how it works. At the same time, the code
906: protection allows a host to be protected against \textit{Denial of
907: Service\/} (DoS) attacks by agent cloning in the sense that the number of
908: clones could be easily verified by using the agent identification number
909: described above. This allows a host to protect itself by controlling the
910: resources provided to the agents in a \textit{per-agent\/} basis. The
911: agent identification number allows a host to identify the number of clones
912: of a given agent.
913:
914: The code protection threat proposed in our work do not permits a hostile
915: host to change the code part of an agent provided by an agent server
916: without invalidating it but, obviously, this host could release its own
917: malicious agents.
918:
919: \section{Conclusions}
920:
921: Mobile agents are an extremely vulnerable piece of software because they
922: are executed in untrusted environments. Both code and data areas must be
923: protected against malicious hosts and agents. The former requires
924: techniques that does not allow a malicious host to hide the identity of
925: the real agent owner. The latter requires information provided by remote
926: hosts to be protected against counterfeit and erasing. The main advantages
927: of the algorithm proposed in this paper are that:
928:
929: \begin{itemize}
930: \item\textit{Secure communication channels are not required\/} allowing a
931: mobile agent to be transmitted over untrusted channels and even stored in
932: malicious hosts where the agent will be shown as plain-text even if
933: trusted communication channels between hosts are established.
934:
935: \item\textit{Both code and data areas are protected\/} against counterfeit
936: and erasing; consequently, mobile agents are a more secure and robust
937: platform.
938:
939: \item\textit{Each host could change its own information\/} when required.
940: This allows a host to update information provided permitting the
941: development of more sophisticated agent-based applications, where
942: negotiation between agents and hosts is required.
943: \end{itemize}
944:
945: We hope that our protection scheme allows mobile agent based
946: infrastructures to be protected against other attacks based on threats
947: not covered in this article or even unknown at present. If this can be
948: achieved, our threat could be a good design principle for mobile agent
949: based information networks.
950:
951: \section*{Acknowledgments}
952:
953: The authors would like to thank Dr. Agust\'{\i}n Nieto, Dr. Jos\'e Manuel
954: Noriega and Dr. M.~\'A.~R. Osorio for reviewing the draft of the article,
955: recommend us the use of the notation proposed by the \textit{American
956: Mathematical Society\/} (AMS) in this work and provide us a place to work.
957: Without their many helpful comments this work would not be possible.
958:
959: \nocite{*}
960: \bibliographystyle{IEEE}
961: % \bibliography{paper}
962:
963: \begin{thebibliography}{10}
964:
965: \bibitem{ritchie:security}
966: Dennis~M. Ritchie,
967: \newblock {\em On the Security of UNIX},
968: \newblock Unix Programmer's Manual. A. G. Hume and M. D. McIlroy, AT{\&}T Bell
969: Laboratories, Murray Hill, N. J., June 1977.
970:
971: \bibitem{hohl:mess}
972: Fritz Hohl,
973: \newblock ``An approach to solve the problem of malicious hosts in mobile
974: agents systems,''
975: \newblock {\em Institute of Parallel and Distributed High-Performance Systems
976: (IPVR), University of Stuttgart, Germany}, vol. 1997, no. 03, pp. 1--13,
977: March 1997.
978:
979: \bibitem{sander:hosts}
980: Tomas Sander and Christian~F. Tschudin,
981: \newblock ``Protecting mobile agents against malicious hosts,''
982: \newblock {\em Lecture Notes in Computer Science (LNCS), Springer-Verlag Inc.,
983: New York, NY, USA}, vol. 1419, June 1998.
984:
985: \bibitem{sobrado:otp}
986: Igor Sobrado,
987: \newblock {\em A One-Time Pad based Cipher for Data Protection in Distributed
988: Environments},
989: \newblock [Online], Computing Research Repository (CoRR), arXiv:cs.CR/0005026,
990: Available: http://xxx.lanl.gov/abs/cs.CR/0005026, May 2000.
991:
992: \bibitem{yee:sanctuary}
993: Bennet~S. Yee,
994: \newblock ``A sanctuary for mobile agents,''
995: \newblock {\em Secure Internet Programming, Lecture Notes in Computer Science
996: (LNCS), Springer-Verlag Inc.}, vol. 1603, pp. 261--274, 1999.
997:
998: \bibitem{sander:towards}
999: Tomas Sander and Christian~F. Tschudin,
1000: \newblock ``Towards mobile cryptography,''
1001: \newblock {\em International Computer Science Institute (ICSI) Technical
1002: Report}, vol. 97, no. 049, pp. 1--14, November 1997.
1003:
1004: \bibitem{tschudin:security}
1005: Christian~F. Tschudin,
1006: \newblock ``Intelligent Information Agents --- Agent based information
1007: discovery and management on the Internet,''
1008: \newblock in {\em Lecture Notes in Computer Science (LNCS), Springer-Verlag
1009: Inc., New York, NY, USA}, M.~Klusch, Ed., July 1999, pp. 431--445.
1010:
1011: \bibitem{dierks:tls}
1012: T.~Dierks and C.~Allen,
1013: \newblock ``The TLS protocol: Version 1.0,''
1014: \newblock {\em Request for Comments}, , no. 2246, pp. 1--80, January 1999.
1015:
1016: \bibitem{lawrence:tls}
1017: Lawrence~C. Paulson,
1018: \newblock ``Inductive analysis of the Internet protocol TLS,''
1019: \newblock {\em ACM Transactions on Information and System Security}, vol. 2,
1020: no. 3, pp. 332--351, August 1999.
1021:
1022: \bibitem{zimmermann:cryptography}
1023: Philip~R. Zimmermann,
1024: \newblock ``Cryptography for the Internet,''
1025: \newblock {\em Scientific American}, vol. 279, no. 4, pp. 82--87, October 1998.
1026:
1027: \end{thebibliography}
1028:
1029: \end{document}
1030:
1031: