This document reports on an evaluation of the security work carried out at QMW for the PerDiS project. The security work was strongly influenced by the fact that the PerDiS platform is intended to be used to support cooperative work within virtual enterprises. The work has the following three aspects:

We have carried out our evaluation in two phases. The first phase is described in Section 2 of this document. It is concerned with the usability and applicability of the role-in-task model.

The second phase is described in Section 3. This evaluates the performance of the implementation and interprets the results. It is concerned with estimating the overhead on communication caused by the authentication and encryption of messages between processes. It assesses whether performance is enhanced by the distinction between domains and evaluates the overhead due to access control checks.

This document does not discuss the threats that the security model and implementation are designed to protect against - these are discussed in PerDiS Deliverable TD.1.2-A [TD1.2A].

This section is concerned with an evaluation of the role-in-task model. We are interested in knowing the following:

To carry out our evaluation we have chosen two rather differing test cases. The first (Section 2.1) is a paper model for object-oriented team programming. The second (Section 2.2) is a real-world example based on the roles and objects used by a medical team working on the treatment of diabetic patients. In both of these test cases we first attempt to describe the specified security policies in terms of our role-in-task model. We then suggest the ways in which the model appears to be deficient (Section 2.3).

In the first study we also illustrate how the security policies may be applied to applications by means of the PerDiS security tools[5]. The Template Tool is used to make a template that describe the generic security requirements for a family of tasks in terms of roles and object categories. The Task Manager Tool allows a user called the Task Manager to instantiate a task from a template and to allocate users to the roles. It also allows users to change roles and access rights during the progress of the task.

The first test case is based on an abstract model for the development of object-oriented software by teams of programmers, described in [1] and henceforth called the ND model. The model was intended to describe a useful cooperative working environment, and therefore addressed issues other than access control. However we describe here just the aspects of the model that are relevant to access control. In particular the concept of teams has more to it than we indicate, but it is worth mentioning that each member has ultimate responsibility for the compatibility of their own work with that of the rest of the team.

In the model, the programmers work in contexts (e.g. Unix directories or Smalltalk images). A working context is owned and used by a single developer who may choose to share it with others. A master context stores classes developed by programming teams who can browse (read) the classes or copy them to working contexts. A master context can also hold shared instances that are freely accessible to team members e.g. for use as test beds.

A team is a group of programmers who are working together on a development project. Team members are assumed to trust one another. Several teams may share a master context but where privacy is required, a separate master context should be used. Each of the classes in a master context has one owner who is allowed to write to it.

In strong ownership, only the owner can modify a class in the master context. Weak ownership allows specified non-owners to add new versions of classes with proposed changes to the master context. The owner specifies which teams may propose changes and is responsible for merging the changes into the original class. An owner can delegate their ownership (actually give it away) to another team member, who becomes the sole owner.

A master context supervisor is a role that specifies the ownership policy, creates teams and if necessary change the ownership of classes.

Here we attempt to apply the ND model to the development of the PerDiS software . We use weak ownership and call the teams Application, ULL (User-level library) and Platform.

The Application team needs to see the ULL classes. Platform programmers need to see the platform classes (Garbage collection classes, Caching classes , Transactions and persistence classes , Security classes). However, apart from Speedikon there are no restrictions on visibility so one master context should suffice. The Speedikon code would need its own private master context because other developers are not allowed to see it.

We could allocate class ownership as follows:

As stated above, the owner specifies which teams may propose changes to the classes they own. As an example, we suppose that the Olivier, Joao and Marcus have specified that members of the Platform team may propose changes to their classes.

We would make Xavier the master context supervisor because he is responsible for the platform and the ULL.

Briefly, the PerDiS role-in-task model allows users to define their security policies for a particular type of task by specifying the access rights in terms of the roles and the categories of objects required to carry out that task. Note also that PerDiS provides a tool allowing users to change the access rights to clusters during the progress of a task. The objects created in each object category are assigned to one or more clusters. Thus, different categories imply different clusters and the possibility of different access rights.

We will now define the roles and categories for a master context that includes all but the Speedikon classes.

Since the ND model applies update access control to individuals, we need single person roles. We will define them as follows:

To follow the ND model, we define three teams as follows:

The ND model states that class owners can specify which teams may propose updates to their classes.

In PerDiS: for each team we allocate all the classes belonging to one owner to a single category (which will eventually map to one or more PerDiS clusters). Thus, although the ULL classes and Garbage collection classes have the same owner, we have allocated them to separate categories because the owner works on them as a member of different teams. In fact, it seems likely that the owner might want to relinquish ownership of one but not the other, which is possible only if the classes are stored in different clusters.

We discuss only weak membership here and use a separate category for the proposed versions of classes belonging to each of the owners in each team. Again we have more categories than are strictly necessary - in fact, all of the proposed updates for the platform classes could be put in a single category, but it seems more practical to have separate categories for each owner to allow the owners the ability to control access to them in different ways. For example, an owner may decide to add or remove a team from the ability to propose updates.

