Fredrik Seehusen
email: fredrik.seehusen@sintef.no

Bjørnar Solhaug
email: bjornar.solhaug@sintef.no

Tool-Supported Risk Modeling and Analysis of Evolving Critical Infrastructures

Keywords: Risk analysis, interdependencies, critical infrastructures, ATM

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Critical infrastructures is a term that is commonly used to refer to assets and facilities that are highly essential for the functioning of a society. Such infrastructures include, for example, electricity and power generation and supply, gas and oil production and distribution, telecommunication, public health, and public security and emergency services. Clearly, the disruption of services that are provided by these infrastructures can be severe or even catastrophic. Critical infrastructures are therefore the subject of the strongest requirements to protection from hazards and risks. They are moreover often characterized by strong interdependencies, which means that the safety, security and reliability of some critical infrastructures strongly rely on such properties of several other.

Governments are both nationally and internationally taking measures to safeguard critical infrastructures. For example, at EU level the European Programme for Critical Infrastructure Protection (EPCIP) was created as a result of the European Commission's Directive EU COM(2006) [START_REF]Communication from the Commission on a European programme for critical infrastructure protection[END_REF]. The objective is to maintain a list of critical infrastructures across the EU, including the set of assets for which protection and incident preparedness is required. The directive stresses the strong interdependencies and the need to identify these in order to achieve the EPCIP objectives. It moreover prescribes risk management and risk assessment as necessary means to identify and document threats, vulnerabilities, risks and countermeasures. Clearly, such risk assessments need to systematically take into account the identified infrastructure interdependencies [START_REF] Braendeland | Modular analysis and modelling of risk scenarios with dependencies[END_REF][START_REF] Ligaarden | Using indicators to monitor security risk in systems of systems: How to capture and measure the impact of service dependencies on the security of provided services[END_REF].

Risk management is coordinated activities to direct and control an organization or a system with regard to risk, and includes the identification, analysis and mitigation of unacceptable risks [START_REF]International Organization for Standardization: ISO 31000 Risk management -Principles and guidelines[END_REF]. For critical infrastructures, risk analysis is particularly challenging because the overall risk picture can be strongly affected by changes in only a few of the systems; in order to continuously manage risks and maintain an adequate level of protection, there is a need to continuously maintain the validity of risk models while systems change and evolve. For this purpose the risk analysis process should be supported by methods and tools that cope with interdependencies in a systematic way, allowing traceability of changes from system to risk. However, established risk management guidelines, standards and methods [START_REF] Alberts | OCTAVE criteria version 2.0[END_REF][START_REF] Barber | The use of the CCTA risk analysis and management methodology CRAMM in health information systems[END_REF][START_REF]International Organization for Standardization: ISO 31000 Risk management -Principles and guidelines[END_REF][START_REF] Lund | Model-Driven Risk Analysis -The CORAS Approach[END_REF]14,[START_REF] Peltier | Information Security Risk Analysis[END_REF] largely view systems in a monolithic way and provide little support for handling change [START_REF] Lund | Evolution in relation to risk and trust management[END_REF][START_REF] Lund | Risk analysis of changing and evolving systems using CORAS[END_REF].

This paper presents a risk analysis tool that supports the modeling and analysis of changing and evolving risks. The tool supports traceability of system changes to risk models, as well as the explicit modeling and assessment of the impact of the changes on the overall risk picture. The tool is developed to support the method and the risk modeling language presented in [START_REF] Lund | Risk analysis of changing and evolving systems using CORAS[END_REF], and has been validated in the air traffic management (ATM) domain [17]. ATM systems are critical infrastructures with strong dependencies on other critical infrastructures such as communication, electricity and energy, positioning and satellite systems, transportation systems and emergency. Moreover, interdependencies in ATM are becoming even more relevant and critical with the ATM 2000+ Strategy [START_REF]EUROCONTROL: Air traffic management strategy for the years 2000+[END_REF] and the SESAR initiative (http://www.sesarju.eu/) as traditionally quite closed systems at national level are integrated at transnational, European level.

The structure of the paper is as follows. In Section 2 we give some background to risk analysis in general and to the risk analysis method and language that the tool presented in this paper is developed to support. In Section 3 we present the most important requirements to the tool, and in Section 4 we give an exampledriven presentation of the most important functionalities. In Section 5 we discuss the tool with respect to the identified requirements. Finally, in Section 6, related work is discussed before we conclude.

Background

According to the ISO 31000 risk management standard [START_REF]International Organization for Standardization: ISO 31000 Risk management -Principles and guidelines[END_REF] risk analysis should be regularly conducted in order to assess and mitigate risks. The standard defines risk analysis as an iterative process consisting of five consecutive steps. Establish the context is to define the external and internal parameters to be accounted for when managing risk, and to set the scope and risk criteria for the risk management policy. Risk identification is to find, recognize and describe risks. Risk estimation is to comprehend the nature of risk and to determine the risk level.

Risk evaluation is to compare the risk estimation results with the risk criteria to determine whether the risk and its magnitude are acceptable or tolerable. Risk treatment is the process of modifying the risk.

The purpose of the standard is to provide methodological advice on how to manage risk, and it offers no specific techniques for how to conduct the activities in practice. Nor does the standard prescribe any support or advice on how to identify and document risk, for example by means of risk modeling techniques and languages. Most of the established risk analysis methods have activities that generally follow the principles laid out by the standard, and commonly they also provide techniques and come with tools to support the activities. CORAS [START_REF] Lund | Model-Driven Risk Analysis -The CORAS Approach[END_REF] is an approach to model-driven risk analysis that is closely based on ISO 31000. It is self-contained in the sense that it offers a method that comes with concrete, practical guidelines, it comes with a language with modeling support and analysis techniques, and it comes with a tool that supports all activities.

In order to handle change, interdependencies and traceability in a systematic and methodic way, each activity must be supported by specialized guidelines and techniques. For this purpose the ISO 31000 process is in [START_REF] Lund | Risk analysis of changing and evolving systems using CORAS[END_REF] generalized to include such guidelines throughout the whole process, and this generalization is in turn instantiated in CORAS. At the same time the CORAS language is extended and generalized to offer risk modeling support for the traceability techniques and for explicitly modeling and assessing changes to risks. The reader is referred to [START_REF] Lund | Risk analysis of changing and evolving systems using CORAS[END_REF] for the details about the generalized method and language. In the following we highlight the most important principles, focusing on risk identification.

A part of establishing the context is to make a description of the target of analysis. The target description includes the documentation and models of the target of analysis, and serves as the basis for the subsequent risk assessment. It is therefore important that all relevant aspects of the target of analysis are properly documented. Moreover, dependencies to other systems and infrastructures must be included in the description of the environment in order to capture how external factors may affect the risks. An important aspect of the generalized process is that possible changes and evolutions are explicitly taken into account during context establishment and documented as part of the target description.

The risk identification involves identifying and documenting unwanted incidents with respect to the target of analysis and the identified assets. In the generalized approach, a further objective is to identify and document the changing risks given the description of change in the target of analysis. A main principle is that to the extent that we have identified and documented the risks for the target of analysis before changes, we only address the parts of the target that are affected by the change. The methodological guidelines are summarized as follows. 1) Identify and document risks by using as input the target description before changes have been taken into account. 2) Establish and document the traceability between the target description before change and the risk documentation resulting from the previous step. 3) Based on the traceability and the description of the changed target, identify the parts of the risk documentation that are persistent under change. 4) Conduct the risk identification of the In conducting these activities we make active use of three model artifacts, namely the target model, the risk model and the trace model. The target model needs to capture the relevant aspects of the target of analysis and can be built using any suitable notation, such as the UML [START_REF]Object Management Group: OMG Unified Modeling Language (OMG UML), Superstructure[END_REF]. For risk modeling CORAS threat diagrams are used. Threat diagrams document risks by describing how threats exploit vulnerabilities to initiate threat scenarios and unwanted incidents. A risk is the likelihood of an unwanted incident and its consequence for a specific asset. Risks are estimated by annotating each identified unwanted incident with a likelihood and a consequence. The graphical language constructs are shown in Figure 1, and an example diagram is depicted in Figure 5.

