Paper Report:

Specification and Verification of Security Requirements in a Programming Model for Decentralized CSCW Systems

TANVIR AHMED and ANAND R. TRIPATHIUniversity of Minnesota

Student: Yu-Cheng HsiaoAdvisor: Dr. Gwan-Hwan Hwang

National Taiwan Normal UniversityInternet Computing Laboratory

Abstract

• Role-based model for programming distributed CSCW systems– Supports specification of dynamic security and coordination

requirements.• Model-checking methodology for verifying the security

properties– Ensure correctness and consistency of a design specification.– Ensure sensitive security requirements cannot be violated

when policy enforcement functions are distributed among the participants.

1 - Introduction – CSCW

• Computer-Supported Cooperative Work• Support cooperative activities involving a

group of users performing tasks related to some shared objectives.

• Examples of such systems include online conferencing, collaborative design and development, and workflow environments.

1 - Introduction – Security and Coordination Requirements

• Security and coordination requirements in CSCW systems tend to be dynamic and context-based, depending on the execution state of the collaborative tasks and history of participants' actions.

Example coordination relationshipsfrom Synthesizing Coordination Requirements for Heterogeneous Autonomous Agents

1 - Introduction – Security and Coordination Requirements

• The coordination requirements are often weaved with access-control concerns.

• Such requirements have been addressed in workflow systems to synchronize authorization and access control mechanisms with task-flow events.

• Specification and enforcement of dynamic security and coordination requirements in role-based models is an important problem.

• Role-based access-control (RBAC) models have been found to be naturally useful in CSCW systems because of their intrinsic ability to model organizational structures.

1 - Introduction – Security Policies• A security policy is a definition of what it means to be secure for a

system, organization or other entity.• For an organization, it addresses the constraints on behavior of its

members as well as constraints imposed on adversaries by mechanisms such as doors, locks, keys and walls.

• For systems, the security policy addresses constraints on functions and flow among them, constraints on access by external systems and adversaries including programs and access to data by people.

• Because the security policy is a high level definition of secure behavior, it is meaningless to claim an entity is "secure" without knowing what "secure" means. It is also foolish to make any significant effort to address security without tracing the effort to a security policy. from Wikipedia

1 - Introduction – Security Policies

• The expression of administrative-level security requirements.

• A distributed CSCW system may require decentralized management as no single organization, site, or participant may be trusted to act as a "reference monitor" for the management and enforcement of all of the policies of the system.

• Participants are designated by the CSCW system designer as untrusted for some of the policy enforcement functions.

1 - Introduction - Verification Methodology

• Ensure that in decentralized management of a CSCW system the assignment of ownership privileges for an entity to an untrusted participant does not result in violation of any sensitive security requirements.

• Determine safe assignments of ownership privileges in a design to satisfy the given set of security requirements.

1 - Introduction - Primary Contributions

1. Development of a role-based model together with a programming framework for specification of coordination and security requirements in distributed CSCW systems.

2. Development of a verification methodology based on finite-state model checking to ensure that a design expressed in this model satisfies a given set of requirements for coordination and security.

The verification methodology is used to ensure the following kinds of properties in a design:– User interactions follow coordination and task-flow requirements;– Roles do not have conflicting or inconsistent constraints;– Confidential information cannot flow to unauthorized users;– No access rights can be leaked to unauthorized users;– Authorized information can be accessed;– Any dynamic constraints on accessing objects can be satisfied.

2 - Goals and Related Work

• Develop a programming framework for constructing secure distributed CSCW systems from their high-level specifications.

• A role-based model that is used by the designer of a CSCW system for specifying its architectural design for integrating application-level components and users, and specifying the policies for role-based user participation, coordination, and security.

• A middleware system automatically constructs the distributed runtime system for a given design.

2 - Goals and Related Work

• Roles are defined in the context of an application rather than the global context of an organization.

• Such as: Team, Domain, Role Template

3 - Security Requirements in Role-Based Distributed CSCW Systems

1. Role Admission and Revocation Constraints2. Role-Based Coordination Requirements3. Dynamic Access-Control Policies4. Meta-Level Security Policies5. Information Flow and Access Leakage

3.1 - Role Admission and Revocation Constraints

• Role admission constraints specify the conditions that must to be satisfied for a user to be admitted in the role.

• These constraints can be based on:– user's current or past membership in some "prerequisite" roles (for