For example, we have:

All the actions that the master context supervisor in the ND model is supposed to do are available to the PerDiS task manager, who may instantiate a task from a template suitable for either weak or strong ownership. In our example, the template is suitable for weak ownership.

The Task Manager tool will provide a convenient way for the master context supervisor (as PerDiS task manager), to substitute new programmers in the roles where necessary. The task template for the task of maintaining the master context (excluding Speedikon) is:

It turns out that teams cannot be represented directly in the role/task model. They are used indirectly in defining the template, because owners of classes specify the teams that can create proposed versions by giving the members of these teams RW access to the corresponding object categories. For example, members of the Platform team can create proposed versions of most of the platform classes, whereas the members of the Application team cannot. The template shown here deals only with the ULL and platform classes. According to the rules in the ND model, the teams using this context can see all of the classes, although it may not necessarily be useful for application teams to look at platform code.

When a task is instantiated from this template by the task manager, he will have all the rights intended - he can assign users to roles, change access rights and so forth. Once a task has been instantiated the users in the roles run applications that create clusters holding the objects in the specified categories. After that, access control is applied to the clusters and the task manager and other specified users can alter the access rights as necessary. Again, teams cannot be represented directly in the ACLs of clusters. For example if a class owner decides to add or remove the rights for members of a team to add proposed versions, they must add or remove all of the roles that belong to that team.

As to the representation of class ownership in PerDiS - the role with RW rights can create and modify classes in that category, e.g. the QMW programmer role can create and modify security classes. This example requires that only one user at a time should own a class. PerDiS currently cannot offer the facility to allow only one user in a role, although the task manager can ensure that this is the case initially.

The model states that an owner of a class can give away ownership to another user. We refer to the role with RW access as the owner. The ACLs of PerDiS clusters may be changed by the task manager or by any other principals added to a list by the task manager. To produce the required effects, the task manager has to add the owner to that list. When the user wants to relinquish ownership they change the ACL, adding another name to the list of those allowed to change it and removing themself. Once again, the single role membership cannot be enforced by PerDiS but the users in the roles could do so voluntarily.

The PerDiS security tools were used to encode the security policy for the preceding scenario as seen below. To summarise, the tools allow the following to be done:

Firstly, the template tool was used to define the security policy for a family of Team Programming tasks in terms of a PerDiS security template, as shown in the illustration below:

This template is stored by the system and is available for anyone who needs to instantiate a task from it.

A task instance for the PerDiS Programming project was instantiated from the above template using the Task Manager tool. The roles and categories were derived from the template, after which various users were assigned to the roles, as shown in the figure below:

This task instance is stored in a cluster and is accessible via the url of the cluster.

Once this has been done, any of the users assigned to the roles can play their roles in this task. To do this, they need to start a PerDiS application from the Security Shell and select one of their own tasks and roles. They will then have the corresponding access rights. For example, we will see below that users can make use of the PerDiS Management application to view and update the classes in this example. If they start this application from the Security Shell they will be allowed the access rights specified for their role in the template.

The Task Manager tool also allows users to see which roles have been assigned to which users through an alternative view:

Suppose that the user Xavier starts his PerDiS security shell. He is presented with a choice of the tasks he is involved in. Then if he selects PerDiS programming project task, he is presented with the option to select either of his roles (the Task Manager and the SOR programmer), as shown below:

If he selects the Task Manager role, he can use the Task Manager tool, for example to give another user a role in the task or to alter the access rights on an ACL.

This Management Tool is a PerDiS application. It provides a user interface to enable users to create, edit and view collections of PerDiS clusters within a nested directory structure. It is documented in [6]

We use the Management Tool to illustrate the ability to control access to object categories in PerDiS. The Management Tool organises the classes in PerDiS clusters according to the access rights for the task. For each class created, we are prompted to choose an appropriate security category:

The Management Tool allows the users in the task to browse the directories and to view or update the classes stored in the clusters, as illustrated in the following figure:

Our second test case is based on an example derived during the Mushroom project [4] which is currently active at QMW. Mushroom is concerned with the development of a generic workspace model and a platform for supporting collaboration and group interaction for the Internet. The current Mushroom project, in conjunction with the School of Medicine and Dentistry is concerned with an evaluation of the workspace model and the platform in the context of a medical application: the care of diabetic patients. This work included a detailed study of the roles played by the various people concerned in the care of a diabetic patient. These roles, which are given in full detail in Appendix 1 can be summarised as follows:

The full list of roles in Appendix 1 includes three further non-medical roles. These have been omitted because the study has not considered the categories of objects used in interactions between them and the other roles.

Considering only the medical roles, the following object categories are derived from the documents used by the participants:

A number of formal letter types are also defined, whereby medical information or recommendations are passed between roles. These are confidential to the roles involved. For example:

The security template for diabetic patient care is defined thus:

In the PerDiS model, a new task would be instantiated for each patient, and the medical practitioners responsible for the patient would be assigned to the appropriate roles. In this case the template is quite generic.