The trace model is part of the generalized CORAS approach and is used to build links between elements of the target model and elements of the risk model. The links are depicted in CORAS diagrams by means of the target segment construct which is an extension of the standard CORAS language. A further extension is the support for the explicit modeling of risk changes. Each CORAS language element can be assigned one of the three modes before, after and beforeafter. The mode before captures elements of the risk picture that become obsolete after change and are depicted in gray. The mode after captures elements that emerge after change and are depicted in the standard way with colors. The mode before-after captures elements that are persistent under change and are depicted using a double layer. Moreover, because the likelihoods and consequences of the latter elements may change these values are annotated in pairs, where the former is the value before change and the latter is the value after change. Examples of the use of these modes are shown in Figure 7.

A full risk analysis will typically result in a large number of threat diagrams covering the various parts of the target description. Without any automated tool support the task of tracing changes from the target model to the risk model must be conducted manually. Moreover, keeping track of how changes percolate, and correctly and consistently assigning modes to the risk elements, can be challenging. Hence, making efficient use of the generalized risk analysis method and the traceability requires proper tool support.

Tool Requirements

The tool is mainly a diagram editor that is designed to support on-the-fly risk modeling during structured brainstorming. The brainstorming sessions involve one or two risk analysts as well as four to seven people with expert knowledge about the target of analysis. The tool is operated by a risk analyst who draws diagrams that are displayed to the participants while the discussions proceed. There are of course many requirements that apply for such a tool to adequately support the whole risk analysis process. In this section we focus on the requirements that are relevant for handling dependencies, traceability and change.

First and foremost, for the tool to fulfill its purposes it should support the specification of all kinds of CORAS diagrams using the language generalized to capture the three different modes with respect to change. Next, in order to deal with traceability the tool must support the specification of traceability links from elements of the target model to elements of the risk model. This, in turn, requires the tool to import (a representation of) the target model. CORAS does not prescribe a specific notation to be used for the target modeling, as different languages may be suitable in different risk analyses, so the tool should be able to import models irrespective of the chosen language.

Whereas we have generalized the CORAS language to explicitly model change, we cannot assume the corresponding expressiveness in the language chosen for the target modeling. Instead we assume that the target model is modified to reflect the changes, such that we have one model before the changes and one model after the changes. The specific parts of the target of analysis that have changed must then be determined by comparing the two models and generating the diff. For detecting changes and supporting traceability, this should be conducted automatically by the tool. Based on the specified traceability links and the diff, the system changes can now be traced to the parts of the risk model that may be affected. This should also be supported by the tool by automatically flagging the affected diagrams of the risk model.

When reassessing the risks the threat diagrams are updated by assigning modes of change to the elements. While the generalized language is useful for the documentation of and the reasoning about risk changes, it may be challenging to keep track of how changes percolate through the threat diagrams and to maintain consistency with respect to change. For this purpose there should be automatic support for detecting and resolving inconsistencies in the diagrams.

In the following the requirements to the tool that are relevant for handling dependencies and change are summarized.

Tool Functionality and Features

In this section we describe and exemplify the most important functionality and features of the tool regarding the support for handling traceability and change.

The tool has been developed as a plugin to Eclipse such that it can be easily extended with new features and easily integrated with other Eclipse-based tools.

To ensure that the models that are created using the tool are stored in a standard format, it is based on Eclipse Modeling Framework (EMF). The examples that we use are from the ATM domain and have been extracted from validation activities involving experts on ATM and on secure system engineering [17].

The main use of the tool is as a diagram editor for creating CORAS diagrams. The interface is shown in Figure 2 with the drawing canvas in the middle. The palette to the left contains all language elements and relations, and diagrams are created easily by drag-and-drop. For each diagram that is created, the user must first choose the kind of CORAS diagram. The syntactically correct diagram is defined by the meta-model of the language, and the tool automatically prevents the user from making diagrams that are grammatically incorrect.