allowing admission)– or in "conflicting" roles (for denying admission),– history of past actions by a user,– and role membership cardinality.

• Because the role admission condition may not hold after a user has been admitted into the role, a role-revocation condition is needed to verify the validity of a participant's current membership in a role.

3.2- Role-Based Coordination Requirements

• Interrole coordination –Coordination between participants in different roles within an activity

• Intrarole coordination –Multiple members in a role need to coordinate among themselves– Intrarole coordination can be based on

independent, cooperative, or ad hoc modes for role task execution by the members.

3.3 - Dynamic Access-Control Policies

• Security requirements in CSCW systems tend to be dynamic in nature.

• Such requirements depend on the execution history of the collaborative tasks

• They may also depend on temporal conditions

3.4 - Meta-Level Security Policies

• Secure management of a CSCW activity requires correct enforcement of the associated policies.

• Specification of such meta policies assigning administrative privileges to a role for managing specific entities in an activity needs to be supported.

• Such policies may also be dynamic, requiring change in the assignment of administrative privileges depending on the execution state of the activity.

3.5 - Information Flow and Access Leakage

• Prevent information flow and access leakage to unauthorized user.

• Confidentiality requirements express such information-flow constraints.

• Decentralized policy enforcement and dynamic policies for admission of users into roles, it is important to ensure that any assignment of administrative privileges preserves integrity of access authorization and information confidentiality.

4 - A Role Based Model for CSCW Systems

• Activity: Abstraction of a collaboration or workflow task involving a set of users in various roles.

• Users perform collaborative tasks involving some shared objects/resources.

• In an activity, users are represented by their roles and within an activity roles are assigned privileges to perform certain tasks.

• Operation: Role-specific tasks.• An operation typically involves invocation of a method on an

object defined within the activity or creation of a new activity.

Central elements of the role-based specification model for programming distributed CSCW systems

1. Activity Template2. Roles3. Role Operations4. Events5. Shared Objects6. Nested Activities7. Meta Roles: Creator and Owner

4.1 - Activity Template

• An activity template defines a pattern for a CSCW activity.

• An activity is created and started by instantiating its template using a distributed middleware system.

• Any number of instances of a template can be dynamically and independently created.

4.1 - Activity TemplateAn activity represents a namespace, defining and encapsulating the following elements:– A fixed set of roles.– A fixed set of operations associated with each role.– A set of object types that are created and accessed through the role

operations.– A fixed set of child activity templates that can be instantiated through

the execution of role operations.Each nested activity instance defines an independent and separate namespace.

– A dynamic set of events that are generated during the life cycle of the activity, representing the execution history of the role operations.

4.1 - Activity Template

• An activity has a fixed number of roles within its scope; the set of operations associated with a role is also fixed.

• The creation of new nested child activity results in the creation of new set of roles that are visible only in the scope of that child activity.

• Events in the model are used for enforcing dynamic security requirements and coordination constraints.

4.2 - Roles

• A role can be viewed as a protection domain with a set of privileges represented by its operations, which perform actions on the objects in the activity's namespace.

• A role definition involves specification of three aspects:– Meta-level policies in regard to admission of users to the

role– Role operations– Conditions under which a role operation can be executed

4.3 - Role Operations• A role operation may have a precondition and an action.• An operation's precondition must be true to execute its

action.• The preconditions are expressed using predicates involving

events within the activity's namespace.• They can also include predicates related to role

memberships in the activity.• An operation's action can be one of the following:

– an object method invocation– creation of a new object– creation of a new nested activity.

4.4 - Events• Events and event counters are used in operation

preconditions and role constraints for specifying coordination and dynamic security policies.

• Events correspond to execution of role operations and creation/termination of child activities.

• Related to each role operation and activity, there are two types of events: start and finish.

• These events are implicitly generated by the runtime system.• An event-based predicate is expressed using logical

expressions involving event counts and event attributes.

4.5 - Shared Objects

• Shared objects are represented in the model by their types and method signatures.

• For an object, access-control policies are derived from the various roles' operations involving that object.

• These are used by the object servers to control access to their objects.

4.6 - Nested Activities• An activity can create child activities to perform certain subtasks.• A child activity must be defined within the scope of its parent

activity.• Each child activity defines its own namespace.• The nesting of activities results in creation of a hierarchically

structured namespace.• A nested activity may need to have access to the objects in the

