Work Package 1 : Security Requirements

The objective of this work package is to specify a comprehensive set of security requirements relevant to global computing that will be studied and addressed throughout the project. To achieve this objective this work package requires input both from industry and from the research community; the latter being often more forward-looking. The requirements are then consolidated and structured, so as to determine a reference set of requirements to be used throughout the project, and in particular in the analysis of case studies.

Since this work package provides requirements for the whole project, its work needs to be performed early in the project. In a physical meeting before or at T0+3 all the requirements gathered will be presented, and a binding decision about those that will be further studied in depth within the project will be made. The consolidation work will then go on until the end of the first year.

Scientific Objectives

The major objective of this work package is to define precisely the context of the project, by defining an extended set of security requirements. This will be done in three steps: requirements gathering, requirements refinement, and requirements consolidation.

The gathering of requirements will consider requirements from two different origins. First of all, we will consider low-level requirements such as information flow and resource security policies, attempting to consider the widest possible set of technologies, in order to match the rapid evolution of security requirements in global computing. For these low-level requirements, we will consider state-of-the-art security architectures in the context of global computing, and derive from them the requirements in terms of properties to be proven on mobile code.

Second, we will also consider higher-level requirements, such as the requirements that are specific to the use of a given framework, or even the requirements that are specific to a given application or category of applications. These requirements will be gathered by considering input from the industry via the EUP and our industrial partners. This will ensure the industrial relevance of the requirements considered.

The next step is to refine the requirements, determining in how far the different categories of security requirements match or complement one another, and selecting the most appropriate set of requirements to consider for the rest of the project. The final step is to consolidate the requirements, in order to present them in a simple and unambiguous way. This consolidation step will be most important for the higher-level requirements. These requirements will most likely be informally if not poorly defined, so an abstraction and formalization will be required in order to meaningfully address them in a rigorous and machine-supported way as is the goal of the project. We will select such an abstraction (most likely a semi-formal representation) and then represent the original requirements using this abstraction.

The resulting requirements should then be used as input by all the other work packages.

Existing results

There has been a lot of work on low-level security requirements, such as information flow security, see (Sabelfeld and Myers 2003) for an overview, and resource security, notably in the MRG project. Higher-level security requirements are extensively used in industry, for instance in programming guidelines, or in Common Criteria protection profiles, but have rarely been systematically investigated (a notable exception being Marlet and Le Metayer 2001). Security automata by Schneider may provide a way to characterize some of these properties.

Structure of the work package

The work package is structured into four tasks, which all start at the beginning of the project:

Task 1.1 Information Flow Security Policies

Information flow controls are an attractive way of achieving end-to-end security properties such as confidentiality and integrity. For example, the lack of information flow from secret to public data implies confidentiality; the lack of flow from tainted to untainted data implies integrity. We will build an attacker model leading to high-precision security definitions in the context of concurrent and low-level languages (such as byte code).

Task 1.2 Resource Security Policies

This task addresses the question of ensuring that downloaded code can run securely within the resources on offer at a given terminal. For example: will an application operate within the memory and time a terminal can offer? Do the services of the terminal operating system and libraries provide sufficient functionality? Will it interact safely with other applications on the terminal? This task will focus on enumerating relevant resources, beyond memory space and execution time, on identifying scenarios in which resource control influences the security of mobile applications, and on establishing criteria for resource policies.

Task 1.3 Framework-Specific Security

This task focuses on the security properties that result from the use of a given programming framework in an industrial setting. We will first gather raw security requirements from the industry, and then organize them into categories. The final step will be to express all the requirements in a more scientific way, possibly using a semi-formal language.

Task 1.4 Application-Specific Security

At this level, the main issue is not to ensure that the implementation of a module conforms to its specification, but that the specification of a module matches with the specification that its clients expect (for instance, a network stack should perform networking operations). This area has not been investigated much, therefore this task will mostly study some practical examples, in order to derive the kind of properties that are most promising. The next step is then to derive more general rules from these properties, and to identify the proof techniques that are most suited to handle them.

All tasks are performed in parallel, as they deal with different categories of security requirements, and each task will lead to the specification of requirements from the different proof technologies to be investigated in the project. The first two tasks will run for 6 months, the third one will run during the first 9 months of the project, and the last one will run during the whole first year. As mentioned above, within the first three months of the project, a specific meeting will be organized where the different requirements will be confronted.

Role in the project

The security requirements identified in this work package are used in all other work packages, as these security requirements are the ones that the Mobius security architecture should ultimately be able to certify.