Our first criterion for evaluation was concerned with whether the role-in-task model is adequate for expressing access control requirements. In the first test case for object-oriented team programmers we noted the following deficiencies:

The second test case considered the security requirements for the users and object categories involved in the treatment of diabetic patients. It was positive in the two following respects:

A possible improvement suggested by this test case:

At the design stage [TD 1.1], we considered two other aspects of the access rights model, neither of which have been implemented, although the design allows for this to be done. The test cases have not shown a need for these, but we still think they might be useful. They are discussed briefly as follows:

Our second and third criteria for evaluation were concerned with whether users that have described their requirements can supply them to the system in a convenient and simple manner and whether the model is sufficiently flexible to allow users to change access controls as a task progresses.

We have attempted to show that this is so by showing how the security tools can be used to set up the access control policies proposed for the first test case. We have shown that it is easy to enter a task template and to instantiate tasks from templates. We have also shown that it is straightforward to give roles to users and to change access rights for clusters. Therefore, we believe that the third criterion as to the flexibility of the model has been satisfied.

However, we have not been able to show that real users can understand how to use the security tools. We have tried to make a convincing argument based on the use of the security tools in first test case, that the tools are convenient and easy to use. But a true evaluation of usability would require a user study based on the use of the security tools in the context of a PerDiS application.

Even without the user study, there is one possible cause for concern which would apply to any application of access control in a shared task in a virtual enterprise. Users are quite used to managing their own private work on computers and even to accessing shared information via databases and the Web. However they generally have no experience with managing access rights. The second test case illustrates this point. Even if we suppose that the template for diabetes care has been provided, the question is whether a GP will be too busy to instantiate new tasks whenever patients are defined as diabetics.

The PerDiS security model was designed to take into account the differing needs for security configurations. In some situations no security may be needed. In others, the security of the hardware and network is trusted sufficiently that a minimal level of security is required, whilst in others both the hardware and network may be untrusted, requiring the application of the strongest levels of security available.

In particular the PerDiS security model has a notion of domains. A security domain is seen as commonly mapping onto an organisational or administrative domain, where security policies may be defined, implemented, controlled and monitored. When principals are communicating within a domain, a level of security is provided based on symmetric cryptography, mainly involving the enforcement of access control. When principals are communicating from within different domains, or where although principals are within the same organisational domain, they are separated by a 'hostile' network, we wish to enforce access control, but also to have strong authentication of communication integrity and principal identity. For data travelling over hostile networks we also wish to maintain secrecy by encryption of the data. Such protection is based on public-key or asymmetric cryptography.

The strongest security is not used for all cases because using security incurs an overhead. In particular, the use of public-key based cryptography is several orders of magnitude more expensive that the use of symmetric cryptography [7].

The aim of this section is to perform two tasks. The first is to evaluate the performance of the implementation of the security. The second is to interpret the results, and determine whether the use of the notion of domains is a useful one.

To summarise the three security configurations measured:

• No security: All messages are sent in the clear, with no authentication or access control applied.
• Intra-Domain: All messages are signed with the domain key. Access control is applied both locally and remotely. All messages are authenticated.
• Inter-Domain: All principals are authenticated using public-key cryptography. All messages are signed and authenticated with an established session key. All data transfers are encrypted.

In order to evaluate the performance it was necessary to obtain measurements of applications using the platform in different configurations. An application suite was written which was composed of several components:

The 'web crawler' application communicates with Web servers using HTTP. It retrieves the first page it is pointed at, and copies the contents of the page into PerDiS DSM. It then parses the page looking for links to other resources, such as more HTML documents, GIF and JPEG images, etc. It then retrieves each of these resources in turn, and in the case of HTML documents, parses them for further references.

The web proxy server accepts HTTP requests from standard web browsers, translates the requests into requests for the DSM, and returned the corresponding resource from PerDiS DSM, mapping it into an HTTP reply.

The web crawler' application can also be configured to traverse an HTML graph, producing from it a management database, in which the hierarchy of the graph is represented as a tree, and the individual resources are displayed.

A resource manager uses the management database to allow browsing of the HTML structure, and also editing of the resources.

To perform the evaluation a repeatable set of PerDiS operations were required. The PerDiS DSM was first populated with a substantial HTML graph using the web crawler. The second configuration of the web crawler was then activated on the HTML graph, accessed through the web proxy. This generated a repeatable set of data requests made to the web proxy which could be measured.

The web proxy was configured to operate in two different ways. For application type 1, each request for a page was resolved within an individual transaction. Each request for a page would take the form (showing the operations of interest to us only):

The aim of this configuration was to measure the performance of an application performing many short transactions.

For application type 2, all of the data requests for each run of the web crawler were resolved within a single transaction. Here the application operations took the form:

The aim of this configuration was to measure the performance of an application operating as a single long transaction.