As mentioned above, the risk identification and the creation of the threat diagrams are conducted by systematically going through the target model trying to determine where things can go wrong and how. The ATM validation activities addressed the initial phases of a system engineering process for the development of ATM services provided by an Air Navigation Service Provider (ANSP) in Area Control Centers (ACCs). The requirements were captured in collaboration with the ANSP and modeled as SI* goal models [START_REF] Massacci | Security requirements engineering: The SI* modeling language and the Secure Tropos methodology[END_REF]. A small fragment of the requirement model, which served as the target model, is shown in Figure 3. The risk analysis tool is designed to import the target model independent of the language that is chosen for making the target description. To this end, all target models must conform to a meta-model, TM, for the representation of the target model in the tool. This meta-model is shown in Figure 4 simplified to focus on the conceptual aspects), and is defined to capture the parts of the target of analysis that are relevant for reasoning about risk, namely actors (which can be human and non-human), events that may occur, and scenarios that may unfold. Because the tool can take arbitrary target models as input, the user needs to define a mapping from the meta-model, MM, of the target model to the meta-model, TM, of the tool. The only requirement is that MM is defined according to an Ecore meta-model, which is the EMF specification of meta-models. The mapping is defined by a set of transformation rules that apply to elements, element attributes and element references. In the ATM case study with the use of SI*, we have, for example, mapped actor/role to actor and goal to scenario, including the names and the goals that are attributed to the actor/role. The specification of the transformation is a one-off task for the selected target modeling language; it is stored in a text file that is loaded by the tool together with the meta-model of the target model (here the SI* meta-model).

The tool is now ready to import the target model that is used. The purpose of importing the target model to the tool is to be able to specify traceability links, not to view or edit the target models, which instead is conducted separately in a designated tool. In order to be able to uniquely refer to the separate elements of the target model the tool creates an index of all elements, where each index is represented by a tuple (ID, Name, Category, Description, Mode). ID is a unique automatically generated identifier, Name is the name of the element as specified in the target model, Category is the kind of target model element (Actor, Event or Scenario), and Mode specifies the mode of the target model element with respect to change. Description is an initially empty field that can be filled in by the user if further explanation is desired or needed. The set of index tuples are represented in the tool in the table format shown at the bottom of Figure 5. Note that the mode of all target elements are currently before since no changes have yet been specified for the target system.

Given the threat diagrams and the index of the target model, traceability between them can be specified by defining mapping rules. Basically, a mapping rule is a pair of a target model element and a risk model element. Additionally, each mapping rule is given a tag with a chosen name for the mapping rule. In the visualization of the mapping rule in the threat diagrams, the name of the tag is automatically inserted. For example, in Figure 5 a mapping rule pairs target element with index i38 (CWP) with the vulnerability Lack of authentication at CWP. A further purpose of using the tag is that it allows several mapping rules to be clustered. For example, all three actors in Figure 3 are ATCOs, and for Given the target model, the finalized risk model, and the trace model, the process is ready to proceed with handling changes that may occur. Two of the changes that were addressed in the ATM case study were the introduction of the AMAN and the SWIM. AMAN (Arrival Manager) is a decision support tool that automates the sequencing of flights in arrival management. The AMAN therefore needs to be fed with all relevant flight data, including State Flight info. SWIM (System Wide Information Management) is an information network that will integrate information systems and facilitate the flow of information between entities such as aircrafts, airports, ACCs, ATCOs, ANSPs, etc. Previously, State Flight info did not have to be digitally stored and shared, but could be kept separate from flight data (cf. Figure 3). With the AMAN introduction, however, this information needs to be part of the general flight data and shared over the SWIM network. This raises new security threats, for example with respect to the confidentiality of State Flight info, which is an asset in our case study.

The first step in addressing the changes is to update the target model. As a result we have two target models, one for the situation before changes and one for the situation after changes. To determine what has changed we need to compare the two models. This is supported by the tool by the automatic generation of the diff, which is done by comparing two target model files as specified by the user.

Fredrik Seehusen, Bjørnar Solhaug

The target element related to this risk element has been changed.

Fig. 6. Automatic flagging of changes

In practice, the tool first transforms the two models to its own target model representation and generates the diff based on this. It thereafter updates the index to include the changes and setting the correct change mode to each target model element. Due to space constrains we do not show the updated SI* model after change, but at the bottom of Figure 6 we see some of the new indexes with their mode. For example, System engineer is an actor that was included after the changes, whereas ACC supervisor is in the target model both before and after.

Due to the changes in the target of analysis, some parts of the risk analysis may have to be conducted anew. The tool supports the identification of the affected threat diagrams by flagging all risk model elements that are related to changes in target model elements. This is shown in Figure 6 with the warning sign on the unwanted incident State flight info accessed by unauthorized personnel and the pop-up message on the screen.

In reassessing the risks that are documented in the flagged threat diagrams, we need to determine which parts become obsolete and which parts are persistent, and we also need to identify new risks that may arise. The explicit modeling and assessment of such changes are supported by the generalized language and by the tool by assigning one of the modes before, after and before-after to each element. This is exemplified in Figure 7, where, for example, the threat scenario Maintenance engineer gets access to ACC control room has mode before, the threat scenario Technical supervisor gets access to SFPL via SWIM has mode

If the source has mode before, then the target cannot have undefined mode. X Fig. 7. Modeling change and resolving inconsistencies after, and the unwanted incident State flight info accessed by unauthorized personnel has mode before-after. Note that the default mode is undefined, i.e. when a new element is inserted there is no mode assigned to it.

While the generalized language supports the assessment and documentation of changing risks, the increased complexity makes it more challenging to keep diagrams consistent. For example, a threat diagram element of mode before cannot be related to an element of mode after as they do not coexist. Moreover, a threat diagram element should not have an undefined mode when it is related to elements where the mode has been specified. To support the user in modeling risk changes the tool does automatic consistency checking, and warnings pop up whenever an inconsistency in introduced. Each inconsistency is flagged with a red circle with a white cross, for example on the relation between the threat Maintenance engineer and the threat scenario Maintenance engineer gets full access to flight data via SWIM. This is, as the shown pop-up explains, because the former is assigned mode before and the latter has undefined mode. A further example is on the relation between the unwanted incident (in mode before-after) and the asset (in undefined mode); the latter should also be in mode before-after.

In addition to detecting errors, the automatic consistency checking is very useful for systematically tracing changes through the threat diagrams. For example, when starting from the left and assigning a mode to the threat, warnings will immediately be flagged on the relations to the adjacent elements. When resolving this inconsistency these warnings disappear, and new ones emerge one step further to the right. The user can in this way update the diagram step by step while maintaining the consistency.

Finally, when all threat diagrams are updated, finalized and consistent, new mapping rules should be defined to establish the traceability with respect to the updated target model. This ensures that all documentation is ready for any further future changes that need to be dealt with in the same way.

Discussion

In this section we discuss the tool with respect to the requirements identified in Section 3. As mentioned before, these requirements focus on the need for tool support for handing dependencies, traceability and change. For a more general evaluation that also takes into account the methodological support and the language support, the reader is referred to [17].

