Architecture Overview

The ACE Security Architecture Overview

This document gives an overview of the architecture of an ACE and the underlying security components in it. Most of the described security components are still in the design phase and have not yet been implemented.

The ACE Architecture:

The ACE concept revolves around and central "server" called the ASD: ACE Service Directory and a number of "clients" that connect to the ASD, which are called "services" in ACE terminology. All these services have a specific function to perform. They perform a narrow set of functions: that is they provide services in the ACE as such. The purpose of these services is to enhance the net feeling of the ACE so that an ACE user can work on all the systems without the usual burdens of today’s systems. The ACE envisages a user without any cumbersome devices that he has to carry around.

Services: Modes of Communication:

All the services communicate with the ASD primarily and also provide a command interface so that other services can communicate with them. The purpose of the command interface (communication) is to avail of the “services that these services provide”. These communications are encrypted within an ACE using SSL.

Design Issue: It is still not clear how an inter domain ACE communication would go about. We probably have to get a service up to interact between the two domains.

The ASD is used for mainly "registering" the services that start up in the ACE. It also considers itself as a service too. The significance of this will be apparent in the fact that in one of the databases relevant to the ACE, the ASD information is also stored as if it were to a service. The ASD maintains a database that has information about the services (Machine name / IP Address, its location in the building (Room name) its class etc). Information about the ASD itself can be obtained from the relevant database. Services can obtain information from the ASD about other services.

Hence, we note that there are 3 "types" of communications:

1. Between the services and the ASD

2. Between 2 or more services themselves (through the services command interfaces)

3. Between two ACE domains

The first two types of communications are encrypted by SSL. The third type of communication has not yet been given any thought about. Besides these communications, there are the network commands that are passed through between the command interface and the implementation thread that each service has. These communications are also (to be) encrypted through SSL.

It should also be noted that the daemons (services) also have a port open (their address) on the machine that they startup and run. It is possible to telnet into these ports and issue raw commands to the service, the commands being listed in the specifications documents of the services.

Services and related issues:

This section covers the present situation and security threats posed by the current setup. It also describes the various streams of data flowing through the network in the ACE and hence identifies these streams as the ones that need to be encrypted for security.

At the start up of each ACE domain (which is technically initiated by the startup of a number of services starting with the ASD), the key for secure communications is presently specified through a configuration file, which in itself is a bad practice. It must be mentioned at this point that the security of any ACE domain relies on Linux security model. Any misconfigured user with too much permission on the Linux domain can very seriously hamper any ACE's Security. The code for ACE is presumably open source and all it would take is permission to read a file (the ACE configuration File for instance) on part of any user to compromise the security of any ACE.

The other types of network traffic that flow in the ACE is relating to the traffic related to VNC and the audio and video streams. All these are equally important. The audio and video streams are produced by 2 services that essentially provide connection between 2 systems so that the two systems can do a simple audio/video data transfer between them. The VNC streams are much more fundamentally important. They form the essence of the mobility of any ACE. Whenever a user is registered in the ACE, he gets a default workspace created on a robust machine where he runs all his applications. When a user tries to "log into" the ACE domain, he gets into a VNC viewer that shows his applications that are running. Hence, the VNC stream that runs between the server and the viewer on the local machine has to be protected / encrypted. There isn’t any provision for this yet. It must be noted that the VNC stream is the main stream to all the applications that the user runs. Hence, once the VNC stream is compromised, it can be effectively deemed that the entire ACE security has been compromised from the viewpoint of that particular user.

Below is a listing of the some of the services that are present in the ACE. The function of each is described in a few words. The related security aspect of these services are also discussed as well as what is it that needs to be done to ensure the security of the services by part and in whole as an entire domain. These services are representative of the entire ACE domain in terms of representing security issues.