The measurements were performed using a two PCs, one with 160M of main memory and an AMD K-6 processor running at 233 MHz, and one with 128Mbytes of memory and a P2 processor running at 233 MHz. They were connected by a lightly-loaded 100Mbs Ethernet subnet.

The cryptographic protocols employed in the implementation are taken from the SSLeay library, version 0.9.1. For the asymmetric cryptography, authentication and key exchange were performed using MD5 signatures and RSA encryption, with a key size of 1024 bits. For the symmetric cryptography, authentication and encryption were performed using the MD5 for signatures and the DES protocol for encryption, with a key size of 56 bits.

Each resource in the HTML tree, be it an HTML text document, GIF or JPEG image, is represented as an object in the PerDiS DSM. Objects are organised into clusters, with a cluster corresponding to a directory in the hierarchy of the HTML tree. Data is locked and transferred between PDs at a 64K granularity. As most of the resources stored are less than 64K there are frequently several resources stored in a single page.

When accessing a resource, the cluster corresponding to the location in the hierarchy of the resource is opened. In the first application type, as each access is a new transaction, this cluster opening will occur each time. For the second application type, the cluster is only opened for the first access into the cluster - it remains open for the remainder of the transaction.

Once the cluster is open, the root object name directory is consulted, which maps from the name of the resource (e.g. index.html) into a persistent pointer into the cluster. Once this is obtained, the resource is locked. This causes the page or pages containing the resource to be brought from the local or remote PD and transferred into the active memory of the application. Again for the first application type this will need to be performed for each request as each request is isolated within an individual transaction. For the second application type, all memory already locked remains mapped, so that future requests to the same object or other objects in the same page can be answered immediately, and without recourse to the PD.

Timing of PerDiS operations is performed using the GetTickCount() function provided by Windows NT. This function returns the time elapsed since NT started in milliseconds, to a resolution of 10 milliseconds. Hence any operations performed in less than 10 milliseconds are reported as taking zero time.

In all the graphs following, lines labelled as "Linear" are lines of best fit.

The following performance figures are micro benchmarks of various communication operations.

The following measures the overheads of establishing a connection between two PDs in the three security configurations - no security, intra-domain security, and inter-domain security. Only one connection is established per pair of PDs the first time they communicate - all subsequent messages between the PDs are sent over the same connection.

The PDs perform a handshake to establish the link at the appropriate security level - either no security, or using the domain key for an intra-domain link, or using public keys to negotiate a shared session key in the inter-domain case.

In the case of no security and intra-domain security, the majority of the connection overhead is the communication itself, with only a 7ms difference in timings. Inter-domain timing is much higher for two reasons - firstly, when opening a connection an attempt is first made to open the connection using the domain key. In the case of an intra-domain connection the attempt succeeds. In the case of an inter-domain connection the attempts fails, and the connection attempt falls back to negotiating with public keys.

A significant proportion of the time is also accounted for by certificate retrieval time, as can be seen from the renew connection data series, where the connections are already in the PD's certificate cache.

For the inter-domain configuration the data transferred between PDs is encrypted. The chart below shows the timings made for the transfer of 64K pages with average timings of 2ms (with a standard deviation of 4) to send a page unencrypted and 36ms (with a standard deviation of 5) to send it encrypted. (Note that due to the timing resolution of 10ms the transfers can only be said to take <10ms rather than 0ms as shown).

The overhead of encrypting a 64Kbyte for transmission page is approximately 170%.

The following measurements evaluate the times taken to perform access control. This operation requires the opening of the security information contained in a cluster, and a search through the access control list (ACL) for a specification of the access rights to be afforded to the user making the request to access a resource. Access control occurs in two locations for a single request - firstly the 'local' PD (i.e. the one to which the ULL attaches) checks the request. Secondly, the 'remote' PD (if the PD holding the cluster is not the local one) also checks the ACL. The measurements were taken during the executions of the test applications described in the next section.

The first measurements show the timings for the local PD:

The first time access control is applied for a cluster we have a large overhead, as the local PD must first obtain the security bunch (and other meta-data) for the cluster in order to make the access control decision. For this particular application we can see that eleven distinct clusters are accessed. The difference in timing for intra-domain and inter-domain configurations occurs because of the overheads of opening a cluster from a remote PD.

On the remote PD, the security functions include performing the same access control, but also the authentication of the requester's identity. For intra-domain messages, authentication is performed using the shared domain key. This operation takes less than 10ms and so cannot be measured. The figures for access control are:

We can see the first accesses to each of the eleven clusters cause the ACL result to be evaluated, whilst for all subsequent accesses the result is available in the cache.

For inter-domain requests we also apply authentication using asymmetric cryptography. The timings for the operations are shown below. To obtain the figures we measured the verify_lock_request() operation, the generic function called by the PD when it wishes to perform security checks on a request received.

The first verify_lock_request() operation takes nearly 250ms. This is because it is performing security on the first request from a principal from a remote PD, for a cluster for which it is the home site. The two PDs perform a public-key based authentication and establish a session key. Access control for the cluster is also performed.