The tool should support on-the-fly modeling of syntactically correct CORAS diagrams with change. The tool is a diagram editor with all language constructs immediately available by drag-and-drop from the palette. Relations between the elements can moreover easily be attached by click-and-drag, where the tool automatically selects the syntactically correct relation. Moreover, as the tool implements the meta-model of the CORAS language, the user is prevented from making diagrams that are grammatically incorrect. An exception from the latter is the use of the extended notation to enable the modeling of risk changes; instead of preventing the user from making inconsistencies with respect to change, the tool automatically flags all such errors. However, this is intended as diagrams are updated in a stepwise manner when change is brought into the picture. If inconsistencies with respect to change was prevented, the users would have to build all the diagrams from scratch instead of updating them.

The tool should support the importing of the target models irrespective of the chosen language for target modeling. The tool is designed to import target models of arbitrary languages, since different notations are suitable for different kinds of target systems and since different communities can have different modeling preferences. The tool therefore uses one common and generic meta-model for all target models. This is at the cost of users having to specify the transformation from the meta-model of the chosen language to the meta-model used by the tool, which requires some expertise in language design. However, this is a one-off task for a given target modeling language, and the benefit is of course that the use of the risk analysis method and tool is not restricted to only one target modeling language. Still, one restriction with respect to the choice of target modeling language is that the its meta-model must be an Ecore meta-model.

The tool should support the specification of traceability links between elements of the target model and elements of the risk model. This is supported by the functionality of defining mapping rules. In order to be able to specify all possible mapping rules, it is necessary that all elements of the target model are indexed by the tool. This in turn requires that the transformation rules mapping the meta-model of the target modeling language to the meta-model in the tool is complete, i.e. that it covers all elements of the target model. For some languages, it may be that the meta-model of the tool is not rich enough, resulting in dependencies that cannot be captured automatically.

The tool should automatically generate the diff between the target model before changes and the target model after changes. This is supported by the tool by comparing the two models and generating the diff between them, identifying elements that are deleted, added or modified. The diff is generated by comparing the representation of the target models in the tool, i.e. according to the target meta-model of the tool. As for the traceability, this means that if there are target elements that are not captured by this meta-model, changes to these are not captured. As an alternative to using a generic target meta-model in the tool, the tool could be customized for one specific target modeling language, such as the UML or SI*. The tool would then use the meta-model for this specific language, and all elements and changes would be captured. Moreover, the user would not have to specify the transformation rules for the meta-model. When designing the tool we aimed for flexibility and general applicability, which explains our design choice. However, customized versions could be developed by replacing the generic target meta-model with any specific one.

The tool should automatically flag all elements of the risk model that are affected by the system changes and therefore have to be reassessed. This is supported by the tool, but the extent to which all affected threat diagrams are flagged depends on two things. First, the generated diff must be able to capture all system changes as discussed above. Second, the users of the tool of course need to specify mapping rules that cover all system changes that occur.

The tool should provide support for detecting and resolving inconsistencies with respect to change. This is supported by the flagging of inconsistencies as discussed above. Resolving the inconsistencies must be conducted manually, but the user can immediately see when consistency is restored.

Related Work and Conclusion

