Security - Telenor

42
ating system(s) and/or platform to enforce access
restrictions placed on the agents.
The second attack is not necessarily halted by a
virtual machine-based platform, although such a
platform can thwart a selection of direct attacks.
The problem is that the agent may try to do
actions allowable within its platform environment,
that still affect host data external to the
platform in accordance with the platform’s policy,
but in violation of the agent’s policy.
EXAMPLE 7. Consider a spreadsheet which
includes an embedded agent in the form of
macros for a computation. A virtual machine
executing those macros might allow write operations
to one particular file on the host. An
attacker could exploit this by letting the original
embedded agent itself be harmless, while the
output to the file is a spreadsheet with macros
that make up a malicious agent. Such an agent
might subsequently be executed with the permissions
of a local user on the host. This type of
attack is also related with the problems concerning
legitimate usage of resources.
The third type of attack can in part be thwarted
using systematic trust management. Discerning
intentionally falsified information from wrong
information given in good faith is at best very
difficult, and undecideable, as it encompasses
at least one problem with inherent ambiguity
(computers are generally not particularly good
at deducing intent). Farmer et al. give examples
of this type of attacks in [5].
The fourth attack is usually stopped by protocols
constructed to take such conditions into account,
or by restricting the communication of the agent
(as is already done with Java applets).
6.2 Platform Attacks
Platforms can attempt to compromise the
integrity of an agent by
1. modifying data carried by the agent or in the
agent’s workspace;
2. manipulating the agent’s execution; or
3. not properly protecting the agent’s workspace.
The novel attack here is the manipulation of execution.
Not only must the agent’s data be protected,
but the agent’s execution must also be
protected. Even if an agent could be executed in
an encrypted form, this would still be a problem
– the only difference would be that the platform
would not know what it was doing. In effect,
some sequence σ = σ 1 σ 2 ... σ n of actions must
not be interfered with, or any interference must
be detectable.
6.2.1 Execution Traces
Vigna proposes in [9] a protocol, which in combination
with a trusted third party, enables the
sender to check the execution of an agent upon
completion. The protocol bases itself upon a system
where each platform records the execution
trace of an agent from the agent’s execution on
that platform. An execution trace is a series of
pairs (n,s), where n uniquely identifies a particular
action in the agent, and s records changes in
internal variables as a result of the execution of
n. In a sense this is nothing more than specifying
the format of an “action”, as mentioned earlier,
so these traces can also be considered executions
in the sense mentioned in Section 2.
The protocol itself consists of messages prior to,
and after, the agent’s execution which transmit
data about the agent and its execution. After an
execution, the agent’s sender should be able to
check an execution trace T p by using the data in
T p to simulate the complete execution of the
agent locally, and compare the outcome to that
provided by the remote platform. Obviously, this
check is only done when there is a suspicion that
the remote platform somehow has tried to compromise
the agent’s computation.
Denote by E K (data) the symmetric encryption of
“data” by encryption function E using key K.
Denote by X s (data) the “data” signed with X’s
private key. Denote by H(data) the hash value
of “data”. Write the identity of the trusted third
party as T. The notation A → m B:data denotes the
transmission of message m from A to B, where
message m consists of “data”.
Let A be the sender of the agent in question.
Denote by B 1 , ..., B n the list of platforms the
agent is to visit. For the initial platform, the
following steps initiate the protocol:
1.
A m1
→ B1 :
As(A, B1,EKA(p, SA),As(A, iA,tA,H(p), T ))
m2 2. B1 → A :
B1s(B1,A,iA,H(m1),M)
The field A s (A, i A , t A , H(p), T ) will also be written
agent A , and be referred to as the agent
token. The contents of the messages is given
in Table 1.
Telektronikk 3.2000