scope of its parent activity.• For this, objects in the parent activity's namespace can be

passed as reference parameters to a child activity.• A nested activity definition includes a list of the parameter types.

4.7 - Meta Roles: Creator and Owner

• In the specification model, associated with every entity—activity, role, and object—there are two system-defined meta roles called owner and creator.

• These roles are used by the underlying middleware system for administrative purposes.

• The user who instantiates an activity or creates an object is the one and the only member of the creator role for that entity.

• This role membership is implicit and immutable.• This role has no permissions associated with it.• We call it a pseudo role.

4.7 - Meta Roles: Creator and Owner

• An owner role represents meta-level administrative privileges.

• An activity specification can specify only one of the roles as the owner role of an entity.

• This results in assignment of entity-specific ownership privileges to the role.

• In the implementation model, there is no concrete representation of the owner roles.

5 - A Specification Model For Decentralized CSCW Systems

• An activity is specified in XML and it is instantiated by a middleware to generate the runtime environment for the target system.

• Before realizing a system from its XML specification, its security properties are verified using model checking.

Three main concepts of the specification model

1. Hierarchical structuring of activities2. Scope rules for objects and roles3. Assignment of role members and passing of

objects as parameters to nested activities

Fig 1 - Role member assignment and object passing in hierarchical structuring of activities

Fig 2 - Task flow requirements in an examination activity

5.2 - Activity Template Specification

• []optional terms

• {}zero or more terms

• |choice

• Boldfacetags in XML schema

Fig 3 - Syntax for activity template definition

Fig 4 - Skeleton specification of Course activity template

5.3 - Condition Specification

Three kinds of conditions in the specification model:1. Role membership-related2. Event history-based3. Temporal• time: return the current time

5.3.1 - Role Membership Functions

• member(thisUser, roleId) : boolean• members(roleId) : List<RoleMember> • Count operator, #

• Ex: The count of the members in a role#(members(roleId))

Fig 5 - Syntax for condition definition: time-and role membership-based predicates

5.3.2 - Event-Based Predicates• Events for role operations and activities:

1. Start2. Finish

• List: ()– Ex: (EventName), #(EventName)

• Index: [i]– Ex: EventName[i]

• Each event have two predefined attributes:1. Invoker2. Time– Ex: opId.start(invoker=thisUser)

Fig 6 - Syntax for condition definition: event-based predicates

5.4 - Role Specification

1. Role Admission on Activity Creation2. Role Admission Constraints3. Role Validation Condition4. Operation Specification5. Role Activation Constraints

Fig 7 - Syntax for role definition

Fig 8 - Syntax for role operation definition

Fig 9 - Specification of examination activity template

5.5 - Meta-Policy Specification

• The rules for owner assignment for an entity – activity, role, and object – are as follows:1. Static Ownership Assignment2. Default Ownership Assignment3. Dynamic Ownership Assignment

Fig 10 - Specification of ExamSession activity template

Fig 11 - Owner assignments in the nested course activity template specification

Fig 12 - Owner hierarchies derived from Fig 11

6 - Design Verification Goals In Model Checking

• Different aspects of coordination and security requirements that a collaboration designer may specify as properties to be verified during the design process

• Verification Goals– Ensure the design specification is not inconsistent– Ensure security and coordination requirements

are satisfied by a specified design

6.1 - Verification Properties

1. Inconsistent Specification2. Task Flow3. Role-Based Constraints4. Information Flow and Confidentiality5. Access Leakage

6.1.1 - Inconsistent Specification1. Reachability of Operations

– All operations are reachable– Deadlock:

2. Satisfiability of Role Membership Constraints– No conflicting conditions for admission and validation– Cannot be satisfied example:

role A cannot be a member of role Brole C’s admission constraints require that its member has to be a member of both rola A and B when joining C

6.1.2 - Task Flow

• The task-flow requirements (permissible sequence of operations) are specified through preconditions of role operations

• Can be expressed using path expression constructs, such as sequence (;) and selection (()) with a count restrictor (:n), where n can be a constant, or “+” representing one or more and “*” representing unbounded.

Task-flow Requirement for the examination Activity

Fig 2 - Task flow requirements in an examination activity

6.1.3 - Role-Based Constraints

• Role constraint (RC) requirement example:

6.1.4 - Information Flow and Confidentiality

• Information flow (IF) requirement example:

6.1.5 - Access Leakage

• Access leakage (AL) property example:

6.2 - Verification Problem with Decentralized Policy Enforcement

• Two distinctly different assumptions and conditions under which a design can be verified1. Verification model with trusted owners:

The designer trusts all participants to correctly enforce the security policies for the entities under their ownership control

2. Verification model with untrusted owners:The designer may trust only a subset of the roles for policy-enforcement functions

7 - Verification Model• Based on SPIN

– SPIN: model checker with an automata theoretic approach• System model specified in PROMELA (Process Meta Language)

– PROMELA• C-like• Support for interprocess communication primitives

• System property: expressed in LTL (Linear Temporal Logic)– LTL temporal operators

• always (□)• eventually (◇)• until (U)

Important Issues in Applying Model Checking Techniques

1. Model extraction2. Initial assignment of participants3. Aspect-specific verification model

7.1 - Model Extraction

• XML specification only contains the coordination and security properties, require additional components for runtime control structures

• Components manage:– Activities– Roles– Operations– Events

Primitive Predicates• member (user, role): the user is a member of the role.• event(event type, user): the user has triggered the specified

type of event.• member (user, role, activity): the user is a member of the

role within the activity.• event(event type, user, activity): the user has triggered the

specified type of event within the activity.• count(event type, n): the number of occurrences of event

type is equal to n.• access(permission, object type, user): the user has the

permission on an instance of the object_type.

Abstraction

• For example, in the course activity, if some user C is an initial assignment to the assistant role, C will eventually be able to join the grader role. It can be expressed as a correctness requirement for the grader role as the following expression using LTL.

7.2 - Initial Assignment of Participants

• A design is verified with a specified number for initial assignment of participants to various roles.

• If this number of participants is lower than the number required to verify all the properties, the model checker either provides a trace pointing that the lack of participants resulted in a counter-example for a safety property or points the operations that cannot be reached.

• On the other hand, if the verification is successful with the specified number of participants, it does not ensure that all the verified properties will hold for a larger number of participants.

• The focus of this paper is on the verification methodology, assuming that an initial assignment of participants is given.

7.3 - Aspect-Specific Verification Models

• To overcome the state-space problem, we exploited various abstraction techniques in the verification model.

• A system model with all its properties intact produces a large search space.

• Some of the properties that are not of concern when verifying a specific property can be excluded from the verification model and independently verified.

Five Classes of Verification Models1. Model for Task-Flow Requirements

– verify reachability of operations and task-flow constraints2. Model for Role Constraints

– verify requirements related to role constraints that do not depend on operation execution history

3. Model for Information Flow– verify properties related to information flow

4. Model with Trusted Owners– verify the safety of the owner assignments in regard to information flow

and access leakage as a result of the “extended privileges” of an owner5. Model with Untrusted Owner

– verify the safety of owner assignments given that a subset of roles may not be trusted for policy enforcement functions

8 - Verification Methodology

• Specification Inconsistent– Specified operation can never be executed– Role can never have a member→ Modify design

• Specification Incorrect– Requirement is violated→ Modify design or requirement

Requirement Interdependency• A modification of the specification may lead to violation of

any of the previously verified properties, which would have to be reverified.

• Reduce iterations:– Follows precedence among the properties it checks.– It first checks a design for role and operation-related

requirements before verifying information flow, access leakage, and ownership-related properties.

– This ordering is motivated by the goal of modeling of primary entities of a specification – activities, roles, and operations – before modifying the design to satisfy higher-level security requirements.

Verification Steps

Task-Flow Model Role Constraint Model

Information Flow Model

Model with Trusted Owners

Model with Untrusted Owners

8.1 - Verification Model for Task-Flow Requirements

• Verify aspects related to coordination requirements, such as reachability of operations and task flow.

• Includes components related to activity creation, operations, and preconditions.

Fig 10 - Specification of ExamSession activity template

Fig 13 - Task model in PROMELA for ExamSession activity in Fig 9

LTL Expressions

8.2 - Verification Model for Role Constraints

• Ensure that all roles can have members, role membership constraints can be satisfied, and SoD properties are not violated

• Includes only components related to the role membership management aspects, such as static and dynamic role member assignment, role admission, and validation constraints

Example

• The static SoD that a user x cannot be a member of two roles r1 and r2.

• In the verification run, x is replaced by user identities and r1 and r2 are replaced with role names