Model Versioning and Evolution (MoVE) (http://move.q-e.at/) [START_REF] Breu | MoVEing forward: Towards an architecture and processes for a Living Models infrastructure[END_REF] is an approach to build an infrastructure to maintain the validity, mutual consistency and interdependencies between models as they evolve over time within model engineering. The approach does not target security and risk in particular, but rather builds a tool-supported infrastructure for versioning of several interdependent models, for example for software architecture and design, business processes, services, security and risk. Similar to our approach, the underlying idea is to provide support for tracing changes from one model to another so as to ensure that they are globally up-to-date and mutually consistent. However, although the infrastructure can support the handling of dependencies and change in risk analysis, as exemplified in a case study, there is no specific modeling or methodological support for this. Instead the user chooses the models and notations, such as CORAS or UML, to be managed by MoVE.

ProSecO [START_REF] Innerhofer-Oberperfler | Using an enterprise architecture for IT risk management[END_REF] is a model-based approach to risk analysis with support for dependency identification and modeling. The approach relates risk elements to elements of a functional model of the target of analysis. Moreover, the model elements are related to security objectives and security requirements, and risks are related to threats and security controls. Although risk assessment is supported, there is no risk modeling support other than a description of incidents and their likelihood and consequence.

Dependent CORAS [START_REF] Braendeland | Modular analysis and modelling of risk scenarios with dependencies[END_REF][START_REF] Lund | Model-Driven Risk Analysis -The CORAS Approach[END_REF] is an extension of the CORAS language to support modular risk analysis, as well as the modeling and reasoning about interdependencies. However, the purpose is not to capture and model dependencies of the risk models on the target system, but rather interdependencies between different risk models. This is in particular relevant for mutually dependent critical infrastructures, where the risks and risk level of one can strongly depend on the risks and risk level of the other. Tool support is provided for creating and editing Dependent CORAS diagrams, but there is no automation of dependency analysis. In [START_REF] Ligaarden | Using indicators to monitor security risk in systems of systems: How to capture and measure the impact of service dependencies on the security of provided services[END_REF] a method is proposed to capture and monitor the impact of service dependencies in interdependent systems of systems. The dependencies between system services are explicitly modeled, and subsequently taken into account during risk identification and modeling. However, the problem of tool-supported traceability between system elements and risk elements is outside the scope.

In [17] an approach to integrate risk assessment and modeling with system development and modeling to aid the handling of dependencies and change between the two domains is presented. The former is supported by the Rinforzando tool and the latter by the SOA Modelling Suite (SMS). The tool supports tight integration between the system model and the risk model in several ways. For example, in the risk models assets and supporting equipment, technologies, work processes, etc. can be selected directly from the SMS target models. Moreover, dependencies are continuously maintained such that modifications in one model is either automatically propagated to the other model, or warning flags appear as pop-ups. This integration of system and risk model is tighter than in our approach, but it requires the use of SMS for system modeling. Furthermore, explicit modeling of risk changes is not supported as the objective is rather to maintain the mutual consistency between models.

In this paper we have presented a tool to support the method and language presented in [START_REF] Lund | Risk analysis of changing and evolving systems using CORAS[END_REF], enabling the traceability from the target of analysis and/or its environment to the risks. The tool gives automated support for tracing changes and identifying risks that need to be reassessed in order to maintain the validity of risk models, as well as automated support for maintaining consistency of risk models. The tool has been validated in the ATM domain, which is a critical infrastructure with strong dependencies on other infrastructures.

Further work is required for evaluating and validating the tool with the use of different modeling languages for capturing the target of analysis, although the results have been promising in case studies so far. A further topic for future work is to develop a tighter integration between the target model and the risk model to support mutual consistency and automated updates of model elements in case of changes.

Fig. 1 .

 1 Fig. 1. Elements of CORAS threat diagrams

-

  The tool should support on-the-fly modeling of syntactically correct CORAS diagrams with change. -The tool should support the importing of the target models irrespective of the chosen language for target modeling. -The tool should support the specification of traceability links between elements of the target model and elements of the risk model. -The tool should automatically generate the diff between the target model before changes and the target model after changes. -The tool should automatically flag all elements of the risk model that are affected by the system changes and therefore have to be reassessed. -The tool should provide support for detecting and resolving inconsistencies with respect to change.

Fig. 2 .

 2 Fig. 2. Creating CORAS diagrams

Fig. 3 .

 3 Fig. 3. Modeling the target of analysisSI* models show the goals (rounded rectangles) that actors/roles (circles) seek to achieve, as well as the resources (rectangles) that are needed for achieving the goals. Non-functional requirements, such as security goals, are captured by soft goals (clouds). A delegation marks a passage of responsibility for achieving a goal (delegation execution, De) or of authority with respect to a resource (delegation permission, Dp). Trust is a relation between actors/roles representing the expectations of the trustor about the capabilities of the trustee (trust execution, Te) or about the behavior of the trustee with respect to a permission (trust permission, Tp). Figure3shows three air traffic controllers (ATCOs) and some of their goals in the sequencing of flights during arrival management. The ACC supervisor is supervising the ATM activities, and is also responsible for protecting the confidentiality of State Flight info. A State Flight is any flight involving military, customs, police or other law enforcement services of a state, or any flight declared as such by state authorities. ATCOs need access to State Flight info since these flights are sequenced differently than commercial flights, but at the same time the information must be kept confidential to prevent misuse by potential adversaries. The Tactical controller is responsible for sequencing the arriving flights, and is supported by the Planner controller in achieving some of the sub-goals. The latter two ATCOs rely on several resources, such as the controller working position (CWP), which is their workstation.The risk analysis tool is designed to import the target model independent of the language that is chosen for making the target description. To this end, all target models must conform to a meta-model, TM, for the representation of the target model in the tool. This meta-model is shown in Figure4(somewhat

Figure 3

 3 shows three air traffic controllers (ATCOs) and some of their goals in the sequencing of flights during arrival management. The ACC supervisor is supervising the ATM activities, and is also responsible for protecting the confidentiality of State Flight info. A State Flight is any flight involving military, customs, police or other law enforcement services of a state, or any flight declared as such by state authorities. ATCOs need access to State Flight info since these flights are sequenced differently than commercial flights, but at the same time the information must be kept confidential to prevent misuse by potential adversaries. The Tactical controller is responsible for sequencing the arriving flights, and is supported by the Planner controller in achieving some of the sub-goals. The latter two ATCOs rely on several resources, such as the controller working position (CWP), which is their workstation.

1 Fig. 4 .

 14 Fig. 4. Meta-model for generic target model

Fig. 5 .

 5 Fig. 5. Defining mapping rules elements of the risk model to which all three are related we can create three mapping rules with the same tag, ATCO.Given the target model, the finalized risk model, and the trace model, the process is ready to proceed with handling changes that may occur. Two of the changes that were addressed in the ATM case study were the introduction of the AMAN and the SWIM. AMAN (Arrival Manager) is a decision support tool that automates the sequencing of flights in arrival management. The AMAN therefore needs to be fed with all relevant flight data, including State Flight info. SWIM (System Wide Information Management) is an information network that will integrate information systems and facilitate the flow of information between entities such as aircrafts, airports, ACCs, ATCOs, ANSPs, etc. Previously, State Flight info did not have to be digitally stored and shared, but could be kept separate from flight data (cf. Figure3). With the AMAN introduction, however, this information needs to be part of the general flight data and shared over the SWIM network. This raises new security threats, for example with respect to the confidentiality of State Flight info, which is an asset in our case study.The first step in addressing the changes is to update the target model. As a result we have two target models, one for the situation before changes and one for the situation after changes. To determine what has changed we need to compare the two models. This is supported by the tool by the automatic generation of the diff, which is done by comparing two target model files as specified by the user.

Acknowledgments. This work has been partially funded by the European Commission via the NESSoS (256980) network of excellence.


Chengjun Wang

Baokang Zhao
email: bkzhao@nudt.edu.cn

Wanrong Yu
email: wlyu@nudt.edu.cn

Chunqing Wu
email: wuchunqing@nudt.edu.cn

Zhenghu Gong

Routing Algorithm based on Nash Equilibrium against Malicious Attacks for DTN Congestion Control

Keywords: Delay-Tolerant Network Routing, Congestion Control, Gaming theory, Nash equilibrium

In Delay-Tolerant Network(DTN), certain malicious node might generate congestion in attack to reduce the overall performance of the whole network, especially the target of message successful delivery ratio. In this paper, a novel Nash equilibrium based congestion control routing algorithm with the function of security defense (NESD) is proposed. In the process of message delivery, node can use Nash equilibrium to compute the largest proportion of transfer messages occupancy to node memory capacity. This mechanism constrains the attack from malicious node and guarantees the message transfer of regular node. This congestion control routing algorithm for security defense is evaluated by experiment. It is important application in the field of homeland defense. The results show that related key parameters are significantly improved in DTN scenario.

Introduction

DTN [START_REF]DTNRG:Delay-tolerant networking research group[END_REF] is widely applied in the obscure or tragedy district [START_REF] Pentland | DakNet:Rethinking Connectivity in Developing Nations[END_REF], vehicle network [START_REF] Burgess | Maxprop: Routing for Vehicle-Based Disruption-tolerant Networks[END_REF], satellite communication [START_REF] Burleigh | Delaytolerant Networking: an Approach to Interplanetary Internet[END_REF] and other wireless network environment.These fields mostly have close relationship with homeland defense.It resolves the problem of intermittent connection, high latency, low data transfer speed, high packet loss rate in DTN by adding a bundle layer [START_REF] Scott | Bundle Protocol Specification[END_REF] between the traditional transmission and application layer and designing storage transfer protocol [START_REF] Fall | Custody Transfer for Reliable Delivery in Delay Tolerant Networks[END_REF].

As a special wireless network environment, the chief goal of DTN is to guarantee the message successful delivery ratio. The previous algorithms mostly adopt the mechanism of increasing message replicas [START_REF] Vahdat | Epidemic routing for partially connected ad hoc networks[END_REF] or leverage the historical information of node's encounter probability [START_REF] Lindgren | Probabilistic routing in intermittently connected networks[END_REF] as the criterion of transfer node selection in the message delivery.

Meanwhile, limit of DTN resource causes the congestion which also affects the message successful delivery ratio in some extent. Previous congestion control algorithms mostly adopt the passive message delete [START_REF] Jain | Congestion Avoidance in Computer Networks with a Connectionless Network Layer:Concepts,Goals,and Methodology[END_REF] or migration [START_REF] Seligman | Storage routing for DTN congestion control[END_REF] when congestion happens, or adjust message generation ratio and sending speed by feedback control system [START_REF] Hollot | A Control Theoretic Analysis of RED[END_REF]. This kind of method usually is passive and lagging. In some extent, it results in the frequent jitter of traffic and unstable network environment.

These methods mostly assume that network nodes are regular and it doesn't consider the presence of malicious nodes. Malicious node tends to forge the probability of its encounter with the target node. High encounter probability is forged by malicious node (Blackhole Attack) [START_REF] Feng | Thwarting Blackhole Attacks in Distruption-Tolerant Networks using Encounter Tickets[END_REF]. Message transfer request is accepted and then received message is discarded. Or malicious node forges the low probability of its encounter with the target node (Resource-Misuse Attack) [START_REF] Vivek | Resource-Misuse Attack Detection in Delay-Tolerant Networks[END_REF] which occupies the memory of transfer node and causes network congestion. Two attack methods both block the communication between the other nodes and target nodes and this reduces message successful delivery ratio. The impact of attack is visible in the field of homeland defense.

The presence of malicious nodes causes the failure of the past mechanism which passively controls congestion in order to guarantee the message successful delivery ratio. The active congestion control mechanism to deal with the attack of malicious nodes should be adopted. This paper leverages the Nash equilibrium in game theory [START_REF] Martin | An Introduction to Game Theory[END_REF] to allocate node memory appropriately that makes the fair sharing of local node memory between existing messages in this node and messages which are about to be transferred to this node. This mechanism not only satisfies the essential message transfer operation for message successful delivery and but also avoids the arbitrary message delivery from malicious node to regular nodes. This attack behavior of malicious node makes regular node's whole memory is occupied by malicious node's transfer message which causes the congestion and packet loss in the regular node. It reduces the overall message successful delivery in the network.

Related Work

To increase message successful delivery ratio, the simplest way to leverage message replica is the flooding routing [START_REF] Vahdat | Epidemic routing for partially connected ad hoc networks[END_REF]. This unrestricted duplication of message is a great waste of bandwidth resource. In [START_REF] Spyropoulos | Spray and Wait: An Efficient Routing Scheme for Intermittently Connected Mobile Networks[END_REF], the authors improve this mechanism by transferring message replicas to all the neighbor nodes in the first communication. Then, these nodes deliver message directly which decreases the amount of replicas, but the successful delivery ratio is obviously affected. In [START_REF] Spyropoulos | Efficient routing in intermittently connected mobile networks:the multiple-copy case[END_REF], the authors comprehensively consider the tradeoff of resource utilization and successful delivery ratio. It provides message replicas to the successive transfer nodes with the decreasing probability until the message is delivered to destination node at last.

The most popular message delivery strategy is routing algorithm based on the historical information of node encounter probability [START_REF] Lindgren | Probabilistic routing in intermittently connected networks[END_REF]. This algorithm adopts storage transfer protocol and node carries message until it encounters the node which has larger probability to meet destination node. This is just the common measure which malicious node uses to attack in DTN. It forges its encounter probability with destination node to destroy usual transfer of message in DTN. Thus, the successful delivery ratio of message is reduced.

To assign different functions for nodes, they are classified as regular node and ferry node. In [START_REF] Zhao | A message ferrying approach for data delivery in sparse mobile ad hoc networks[END_REF], regular node use random movement and ferry node is transferred in a constant path to assist message delivery of the regular node. This resolves many issues in the traditional DTN network. But the path selection of ferry node is still a hard problem to researchers. This motivates the idea of social network [START_REF] Costa | Socially-Aware routing for publishsubscribe in delay-tolerant mobile ad hoc networks[END_REF] applications in DTN. DTN network is divided into multiple regions. The routing in a region and between regions is different.

For the congestion control, the most common method in message process is to delete new arrival message or previous old message stored in the node [START_REF] Seligman | Storage routing for DTN congestion control[END_REF]. In [START_REF] Floyd | Random Early Detection Gateways for Congestion Avoidance[END_REF], the authors add the probability management for the operation of message deleting that adopts the predefined constant threshold to control the new arrival message's deleting ratio. In [START_REF] Seligman | Alternative Custodians for Congestion Control in Delay Tolerant Networks[END_REF], the authors introduce the migration algorithm that means when congestion happens, and then the message is transferred to the nearby nodes. Migration will result in the increase of message transfer overhead, the decrease of message successful delivery ratio and increase of message delivery latency.

In the aspect of message sending speed adjustment,the authors define threshold to implement Additive Increase Multiplicative Decrease (AIMD) [START_REF] Chiu | Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Networks[END_REF] dynamically to adjust message sending rate [START_REF] Nishiyama | Wireless Loss-tolerant Congestion Control Protocol Based on Dynamic Aimd Theory[END_REF]. The constant threshold sometimes can't reflect the network status which might cause the inaccuracy of control. The authors in [START_REF] Godfrey | Incentive Compatibility and Dynamics of Congestion Control[END_REF] use ACK as the sign to adjust the message sending speed. When node derives the feedback of message loss, it directly rollbacks the sending speed to that the message was successful delivered recently.

The above two aspects both can't control congestion from the overall situation which needs to build the global feedback control system [START_REF] Firoiu | A Study of Active Queue Management for Congestion Control[END_REF]. Due to the latency as the specific attribute in DTN, control effect of ACK always has the lag phenomenon and congestion identification mistake. Meanwhile, it might cause the severe jitter of message sending speed which leads to the instability of DTN data transfer speed. If the Nyquist Criterion [START_REF] Paganini | Congestion Control for High Performance,Stability,and Fairness in General Networks[END_REF] is used in the feedback control system , the instability of message transfer speed in system is mostly resolved.

In conclusion, the above congestion control mechanisms assume all the nodes are regular. In the process of message delivery, the forge of node's attribute is not considered. Meanwhile, when congestion happens, passive method is adopted to control congestion. If there is active attack from malicious node in the network, limited storage resource would be consumed. This passive control method always can't reach the expected effect. This demands the algorithm which can actively control congestion and guarantee the message's successful delivery ratio has the capacity to do active defense. Moreover, some other issues can be considered, including the localization [START_REF] Andersson | Interworking Techniques and Architectures for Heterogeneous Wireless Networks[END_REF][START_REF] Turgay | A Comparative Review of Connectivity-Based Wireless Sensor Localization Techniques[END_REF], human mobilities [START_REF] Sun | Aggregate Human Mobility Modeling Using Principal Component Analysis[END_REF].

NESD congestion control routing algorithm

Problem Description

Node in DTN network is distributed discretely and adopts random routing. Random routing results in randomness of node's encounter to a large extent which makes the successful ratio of message delivery unpredictable. The previous solutions usually select transfer node based on historical encounter record to improve the message delivery successful ratio. But the network security is not considered which has no active defense capacity to the active attack. Once history record based on encounter probability is leveraged by malicious node, the consumption attack is implemented to the memory resource of network node which causes network congestion, and the network message successful delivery ratio is lessened as well.

Algorithm Idea

In most cases, the resource is limit which inevitably leads to competition of individuals for public resources in the same system. How to balance the interests of all parties and reach a win-win situation in some extent facilitates the emergence of game theory. This theory adopts formal language derivation to compute the optimal combination of the interests of all parties. Under this combination, each individual would not deviate from this balance for the interest temptation. Thus, it avoids the loss of one individual's interest or the non-optimal situation of overall individuals' interest caused by the individual's competition for public resources.

Memory resource is very rare in DTN node. If presence of malicious nodes is considered, active defense measures must be taken to constrain its active consumption attack for the resource of the node in DTN. Meanwhile, regular occupation demand for memory resource should be guaranteed for the message delivery of regular node. If malicious node attack and regular node demand can't be distinguished, we can adopt the game theory for trade-off. Memory resource of each node should be allocated appropriately. The memory occupation during the regular delivery of regular node message is guaranteed. Meanwhile, malicious occupation of malicious node is avoided.

Algorithm Implementation

The memory of each node in DTN is mostly occupied by two types of messages: existing messages in this node and messages which are about to be transferred to this node. Malicious node always unlimitedly demands other nodes to transfer its brought messages. The memory of attacked nodes is wholly occupied. The memory of attacked party is used out which results in congestion. The method to deal with congestion always deletes the oldest messages. It makes attacked node drop all existing messages in memory.

We adopt Nash equilibrium [START_REF] Martin | An Introduction to Game Theory[END_REF] in gaming theory to tradeoff the share of node memory between existing messages in this node and messages which are about to be transferred to this node. In conditions that malicious node and regular node are not differentiated, active defense is adopted to guarantee the message delivery of regular node. Meanwhile, the attack from malicious node is weakened in some extent and congestion is avoided.

The key of NESD is to leverage Nash equilibrium. The optimal combination of node memory occupancy for existing messages in this node and messages which are about to be transferred to this node is computed. The memory of node is fully shared by two kinds of messages, but not excessively occupied by one party.

The message transfer scenario under malicious node attack is applied to gaming theory. To make use of Nash equilibrium, we assume:

Attendee: existing messages in this node and messages which are about to be transferred to this node.

Action: node memory occupancy of existing messages in this node and messages which are about to be transferred to this node.

Preference:existing messages in this node and messages which are about to be transferred to this node all hope to obtain more opportunities to be transferred unitl reaching the destination node. Theorem 1 When L 1 and L 2 both reach maximum, based on the characteristic of Nash equilibrium, p 1 and p 2 can reach the same reasonable value.

Proof. L x = S x + p x -D x ( 1
)
S x = T x × R (2) T x = { px b , p x ≤ b 1 , p x > b (3)
R = { b -p 1 -p 2 , p 1 + p 2 ≤ b 0 , p 1 + p 2 > b ( 4
)
Figure 2 is derived from formal ( 4)

Fig. 2. R D x = cp x (0 ≤ c ≤ 1) (5)
The setting of D x represents the idea that more occupancy means more responsibility. More memory consumption by certain kind of message results in larger packet drop-off probability for the messages when congestion happens.

According to formal (1) to ( 5):

L 1 = { p1 b × (b -p 1 -p 2 ) + p 1 -cp 1 , p 1 + p 2 ≤ b p 1 -cp 1 , p 1 + p 2 > b (6) L 2 = { p2 b × (b -p 1 -p 2 ) + p 2 -cp 2 , p 1 + p 2 ≤ b p 2 -cp 2 , p 1 + p 2 > b ( 7
)
Figure 3 is derived from formal (6) When p 1 + p 2 ≤ b and p 2 = 0, L 1 achieves maximum under formula ( 8)

Fig. 3. Preference of L1 p 1 = b - bc 2 ( 8
)
When p 1 + p 2 ≤ b and p 2 > 0,L 1 achieves maximum under formula ( 9)

p 1 = b - p 2 2 - bc 2 (9)
When p 1 + p 2 ≤ b and p 1 = 0,L 2 achieves maximum under formula ( 10)

p 2 = b - bc 2 (10)
When p 1 + p 2 ≤ b and p 1 > 0,L 2 achieves maximum under formula ( 11)

p 2 = b - p 1 2 - bc 2 (11)
According to [START_REF] Jain | Congestion Avoidance in Computer Networks with a Connectionless Network Layer:Concepts,Goals,and Methodology[END_REF], we argue that when y-axis L 1 adopts the maximum value, x-axis depends on p 2

f 1 (p 2 ) = { b -p2 2 -bc 2 , p 2 ≤ b 0 , p 2 > b ( 12
)
According to [START_REF] Hollot | A Control Theoretic Analysis of RED[END_REF], we argue that when y-axis L 2 adopts the maximum value, x-axis depends on p 1

f 2 (p 1 ) = { b -p1 2 -bc 2 , p 1 ≤ b 0 , p 1 > b ( 13
)
Based on Nash equilibrium, Figure 4 is derived from formal [START_REF] Feng | Thwarting Blackhole Attacks in Distruption-Tolerant Networks using Encounter Tickets[END_REF] and formal [START_REF] Vivek | Resource-Misuse Attack Detection in Delay-Tolerant Networks[END_REF].When L 1 and L 2 adopt maximum at the same time, we have.

p * 1 = p * 2 = 2 3 b - bc 3 ( 14
)
According to the Theorem 1 and verification, We configure the concrete threshold for the node memory occupancy by two kinds of messages as p * 1 = p * 2 . This mechanism realizes the full share of node memory resource between existing messages in this node and messages which are about to be transferred to this node. It also makes the resource not overused by one party. This effectively defenses the attack of memory occupancy from malicious node. The active control to congestion caused by malicious node memory occupancy increases the system global message successful delivery ratio.

Evaluation

We leverage DTN-dedicated simulator THE ONE to do the simulation. NESD congestion control routing algorithm and encounter history based regular routing algorithm is compared in this paper. Meanwhile, network congestion ratio, message successful delivery ratio and message successful delivery cost are analyzed under the situation that memory is attacked through active consumption by a small quantity of malicious nodes.

The parameters in routing algorithm are set as table 2.

In order to prove the advantages of this algorithm in a limited testing time, we set more nodes, smaller nodes memory, faster node speed, more frequent message generation rate and larger message transfer speed. Thus, congestion control performance can be exhibited in short experiment time. And whether message is successfully delivered also can be exhibit promptly. It's beneficial to our evaluation to the algorithm performance. By the comparison of congestion ratio shown in Figure 5, we found that NESD congestion control routing algorithm significantly improves DTN network congestion compared to regular routing algorithm based on historical encounter information. It sets the concrete threshold for node memory occupancy to limit the node memory consumption from malicious node. The exhaustion of the whole encounter node memory in the attack of malicious node compels the attacked node to accept all the messages for transfer from malicious node. Since we set the same memory size for each node, this inevitably causes attacked node lose its' message for accepting all the messages from malicious node which results in congestion. The algorithm we design avoids the emergence of this problem and reduces the network congestion ratio. successful delivery ratio. Node's message delivery in DTN mainly depends on the assistance of message transfer operation. More than one hop is needed to complete the successful delivery. But in the network with memory consumption attack from malicious node, messages are always forcefully deleted before the arrival at the destination node due to the memory exhaustion by malicious node's attack. This inevitably lessens the message successful delivery ratio. The algorithm we design limits the attack from malicious node and guarantees the necessary transfer operation of regular node for successful message delivery and the success ratio is also insured. By the comparison of the cost for message successful delivery in Figure 7, NESD congestion control routing algorithm significantly lessens cost of message successful delivery. In this experiment, we define the cost of message successful delivery as the delivery number to destination node divided by the number to un-destination node. Obviously, congestion and packet loss caused by malicious node attack increases the overall delivery number to un-destination node and lessens overall delivery number to destination node which increases the cost of message successful delivery. The constraint operation to the malicious node attack inevitably reduces the cost of message successful delivery.

Conclusion

Based on the conclusion of the main research work for DTN congestion control routing, this paper proposes NESD congestion control routing algorithm under the premise that there is memory consumption attack from malicious node. These also have significant application values in the field of homeland defense.This algorithm leverages Nash equilibrium in game theory by setting concrete threshold to tradeoff the node memory occupancy between existing messages in this node and messages which are about to be transferred to this node. The transfer operation for successful message delivery of regular node is guaranteed. Meanwhile, illegal occupancy of node memory from malicious node is constrained effectively. This algorithm improves the congestion degree and enhances message successful delivery ratio. This paper in detail proves existing messages in this node and messages which are about to be transferred to this node both can be transferred continually with high probability until coming into contact with the destination node. At the same time, the concrete threshold for the share of node memory by two-class messages is computed for achieving this target. And the high performance of this algorithm is proved by experiment.

We will continue the research on active defense mechanism to all kinds of attacks from malicious node. Message successful delivery ratio should be guaranteed. The mechanism also should perfect congestion control, optimize the defense result and effectively decrease the delivery latency of messages. In next step, we will discuss the effect of other attack behavior to DTN from malicious node and propose the corresponding defense measurement. The message successful delivery ratio should be guaranteed and congestion should be controlled effectively. Scholars and Innovative Research Team in University of the Ministry of Education("Network Technology",NUDT), the Innovative Research Team in University of Hunan Province("Network Technology",NUDT), and the Innovative Research Team of Hunan Provincial natural science Foundation(11JJ7003).

Fig. 1 .Figure 1

 11 Fig. 1. Tx

Fig. 4 .

 4 Fig. 4. Nash Equilibrium

Fig. 5 .Fig. 6 .

 56 Fig. 5. Congestion ratio

Fig. 7 .

 7 Fig. 7. Cast of successful delivery

Table 1 .

 1 Symbols Used in Theorems

	Symbol Description
	Lx	Preference of X type message
	px	Memory size occupied by type X message
	1	messages which are about to be transferred to this node
	2	existing messages in this node
	b	Size of node memory
	c	Node congestion degree
	Sx	Spare memory size allocated in proportion to type X message
	Tx	Node memory ratio already occupied by type X message
	R	Spare memory size of node
	Dx	Drop-off message amount of type X caused by congestion

Table 2 .

 2 Simulation parameters

	Parameter	Value
	Scenario length and width	10000m
	Hotspot area length and width 4000m
	Node number	20
	Node memory	3 MB
	Node speed	10 m/s
	Communication radius	50m
	Message generation rate	20 seconds per message
	Message size	500KB
	Message transfer speed	5000KB/s

Acknowledgement

The work described in this paper is partially supported by the grants of the National Basic Research Program of China (973 project) under Grant No.2009CB320503, 2012CB315906; the National 863 Development Plan of China under Grant No. 2009AA01A334, 2009AA01A346, 2009AA01Z423; and the project of National Science Foundation of China under grant No. 61070199, 61003301, 60903223, 60903224, 61103189, 61103194, 61103182; and supported by Program for Changjiang