For subsequent calls to verify_lock_request() for data in the same cluster, the time taken is nearly zero as the message is authenticated using the session key, and the access control result is available from the result cache.

For subsequent calls to verify_lock_request() for data in a different cluster, we must perform a new access control check using the ACL for that cluster. Examining the graph we can see there are a further 10 such calls (as the application measured accesses 11 clusters). Hence the costs for these calls are about 40ms. Because the clusters are all at the home site, and the same principal is requesting the clusters, the session key already established may be used.

If the clusters were 'owned' by other principals (i.e. available from the PD because the page has been modified by the owning principal) a new session key would be needed for each different owning principal, and so first-access costs would be similarly high.

In this section two different types of applications are measured and the performance reported and interpreted. Application 1 maps each request into a new transaction, acting as an application which operates using many short-lived transactions. Application 2 performs all the requests within a single transaction, acting as an application that performs its operations within a single long-lived transaction.

We chose to measure 4 operations for our performance evaluation. This is because it is these 4 operations which are most affected by security.

new_transaction() as seen from the perspective of the ULL is where initialisation of security occurs. The ULL sends the identity and credentials of the user running the application to the PD. The PD stores this information, and also performs authentication checks to confirm the claimed identity of the user. At the same time, the ULL also accesses the task object for the current task, to obtain a list of object categories, which is required for object creation. This invokes quite a high overhead of operations, as it requires that the task object cluster be opened and the object retrieved.

open_cluster() is where the majority of access control is performed. open_cluster() causes the retrieval of the meta-data bunches (md_bunch, rt_bunch, secu_bunch, etc) from the PD into the application's memory. This retrieval of data is subject to access control. Performing access control also incurs operations likely to be the subject of security themselves – the PD will perform an open_cluster() itself on the cluster being opened to obtain the security information needed to perform the access control check.

hold_unchecked() incurs very little access control overhead, as the security caches the access control results on a per-bunch basis. The overhead associated with hold_unchecked() will largely come from the cost of encrypting the data returned for a hold request, and authenticating the validity of messages received.

end_transaction() incurs security costs when it re-takes locks (in the case of optimistic transactions) and when it attempts to write data into the file system (which will be subject to access control).

The proxy server has a local PD that is different to the PD holding the HTML data. All requests made by the application measured are passed from its ULL to its local PD. These requests are subjected to local access control, and then checked again when the request is sent to the remote PD. The request will be also be authenticated. All data used in the application is transferred from the remote PD to the local PD.

The application was run five times in each security configuration. The following graphs were obtained by averaging the cost of each operation across the five runs (standard deviations are given). The analysis of the results is broken down into operations.

new_transaction() has two operational characteristics. The first call of new_transaction() is a 'cold' call - no communication has been established between PDs, no information is available locally, no certificates have been loaded, etc. The subsequent calls to new_transaction() are 'warm' calls, where the PDs are already communicating and the data required is available locally.

The first figures are for the 'cold' operation:

We have average timings (and standard deviations) of:

No security: 355ms (5)

Intra-Domain: 524ms (5)

Inter-Domain: 1600ms (23)

The overhead for intra-domain operation is 50% and for inter-domain operation is 350%.

The next set of figures are for the subsequent new_transaction() operations which are 'warm' calls.

We have average timings (and standard deviation) of:

No security: 42ms (3)

Intra-Domain: 91ms (2.9)

Inter-Domain: 91ms (2)

The overhead of security for both the intra-domain and inter-domain configurations is 116%, as we would expect as the data is available locally, and only access control is applied.

open_cluster() behaves in two distinct ways. The first time a cluster is opened by a ULL, it causes the local PD to fetch the cluster data from the remote PD. Here the security overhead and other costs are high - the local and remote PDs and principals must authenticate each other, access control is applied, the data must be transferred between PDs (encrypted in the inter-domain case), and finally the authority of the remote PD to send the data is checked.

When a cluster is opened subsequently, unless the data has been invalidated by being modified by another transaction running on another PD, the local PD will retain the cluster locally in its cache. Hence, only the local access control check need be applied. This is true even though each new_cluster() operation occurs in a different transaction. The effects are seen for each run of the application because the PDs are restarted (hence clearing their caches) before each run. If the PDs were not restarted only the first run of the application would incur the very expensive behaviour (again assuming no modification of the data by another transaction).

The first graph shows the open_cluster() 'cold' operations where a cluster is accessed for the first time:

The average figures for the operations are:

No security: 167 ms (6)

Intra-Domain: 235ms (4)

Inter-Domain: 667ms (11)

The intra-domain configuration incurs an overhead of 41%, whilst the inter-domain configuration incurs an overhead of 299%.

For 'warm' operations where the data is already available locally, we have:

The figures for the operations are:

No security: 30 ms (2)

Intra-Domain: 49ms (3)

Inter-Domain: 49ms (3)