Case Study

• Verification of RC1:– RC1 is a static SoD requirement (a member of a checker

role cannot be a member of candidate role).– An optimization of this process is to verify the property,

based on the only possible member in the checker role (C).– The following expression specifies that eventually there

does not exist a state, where C is a member of both checker and candidate roles.

– This requirement was satisfied.

Case Study

• Verification of RC2:– Users A and B are initial members of the student role.– The requirement is specified by negating the fact that eventually user A

is a member of the candidate role without starting the ExamSession instance es1.

– In this expression, an activity es1 is added to imply that the ExamSession_start event and the candidate role are in the same activity instance scope.

– As users A and B are added to the student role in nondeterministic steps, checking for either of their identities is sufficient for this verification.

– This requirement was satisfied.

8.3 - Verification Model for Information Flow

• Several confidentiality properties, such as noninterference, noninference, and nondeducible, have been formalized

Fig 14 - Information flow: object to object and subject to subject

Case Study

• Verification of IF1:– Users A and B are initial members of the student

role– User A of the examinee role cannot access the

content of the exam paper before start of his own exam session

Fig 15 - Trace of a counter-example: examiner leaked ExamPaper

Fig 16 - Trace of a counter-example: Checker leaked ExamPaper

Fig 17 - Trace of a counter-example: Candidate leaked ExamPaper

Case Study

• Verification of IF2:– The confidentiality requirement IF2, with user C being a member of the

assistant role– The requirement is expressed as a negation of the error behavior, that is, A is a

member of the candidate role and C is a member of the checker role in the same exam session, and candidate role member’s identity (A’s identity is known to C before the grade operation is finished by C).

– A counter-example was found where the candidate leaked his identity through the AnswerBook object, and the checker was able to access the identity during grading.

– The fact that candidate would not perform such an action was provided to the model.

– Hence, IF2 was satisfied.

8.4 - Verification Models with Trusted Owners

• The primary goal in developing these models is to verify that security requirements cannot be violated because of the extended privileges that are acquired by participants in any owner roles.

• There are two kinds of models developed in this class:1. To verify information-flow requirements, the Information-Flow

Model is extended with owner privileges on role membership information

2. To verify access leakage properties, the components for information flow are augmented with components representing object access including unrestricted access by owners

Case Study

• Verification of IF1, IF2:– In the next step, the information-flow properties

IF1, IF2 were satisfied with the current owner assignments.

Case Study

• Verification of AL1:– The requirement AL1 is related to access leakage

that the write privilege to the AnswerBook must be revoked when ExamSession terminates

– The requirement is specified by negating the fact that eventually there is a state where A’s ExamSession activity has been terminated and A has write access to an Answer_Book

– This requirement was satisfied

8.5 - Verification with Untrusted Owners

• The designer designates a subset of the roles that cannot be trusted for policy enforcement.

• The basic problem in verification of a system with some untrusted roles is to ensure that any specified or potential assignments of untrusted roles as owners for some entities are safe (they would not result in violation of any sensitive security requirements).

• Once the untrusted roles have been specified, the next step is to find all the other roles that these untrusted participants would be able to join.

• Among these roles, a subset may be owners of certain entities.• Such an entity is called potentially misbehaving as it can be owned by an untrusted

participant, who can potentially violate policies associated with it.• When verified, if this misbehaving entity violates a given security requirement, it is

called a consequently misbehaving entity.• The goal of our verification process is to identify the consequently misbehaving

subset of the potentially misbehaving entities.

Case Study

• Verification with Untrusted OwnerFig 18 - Potentially misbehaving entities derived based on a trust assignment in Fig 12

Conclusion• The work presented in this paper has been driven by the goal of building a

programming framework for constructing secure distributed CSCW systems from their high-level specification.

• We have presented here a role-based specification model to express dynamic security and coordination requirements, including administrative security requirements, in distributed CSCW systems.

• We have also developed a methodology, based on finite-state model-checking techniques, to verify the correctness and consistency of a design specification for a given set of security and coordination requirements.

• Based on the different aspects of the requirements to be verified, we have described development of five classes of models to address problems related to state-space explosion and interdependency of the requirements.

• An important aspect of this methodology is to verify that the ownership privilege assignments in a design do not result in violation of any critical requirements, when some of the roles cannot be trusted to correctly enforce any policy-management functions.