1. Introduction
This document is intended to set the requirements for a generic security protocol
by means of which two parties can exchange keys used for any cryptographic scheme. The
keys can be used as temporary session keys for exchanging data in a session or for
communication between the 2 parties to ensure the integrity of the messages passed.
The document only sets down the
requirements of such a desired robust protocol: it does not describe any such protocol
itself. In essence, all the different
scenarios that occur in the ACE environment are described. Standard security properties of
any generic key exchange protocol ARE NOT described here. This is a follow up on the
“Security Protocol Requirements” Document.
2. Overview
The situation in the ACE environment is as follows. There are a number of devices,
which are in constant communication with each other. All theses devices subscribe to a
central “server” which is the ASD (ACE Service Directory) to which they report.
The ASD shall also store information about each device / service as far as its context and
state are concerned. Each device / service shall have a key associated with it.
Device:
A device implies any physical device and a key / identification associated with it.
This may include a host on the ACE Infrastructure, a projector, a camera etc. They may be
wired or wireless. There may be devices that have the capability to store a key
internally. There may also be devices that just need to be controlled by a service. Such
devices do not come with a provision for storing an internal key within the device itself.
Service:
A service is a piece of software. Typical services in the ACE environment are Audio
Capture and Play, Fingerprint Identification Unit control daemon, Camera and Projector
control daemon etc. These services indirectly control physical devices. Some of them (the
physical devices) do not have the capability of having a hardware specific key associated
with them (like the sound card). Access to such devices in the ACE Infrastructure is
protected through such services. Hence, there shall be a key associated with the service
that acts as the gateway to control the devices.
3. Requirements of Key Exchange /
Distribution
As described in the Overview section,
there is a key associated with each device and service. There are a few fundamental
requirements of any key exchange protocol that are not described here. The requirements
and scenarios that are specific to the ACE Infrastructure are described here.
It is expected that the keys that are distributed shall be used for
different cryptographic algorithms. The key exchange shall ensure this by allowing key
exchange of varying lengths.
The Model used for the key exchange is not a fixed one. There may be
static or dynamic as explained below.
Although the ACE Infrastructure contains the ASD akin to a central server,
this may not always be the case. The ASD by itself is classified as a service, which may
come up or go down. Hence, in most cases, the initial setup of a device or service is
expected to be in a configuration file. After the initial setup, each device / service can
have the option of requesting its private / public key pair from the central database or
getting itself manually configured. In such cases, Encrypted key exchange is required.
In
other cases where the service is active, it may require a session key for purposes of a message / control to be passed on. In
such cases, Authenticated key exchange is required.
In a scenario where it is required that in
a conference, a user has access higher than he is normally allowed, there must be a KDS so
that session keys are appropriately generated for a particular time limit (something like
kerberos).
Example:
A
conference may be initiated in a room where certain resources need to be controlled by a
user who is otherwise not allowed to do so. The resource may be a camera or a projector in
that room. In such a situation, the user must be in a position to acquire a key with a
time limit (kerberos-like) that allows a time limited access to those resources.
àIn scenarios where the use of a
resource shall demand agreement from all k users, the appropriate form of keys shall be
used. This is a case where k users can perform an action, but k-1 can’t do so. In
essence, the key center shall be able to distribute private pieces of information to
different (k) users so that they are able to collectively compute a shared (session) key.
Authentication
across domains:
An ACE domain has a set of resources,
all of which subscribe to a central ASD. All users have a context and a set of workspaces
with active applications running. The key distribution and storage is local to each
domain. There shall be a method (integrated with an authentication protocol), which shall
transparently perform user authentication across domains so that a users context is
seamlessly available to him as he crosses ACE domains.
Wireless
devices requirements:
All the above requirements are desired
properties of any key exchange / distribution mechanism. Listed below are a few specific
to wireless devices in the ACE environment:
As is usual wireless devices have the
limitation of bandwidth, power (computational AND battery if applicable). These are with
respect to devices like wireless cameras, projectors etc. They do NOT apply to Laptops,
though if the desired security level could be achieved, the key exchange / distribution
scheme might well be applied here too.
Minimum number of passes:
This
is the key statement that covers bandwidth and power limitations. The number of passes
that are required of a (session) key exchange shall be as low as possible. In addition to
that, the number of bits transmitted shall also be kept as low as possible. This is for
bandwidth conservation. It shall also be attempted to keep the online computation of the
device as low as possible to reduce the latency time. This is apart from satisfying the
security properties. Hence, reduction in
effective computation should not reduce security strengths.
Key Center
requirements:
These are the information centers that hold all the information on all the key
distribution schemes and the actual keys (configured or generated). Listed below are the
desired properties of such centers (inside a domain).
Key Storage:
The keys that are “permanent” to each service / resource are expected to
be stored on a database. It is hoped that there will be a scheme (similar to Lamports
Hash) that protects the entire system from eavesdropping and server disclosure attacks.
This is an extension from the previous documents “Perfect Forward Secrecy”
requirement.
Number of centers:
If there is only one center, then the
usual case is that the center knows all communication and if it goes down, all key
distribution processes stop, that is, it is a single point of failure.
There shall be a scheme that entails
the power of the key center to m new centers with the following properties.
There shall be l centers that
are capable of providing the same functionality of the key center as before.
Even if (l-1) centers are
compromised, they shall not have information on any common key.
Even if (l-1) centers AND n
users are compromised, they shall not have any information that those n users should not
know.
5. Conclusion
The document presents the scenarios and
requirements of a generic key exchange mechanism in the ACE Infrastructure. This is a
precursor to the other requirements, specifications and design documents for the protocol
and other issues needed to make the entire ACE Infrastructure secure.