As we would expect, the intra and inter-domain configurations are more expensive than in the no security configurations, and as all the security is only applied locally, intra-domain and inter-domain operations have the same overhead.

Intra-domain and inter-domain configurations incur an overhead of 35% of which all can be attributed to access control.

The measurements obtained for hold_unchecked() should describe three different modes of behaviour. For the first two, the object to be locked is not already in memory. In this case, the page or pages containing the object must be retrieved from the PD. The operation may then either be 'cold' where the page has to be fetched from the remote PD, or 'warm' where the page is cached at the local PD.

Because hold_unchecked() is called at the object granularity, a single hold_unchecked() operation may cause the transfer of several pages from the remote PD to the local PD and into memory. Hence when considering the figures it is useful to know how much data is being transferred per operation.

The following graph shows the sizes of the objects being locked:

In some cases we would expect hold_unchecked() to take almost zero time, occuring when a lock is requested on an object already in memory. This happens if the object had already been locked, but it can also occur on an unlocked object. The platform works at a (64k) page granularity, so locking just one object in the page will bring the page into memory. Other objects in the page are hence brought into memory at the same time, so subsequent requests to lock those objects require no activity.

The operation timings are shown below. It is interesting to note the mirroring of the data size with the operation times.

To compare the three configurations it is necessary to compare identical operations. The following figures are the averages of operations for which only one data page was needed. The average times to lock an object are:

No Security: 94ms (2)

Intra-Domain: 124ms (3)

Inter-Domain: 384ms (3)

The overhead of an intra-domain configuration is 32% and for an inter-domain configuration is 309%

end_transaction() must commit to the file-store any pages that have been altered. Because the transactions measured are read-only security has little significance:

Average timings (with standard deviation) were:

No security: 22ms (4)

Intra-domain: 21ms (3)

Inter-domain: 21ms (2)

showing there is no overhead for either security configuration.

For the next set of measurements we examined the same application and scenario with a different operating characteristic. For application type #1 each request for an HTML page was dealt with in an individual transaction. For application type #2, all the requests are dealt with within a single transaction. The use of a relatively long single transaction is how PerDiS was designed to be used. The configuration and operations measured are as for application 1.

The following shows a comparison of new_transaction() timings:

The average timings were:

No Security: 324ms (25)

Intra-Domain: 485 (9)

Inter-Domain: 1445ms (54)

giving us an overhead for the intra-domain configuration of 50% and for the inter-domain configuration an overhead of 346%.

As there is only one call to new_transaction() per run all these measurements correspond to the 'cold' operation of the application type #1 measurements.

The first graph shows the open_cluster() 'cold' operation where a cluster is accessed for the first time:

The average figures for the operation are:

No Security: 174ms (22)

Intra-Domain: 238 (32)

Inter-Domain: 693 (141)

Intra-domain configuration incurs an overhead of 37%, whilst the inter-domain configuration incur an overhead of 298%.

For application type #1 we could also measure the 'warm' operation timings, whereby a new transaction opened a cluster already cached by the PD, but not in the application's memory. In this case, because the application runs as one long transaction, subsequent requests for the same cluster take zero time, because the cluster is already in the application's memory.

Application type #2 accessed exactly the same data as application type #1, and so the pattern of data access is the same as shown previously.

The operation times for hold_unchecked() are shown below:

Again it is interesting to note the mirroring of the data size with the operation times.

The average times to lock an object which requires the loading of a single page into memory are:

No security: 94ms (5)

Intra-Domain: 122ms (4)

Inter-Domain: 373ms (6)

The overhead of the intra-domain configuration is 30% and for the inter-domain configuration is 297%

Measuring end_transaction() for application type #2 is considerably more straightforward - it only commits once per run. Comparing the times for each configuration we get:

The average times for the operations are:

No Security: 485ms (5)

Intra-Domain: 487 (5)

Inter-Domain: 484 (6)

As the resolution of our measurements is 10ms we can consider these to be equivalent, with no overhead for the secured configurations.

In the previous configurations we examined PerDiS running with PDs communicating across a network. For comparison, we examine application #1 running with a single PD and ULL-based application running on the same machine.

As only one PD is involved, we do not use the standard security configurations, which cover communication between PDs (i.e. this is not intra or inter-domain). Instead only local security applies, where there is authentication of the user's identity and access control protection for clusters.

For the previous measurements we had a 'hot' and 'cold' for the new_transaction() operation. These differences occurred because of the overheads in fetching the task object cluster from a remote PD for the first accesses; mainly this was due to the cost of establishing a secured and authenticated connection with the remote PD. In this case the information is available locally, and the costs for accessing the clusters are the same.

The average times are:

No security: 75ms (5)

Security: 145ms (6)

The overhead for security is 94%.

First we have the 'cold' operations (where the cluster is loaded from disk)

The average times are:

No Security: 86ms (6)

Security: 108ms (8)

with the secured configuration having an overhead of 26%.

For the 'warm' operations (where the cluster is already in the cache)

The average timings were:

No Security: 53ms (2)

