According to our information the following outcomes, in the form of Public Deliverables, will be produced during the lifetime of the project. If our information is incorrect, please contact the TWEURO teamso that we can correct our list and provide links to the published material. We are happy to host public material for projects. This page was last updated on: 09-10-1998

Deliverable D06.1 is a public deliverable and consists of a summary and 6 more deliverables listed at the end of the section “PUBLIC CWASAR RESULTS“. The other deliverables have been classified as not for the public. However, D05.1 and D07.1 are available to participants of the EC Telematics Programme. If you wish to receive a copy, please identify and authenticate with the CWASAR project coordinator: winfried.kuehnhauser@gmd.de

The support of the European Commission for the CWASAR project ended in December 1996. Together with several new partners, the CWASAR consortium is now applying the results to build a Professional, industrial-quality product.
 Publication restrictions do not apply with respect to the CWASAR security concepts; results can be downloaded from their site.

The two main goals of the Cwasar security work are 1) to design a security architecture containing mechanisms capable of enforcing an expressive set of security requirements, or policies [1][2][3], and 2) to design tools enabling a user's informal security policy requirements to be translated onto the security architecture's mechanisms [4][5][6]. By expressiveness of security policy, we mean the ability to support security policies which match the varied needs of Cwasar users and their applications. Thus, the two themes of the security work-package are security architecture design and security engineering.

The first issue addressed is the design of a security mechanism allowing for expressive security policies. Our approach to security is to embed software black boxes, called custodians, into the architecture. A custodian is bound to any number of objects and enforces these objects' security. Moreover, a custodian contains a programme which is evaluated each time that an object it is bound to receives a request. Based on the programmed rules, access to the object may be permitted or refused, and supplementary actions such as logging in an audit file can also be taken. Expressiveness of security policy follows from using programmes to represent policies, as opposed to data structured mechanisms such as capabilities or
access control lists.

The purpose of the security engineering work topic is basically to offer the user with tools that aid him to cheaply translate the informal security policy requirements into a custodian that correctly represents these requirements. The work here centres around a security library which contains developed security policy components, e.g., public domain encryption software, and also developed custodians. These components can be reused and refined by a security administrator in the development of a new security policy. In general, the gap between an informal statement of security policy requirements and an implementation of these requirements is too large for it to be feasible for a security developer to reason whether the custodian is a complete and correct representation of his security policy requirements. Consequently, the library introduces an intermediary stage based on representing security policies within a high-level type declaration language [5]. The design gap between type declaration and (C++) coded custodian is removed through the use of code generation techniques- the design gap between policy requirements and policy specification is reduced by the use of formal tools, incorporated into the security library, which allow the policy developer to establish whether some properties (policy requirements) are satisfied by the
policy specification or not. Details of the library design and implementation can be found in [6].

One of the key points for the security architecture design is to define how the custodian model is integrated into the Cwasar functional specification and technical architecture. The design of the latter is the goal of work~packages 5 and 7, and so much interaction took place between all three work-packages. The output of the discussions is described in [1][2].
Security policy development as described above tackles the standard case, where there is a single development authority and a single set of user requirements. In a system spanning several countries, each service provider and each client usually have their own individual security policy in place. These policies will be independently developed, being subject also perhaps to different legal guidelines, e.g., laws on the use of crypthographic functions. A problem arises when users or data are governed by several security
policies, since the security rules of these policies may conflict. Catering for this problem requires a new concept termed a meta-policy. A meta-policy defines the cooperation rules of independently developed security policies. On one level, this is a specification tool, providing a framework to express how policies may interact and to reason about any conflicts arising from interaction, at a lower level, the concept requires mechanisms to be placed within a custodian that enforce the meta-political constraints during system operation. First steps can be found in [4][5].

Kühnhauser (W.), An executive summary on the security approach in CWASAR (html document).
[1] Bryce (C.), Kühnhauser (W.), Security in Cwasar. Cwasar Report, December 1996 (zipped postscript file).
[2] Bryce (C.), Kühnhauser (W.), Amouroux (R.), Lopez (M.), Rudnik (H.), Cwasar: A European Infrastructure for Secure Electronic Commerce, Cwasar Report, August 1996 (zipped postscript file).
[3] Kühnhauser (W.), A Paradigm for User-Defined Securiiy Policies, in Proceedings of the 14th IEEE Symposium on Reliable Distributed Systems, Bad Neuenahr, Germany, September 1995, pages 135-144 (postscript file).
[4] Kühnhauser (W.), A Framework to Support Multiple Security Policies, in Proceedings of the 7th IEEE Canadian Security Symposium, Ottawa, Canada, May 1995 (zipped postscript file).
[5] Bryce (C.), Security Engineering of Lattice-Based Policies. Cwasar Report, December 1996 (zipped postscript file).[6] Bryce (C.), The Skippy Security Engineering Framework, Cwasar Report, December 1996 (zipped postscript file).
Download the CWASAR Security Deliverable.

 [Business Project's Index] [CWASAR] [GROW] [ICARE] [SYRECOS] [TAMCRA] [News Links]