ACE Service Directory:	This isn’t exactly a service although it registers itself as a service when it starts up. It does provide services to other connecting services in the sense that it provides information about the other services. It is also by far the critical "server" of the ACE.
Audio Capture:	This service (also called Daemon from now on) simply captures data from the microphone from the local machine on which it is running and transmits it another service (the Audio Play Daemon) that takes in the audio data and plays it on its local machine.
Audio Play:	This service is at the receiving end of Audio Capture. It receives the data stream that the Audio Capture service sends and plays the same on the local machine.
Video Capture & Display:	These 2 services are the same as their Audio counterparts except that they transfer Video data instead of Audio Data
System Resource Monitor: (SRM)	The System Resource Monitor is the service that holds information about the entire ACE resources. This includes information such as the number of CPUs on each machine, the load on each machine etc. It receives all the information it has from the host resource monitors that are running on every machine on the ACE domain. The information transfer from the HRMs (Host Resource Monitor) to the SRM occurs in 2 modes: The SRM first gets information from the HRM upon initializing through the HRMs command interface. Later, whenever the HRM has any relevant information to pass on to the SRM, it does through means of notifications. These notifications are similar to the network commands that pass through the ACE and are hence encrypted through SSL in the same manner as the other network commands are.
Host Resource Manager: (HRM)	This service shares a many to one relationship with the System Resource Monitor. This service runs on every host machine on the ACE Domain. In fact, one of the definitions of an ACE domain is that each host on the ACE Domain has to have an HRM running on it. This service provides information to the SRM about the local systems load, number of CPUs etc. As mentioned before, it communicates with the SRM by means of its command interface and notifications.
IButton:	The IButton service is part of the services that provide ways to log into an ACE domain. It falls under the category of Authentication. This daemon essentially polls the serial IButton Interface and decides whether an IButton has been depressed into the IButton slot. It tries to match the user by checking whether the IButton Serial Number is already there is the user Database. The problem with this is the classical database disclosure one. Once the database in compromised, the IButtons are useless. It is even more acute in this case because once the IButton Serial Number is revealed; there is no use of the IButton itself. This is too much of an infrastructure waste. Further more, the IButton, if lost or stolen is more a menace than a use when not stolen. Hence, one of the design issues include placing the "IButton User" in a domain with restricted privileges and have the" actual user" as identified by user name / password in a domain with full privileges. It is however an administrative decision on whom to place where. Hence, one of the design requirements shall be to provide for 2 domains (Domains as in User Authorization Domains), one with significantly lesser permissions than the other.
ID Monitor:	This is the actual Daemon that takes in notifications from the IButton etc and authenticates the user. It then tries to display the VNC desktop of the user on the machine where the user has logged in.
Finger Print Identification Unit:	As a service, this is similar to the IButton. It differs only in the fact that it polls the FIU instead of the IButton. As before with the IButton, the Fingerprint data has to be protected else the entire system simply collapses again. This service sends notifications to the Requested service that listens for such notifications.
Network Logger:	This Service provides a logging facility for all the daemons. Whenever an event occurs that any service thinks worthy of logging, it simply invokes the network logger services. The network logger performs the function of accounting in the ACE.

Issues & Design:

The three fundamental tenets of Security Authentication, Authorization and Accounting are addressed here.

Any ACE domain has 2 fundamental players: The Services (Daemons) and the user. Currently, there is no authentication between the daemons themselves. Any Service, after registering itself with the ASD can request and get the command interface of any other service. The first issue to be addressed with the Daemons is authentication within them. The preferred means of identification if the daemons can be through an RSA Key pair (as is the same for users too in addition to fingerprints and IButtons). There shall be a service that is to be started along with the ASD, which shall be a Key/Certificate manager. This service shall have the following functions:

It shall manage the Keystore for the daemons (Note that Keystore in this case DOES NOT refer to the same Keystore as created by the java keytool)
It shall be responsible for distributing dynamically generated keys to users and daemons alike for

Identification
Conferencing

3. The only authentication for the daemons for the ASD and the Key Management Service shall be the address of the ASD, which shall be known through the configuration files. It should be noted that this again places reliance on the Linux security model. Any change in the configuration file compromises the service. Essentially, it doesn’t affect the working of the ACE domain, but deprives it of the services of a daemon.

This service shall issue each daemon a key pair upon startup. The key lifetime shall be the lifetime of the daemon or a specified time limit. The only authentication of the daemon upon startup shall be the fact that

The administrator is starting them up though a script (that can be executed only by the administrator)

The fact that they are "Auto Started" on a host machine with the host machines key for reference.

Again, this is an instance where there is a reliance on the Linux Security model. It is assumed that only the administrator can add machines on the ACE domain.

These are the authentication schemes for daemons within themselves. The other major player in the ACE: the user can log in to the ACE by three mechanisms:

User / Password Combination
IButton
Fingerprint Identification.

Any user can log in from “inside” the ACE domain or from “outside” the ACE domain. An ACE domain is defined as the set of all host machines that are registered in the ACE database as part of the ACE domain. These hosts mostly have a set of services running on them, with the Host Resource monitor being one that almost certainly runs on the host machine. As mentioned before, the authentication mechanism with the IButton and Fingerprint methods are fraught with the danger that unlike passwords, the essential secret (the Fingerprint data or the IButton Serial Number) cannot be changed (easily or at all) once it is compromised.

The present mode of remote authentication is done through a service (The Remote Connection Manager), which authenticates the user through the SPEKE protocol.

Each user, after logging into the ACE is presented with a set of his workspaces (which are nothing but VNC sessions) and the set of services that he is allowed to operate within ACE. This shall be in GUI form with the services. Authorization is to be done with Keynote certificates. Accounting is taken care of by the Network Logger Service.

One issue of relevance with the daemons lies with the fact that they have a telnet port open on the machine where they are launched. Access through this port has to be blocked to relevant administrative users. However, as a good design principle, there should exist enough applications for querying the status of each daemon so that the telnet command line interface is almost never ever used.