Security on: 76ms (3)

giving a security overhead of 43%.

The average timings were:

No security: 19ms (11)

Security: 19ms (10)

giving no security overhead, as we would expect.

Average timings for this operation were:

No security: 35ms (4)

Security: 34ms (4)

giving no security overhead for this configuration.

The following graph compares the differences in overheads found between the two applications types (where we have two PDs communicating over a network)

As we would expect, new_transaction(), open_cluster(), hold_unchecked() and end_transaction() all behave in similar fashions - the security overheads for each of these is the same.

For the purpose of this graph we took the timings of the 'cold' new_transaction() from the measurements of application type #1 when calculating the overhead - the overhead is otherwise reduced by the averaging effect of a single 'cold' new_transaction() with the large number of "warm" new_transaction()s. Similarly we only consider the 'cold' open_cluster() operations as we have no 'warm' measurements for application type #2 (times for 'warm' operations for type #2 are zero as the cluster is always in memory in a single transaction)

The applications measured above all use read-only transactions, i.e. there is no modification of the data set read. The discussion above does however tell us about how writing applications will behave. The storage is secured using exactly the same security functionality - the storage calls verify_lock_request() to determine if a page should be written into the store or not. The same security applies for the communication between a transaction in write phase and a transaction in read phase - just in the opposite direction. Hence the messages are signed, encrypted, authenticated using exactly the same mechanisms, giving exactly the same overhead as analysed above.

The following table gives a summary of the overheads of the security configurations:

new_transaction() causes the creation of a new transaction on the PD, registers the security details of the user, and loads the security information from the task object.

The dominant operations are therefore those of opening the task object cluster - open_cluster() and hold_unchecked(). The overhead associated with new_transaction() matches the overheads of these two operations.

For open_cluster() we need to consider its two modes of operation. When operating "from cold" the overhead for intra-domain operation is about 40%, whilst for inter-domain operations it is about 300%.

This overhead derives from the local and remote access-control check on the cluster, and also the authentication of the user making the request, and the authentication of the signatures on the messages exchanged. Inter-domain operation incurs a far higher overhead because in addition to the costs of intra-domain operation, the first access to a cluster will result in a public-key based authentication exchange in order to establish a session key for access to that cluster on that PD.

However, once the cost of bringing a cluster's meta-data to the local PD has been met once, subsequent overheads are reduced to 35% for both configurations if accessed by a different transaction, or zero if accessed by the same transaction. The same transaction achieves zero overhead by having the cluster already in memory. The other transactions achieve their savings by only being subject to access control by the local PD.

hold_unchecked() incurs an overhead of about 30% for intra-domain operation, and 300% for inter-domain operation.

The overhead derives from the checking of signatures on messages exchanged, and the authentication by the recipient PD of the authority of the sending PD to send the data. In addition, for inter-domain operation, hold_unchecked() incurs the extra costs. Firstly, due to the 'lazy crypto' protocol, the first message received will be rejected (as it is signed in the wrong domain key). A request for the message to be returned in the session key for the cluster will be made, and the new request must be generated and returned. The data is also encrypted using symmetric cryptography.

Measurements were made to determine the overhead of the lazy-crypto protocol compared to that for encryption. Out of the total overhead for inter-domain operation, 6% results from the lazy-crypto protocol.

As the transactions measured were all read-only transaction, the commit phase did not have to write any data into the store. Hence there are no security overheads associated with this operation in either configuration.

The previous measurements all consider the performance overheads of security at the micro-level. It is useful to put these measurements into context at the macro-level by considering the impact on overall performance of the applications under various security configurations. It is important to note that the applications measured are batch-style, in that all the operations are carried out sequentially and automatically. PerDiS was designed to support interactive applications, where the activity would be more 'bursty' and the cost of accessing data would be spread over a larger time span. However, these figures are still relevant, as we are interested in assessing the impact of security at the 'bursty' times such as start-up or when an application is committed.

It is also worth noting that "overhead" is in proportion to the amount of time the application spends performing other tasks, and so cannot be compared from one application type to another.

A comparison of application run-times is shown below:

For application type #1 the overhead of security for the intra-domain configuration was 13 seconds (56%) and for inter-domain operation was 32 seconds (140%).

For application type #2 the overhead of security for the intra-domain configuration was 2 seconds (20%) and for the inter-domain configuration was 21 seconds (210%).

The evaluation of the role-in-task model for describing security policies concluded that the model was adequate for expressing access control requirements for our two test cases. It was interesting to note that for the first case the idea of a generic template was not applicable due to the classification of data into categories being very task specific. However, in the second case the task was more generic than a simple template, and the implementation would benefit from establishing tasks from other tasks as well as templates in cases where the same people fulfilled the same roles in different tasks.

In both cases we were able to accurately specify the access control policies, but in the first case we were not able to specify the controls on controlling the access control policies. More research into specifying this meta-access-control information would be useful.

