Spawn employs a lightweight security mechanism. In
a stationary setting, where all hosts access a wired (and therefore much
more reliable) network security, issues are easier to deal with since the
applications can rely on central databases containing information about users,
passwords, credentials, and capabilities. Trust management in a distributed
system operating in a stationary setting is easier when applications can
always rely on the presence of a (server) service ready to authenticate requests
and offers. In ad-hoc wireless networks, security considerations face new
challenges. When two devices come in contact, identifying the other party
is not as easy as asking a trusted third party to verify the other's identity.
While an authentication server may be available from time to time, the design
of the applications cannot rely on this for their proper functioning. There
is no guarantee that an authentication service is available at a given point
in time or that it will become available any time soon. Thus, the two nodes
need to take special safety measures to ensure secure interactions.
Addition of security to Spawn required the addition of two components: a
security veneer between Spawn and Limone, and a security manager which maintains
the access control rights, security keys, etc. Security is provided at two
levels of granularity: by tuple-space and by tuple. The figure below presents
the architecture overview of the system and it's security veneer. The security
veneer is at the interface of Spawn and Limone, where it acts as an interceptor
and filters all incoming and outgoing traffic, and enforces security and
access control policies. The bottom layer handles all the communication between
hosts and agents.
In Limone, each agent owns a local tuple space. This tuple space is always
left unsecured, meaning that any entity can access its contents. This tuple
space is used for general service advertisements and communication. In
addition, the security veneer allows an agent to create a secure logical
tuple space. A secure logical tuple space has a name and a password associated
with it. To access the secure logical tuple space, an agent must possess
a handle to the logical tuple-space (obtained when the logical tuple space
is created or by providing the name to the Limone system) and in addition
must specify the password when performing any tuple space operations to
ensure the execution of the operation. This ensures that only those entities
that possess the password can access the secure logical tuple space (we
assume that the distribution of passwords is done by a third party key
distribution software that is handled at the application level). The use
of different names and passwords for logical tuple spaces enables creation
of multiple (protected and/or unprotected) administrative domains where
servers can publish services and clients can look them up, grouped by common
interests or access rights. If a secure logical tuple space is created
without a password, it functions the same way non-secure logical tuple
spaces do, where only the handle (or the name to obtain the handle) is
required to retrieve data.
Given the variety of data present in a repository and the multitude of users
accessing it at any moment, often, the protection has to be extended to a
finer grained level than the entire tuple space of service registry. The
security veneer also provides secure tuples. A secure tuple is similar to
standard Limone tuples but add two fields: a read-password which is required
to read or copy the contents of the tuple, and a remove-password that is
required to remove the tuple from the tuple space. The passwords are added
when the tuple is placed in the tuple space. The read-password controls access
to the content of the tuple, while the remove-password makes a tuple read-only
to those entities that do not possess the password. Thus a service advertisement,
which is essentially a Limone tuple can be secured by using a secure tuple,
which can be marked read-only by its provider protecting it with a remove-password
that is not made public. This will prevent unauthorized (accidental or fraudulent)
removal of the service advertisement as well as the replacement of the advertisement
with a fake one. Additionally, each advertisement can be protected by a read-password,
which enables a service provider to protect its services in a highly individualized
manner. As with the passwords for the tuple space, if a password is not provided
for a tuple, it behaves like an insecure tuple, e.g., if a remove-password
is not provided, any entity can remove the tuple. Similarly, if a read password
is not provided, any entity can read the contents. Note that in the case
of both tuple-space-level and tuple-level security, the security manager
is responsible for checking and verifying password protected access.