Information Technology Reference
In-Depth Information
architecture. The following six security threats can be identified in agent-based infra-
structure: disclosure, alteration, copy and replay, denial of service, repudiation and
spoofing and masquerading. Security architecture should provide special means to
handle these threats. In this section we review the role of each AP components in the
AP security architecture.
We connect the trust model of such an infrastructure with the trust model of real
world in order to make security critical decisions, basically means that we check if we
trust the entity an agent represents or an AP an agent resides on and indirectly trust
the agent. The connection between those two worlds, the virtual one of agents and the
real one is done via the digital certificates. A digital certificate is an object (file or
message) signed by a certification authority that certifies the value of a person's public
key. X509 certificates of the ISO are the most popular, so we also adopt them in our
design.
If the AP is in any way considered being trusted, that trust must begin with the
AMS. The AMS should store all the information about agents in the AP in secure
storage (e.g. hashed) and also has to be able to receive registration information se-
curely too. In order to achieve this, the AMS may possess a private/public key pair
and associated certificate so that agents can talk to him in an encrypted way. This
provides the basis for inter-platform security from the message transport service and
assures confidentiality. Building security integrated at all levels involves some extra
processing that may not be appropriate in all cases, so in order to avoid it when it's
not necessary, the required policies can be specified. The specifications of these poli-
cies are addressed in the Policies Manager.
A DF is a component of an AP that provides a yellow pages directory service to
agents. It is the trusted, benign custodian of the agent directory. An AP may support
any number of DFs and each DFs may register one to each other configuring federa-
tions. It means that actually it is possible that one malicious agent registers himself as
a DF (spoofing) in order to get information about other agents in the AP. This prob-
lem has been solved in our implementation by means of policies in the PM restricting
the possible DFs to some specified and authenticable agents.
An agent can have multiple certificates in situations where he has established pri-
vate/public key pairs for different policies, functions, or domains. With the addition of
certificates information to it, the DF essentially becomes a default repository for agent
certificates, but should not store sensitive information like private keys as all informa-
tion in the DF is made public. While the DF can be considered a form of certificate
repository, it is not a replacement for repositories that may be established as part of a
general, public key certificate infrastructure.
The agent residing on the AP, has to be able to manage its identity in one or multi-
ple domains and the certificates associated with the identity and roles that he has as-
sociated. The agent should be able to store securely its private keys and all the infor-
mation about his identity in order to avoid that someone can tamper with its code and
have access to this sensitive information.
The first activity that an agent performs upon creation is to register in the AMS of
his HAP and with the DF(s) he is interested in. Since successful registration with the
AMS is the only way to get access to the AP infrastructure this step should be secure
and requires the agent to be authenticated and the information he sends to be en-
crypted in order to avoid disclosure of sensitive information.