The security tools were demonstrated being used to encode the security policies specified in terms of a role-in-task model into a representation for use by PerDiS. This demonstrated the flexibility of the tools and model in encoding and changing access control policies, and that the tools were complete in terms of the functionality required. It was concluded that a user study on the HCI aspects of using the tools would be useful.

In the second part of the report, we evaluated and interpreted the performance of the platform under different security configurations. It is clear, and to be expected, that a performance overhead must be paid for securing access to the data. For our more realistic scenario in application type #2, we pay about a 20% overhead for applying intra-domain security. This would provide us with access control and some auditing but no
encryption in an environment where eavesdropping is not an issue, and where we could trust the administration of the PerDiS software and applications. In the inter-domain environment where stronger auditing and authentication is required, and where data must be protected against network snooping, the costs rise to a 200% overhead.

The vast majority of the inter-domain overhead is incurred in the encryption and decryption of the data. This overhead could be significantly reduced by improving the implementation of the encryption used. For example, better encryption algorithms could be used. The current implementation employs DES with 56 bit keys; Schneier reports that the IDEA algorithm encrypts at twice the speed of DES, whilst employing a 128-bit key [7]. Further tuning could be applied to the communications implementation to better integrate the encryption within the socket layer. Such adjustments might reduce the inter-domain overhead to 100% or less.

For the measurements taken here all intra-domain data transfers occurred with no encryption of the data - a domain maps to a boundary within which communication does not need to be protected from eavesdropping. For communication beyond this boundary all data is encrypted. The PerDiS security model allows for the choice of whether or not to protect data using encryption to be specified on a per-cluster basis. Hence highly sensitive data can be encrypted for every network transfer, whether local or remote, whilst non-sensitive data can be sent in the clear even over untrusted networks, if desired. In such cases where the same amount of encryption is performed in both configurations the overheads for intra-domain and inter-domain are closer as shown in the figure below:

The performance benefit of intra-domain operation also depends on the mixture of 'cold' and 'warm' operations, and on the level of modification to data. The figures show that for 'warm' operations where the data is already available locally, the security overheads for both configurations are the same (as only access control is applied). If an application behaves by bringing all its data locally and working on it for some time, then the benefits of intra-domain compared to inter-domain operation will be lost. However, if there is a high level of data modification, causing the frequent invalidation of pages, resulting in more 'cold' operations to re-retrieve data from a remote PD, then the intra-domain configuration regains its advantage.

There are other factors to consider however. An intra-domain configuration has the additional management overheads of the secure distribution of the domain key to all its participants. It is also weaker, as a leak of the domain key by one member would lay all the other members open to attack. Auditing is also weakened, as authentication is based on the shared key - by contrast, in the inter-domain configuration authentication is based on the individuals' public key.

Also, the performance figures were obtained measuring two machines connected over a very fast local network. The overhead for encryption might become relatively less when the latency and slower data speeds of a wide-area network are taken into account.

To conclude, the report shows that the role-in-task model is successful in expressing security policies and that the implementation of the model is successful in allowing users to encode these policies using the provided security tools. Making use of and enforcing these policies incurs an overhead - the model and implementation allow a customisable level of security depending on the trade-off of the security required and the level of overhead that is seen as acceptable.

[1] C. Nascimento and J. Dollimore. "A Model for Cooperative Object Oriented Programming", Software Engineering Journal, Vol. 8, no.1, pp 41-48, 1993.

[2] George Coulouris, Jean Dollimore, Marcus Roberts. "Role and Task-based Access Control in the PerDiS Groupware Platform", Presented at Third ACM Workshop on Role-Based Access Control, George Mason University, VA.October 1998.

[3] George Coulouris, Jean Dollimore, Marcus Roberts. "Secure communication in non-uniform trust environments", Presented at: ECOOP Workshop on Distributed Object Security, Brussels, 20 July 1998.

[4] Tim Kindberg, George Coulouris, Jean Dollimore and Jyrki Heikkinen. "Sharing Objects over the Internet: the Mushroom Approach", IEEE Global Internet London Nov. 1996.

[5] Marcus Roberts. "Documentation for Security Tools", PerDiS Project Deliverable TD-1.2.C. Available online at http://www.perdis.esprit.ec.org/docs/T.D.1.2/TD12C.html, 1998.

[6] Marcus Roberts. "The PerDiSWeb Resource Management Tool", Available online at http://www.dcs.qmw.ac.uk/~marcusr/perdis/management-tool.html, 1999

[7] Bruce Schneier, "Applied Cryptography, Second Edition", Wiley, 1996.

[TD1.1A] George Coulouris, Jean Dollimore, Marcus Roberts. "Security Services Design". Available at http://www.perdis.esprit.ec.org/deliverables/docs/T.D.1.1/A/T.D.1.1-A.html, 1997

[TD1.2A] Marcus Roberts, George Coulouris, Jean Dollimore. "Design of Security in IPF" Available online at http://www.perdis.esprit.ec.org/deliverables/docs/T.D.1.2-A/TD1.2a.html, 1998