Saïd Gharout
email: said.gharout@orange.com

Abdelmadjid Bouabdallah
email: bouabdal@hds.utc.fr

Yacine Challal
email: ychallal@hds.utc.fr

Mohammed Achemlal
email: mohammed.achemlal@orange.com

Adaptive Group Key Management Protocol for Wireless Communications

Keywords: confidentiality, key management, group communication, mobility Category: C.2.0

Group-oriented services and wireless communication networks are among the emerging technologies of the last few years. Group key management, which is an important building bloc in securing group communication, has received a particular attention in both academic and industry research communities. This is due to the economical relevance of group-based applications, such as video on demand, videoconferencing, collaborative work. The key management concerns the distribution and updates of the key material each time a member joins or leaves the group. The dynamic aspect of group applications due to free membership joins and leaves in addition to members' mobility makes difficult the design of efficient and scalable key management protocols. Indeed, to secure group communication in mobile environment, the protocol must deal not only with dynamic group membership but also with dynamic member location. Thus, the challenges in designing secure and scalable key management protocols are: the dynamic updates of the key caused by frequent joins and leaves, the large size of the group and the mobility of group members. Many academic researches have addressed the first and the third challenges. However the mobility challenge has not been widely addressed. In this paper, we present our solution for group key management with a mobility support. Our protocol focuses on the above three challenges. It is highly scalable to dynamic groups and treats the nodes' mobility with a null re-keying cost and keeps perfect backward and forward secrecies. Our simulation studies show that our protocol makes better performance compared to other protocols while reducing the overall overhead and the number of re-keying messages and has no security failures.

Introduction and challenges

The phenomenal growth of the Internet in the last few years and the increase of bandwidth in today networks have provided both inspiration and motivation for the development of new group-oriented applications and services, combining voice, video and text "over IP". Nowadays, group-oriented applications are increasingly deployed over the Internet such as video conferencing, interactive group games, video on demand (VoD), IP-TV, e-learning, software updates, database replication and broadcasting stock quotes. Unfortunately, the strengths of group-oriented applications, implemented either by IP Multicast [Savola 2008], overlay Multicast [START_REF] Yeo | [END_REF] or other means is their lack of security. Indeed, the open and anonymous membership [START_REF] Haberman | [END_REF]] and the distributed nature of multicasting are serious threats to the security of this communication model. For this purpose, much efforts have been conducted to address the many issues relating to securing group communication, such as: access control, confidentiality, authentication and watermarking.

Group communication confidentiality requires that only group members could read data even if the data is broadcasted into the entire network [START_REF] Judge | [END_REF]Ammar 2003, Baugher et al. 2005]. Typically, the distribution of data with commercial value (video streaming, ...)or State top-secret content requires the use of appropriate mechanisms to prevent non-legitimate recipients from having access to the content. To ensure confidentiality in group communication, only the customers authorized for the service would have access to the content for only the duration corresponding to their authorization. A straightforward solution is to encrypt the group-intended data by the sender with a group key, called Traffic Encryption Key (TEK), common to all authorized recipients. However, when the authorized duration for a recipient expires (in video streaming or audio conferencing for example), it is necessary to change the common group (traffic encryption) key into a new key in order to prevent the leaving customer from having access to the content beyond the limit of his authorized duration. Therefore, the sender has to share the new TEK with all legitimate recipients except the leaving one. This phase is called re-keying, and should be performed each time a customer joins the secure session to prevent him from having access to old content (what is called Backward Secrecy) or leaves the session to prevent him from having access to future content (what is called Forward Secrecy). The role of a group key management protocol is to generate, update and distribute TEKs to legitimate group members. To ensure perfect backward and forward secrecy, a re-keying must be done each time there is membership changes (join or leave) in the group. The impact of this re-keying process on group members, commonly called 1-affects-n phenomenon, measures the number of affected members by a re-keying process. This 1-affects-n phenomenon is a challenging issue in designing group key management protocols. If the group size keeps increasing, such a phenomenon will significantly degrade the system performance. In the last few years, a lot of group key management protocols have been conducted in the literature to address the confidentiality issue in group communication [START_REF] Rafaeli | [END_REF]. Even though a multitude of data confidentiality mechanisms currently exist for the fixed Internet, this security service remains a challenging problem in terms of scalability, efficiency, and performance. A critical problem with any re-key technique is scalability: as the re-key process should be triggered after each membership change, the number of TEK update messages may be important in case of frequent join and leave operations. Some solutions propose to organize the secure group into subgroups with different local TEKs. This reduces the impact of the key updating process, but needs decryption and re-encryption operations at the borders of subgroups. These operations may decrease the communication quality and causes computational overheads.

While the problem of developing efficient group key management protocols is difficult, the problem becomes more difficult and complex when we consider member mobility [Romdhani et al. 2004]. Indeed, in the mobile environment [Perkins 2002, Johnson et al. 2004, Koodli 2009] where members can move inside the group the key management protocol must deal not only with dynamic group membership (join and leave) but also with dynamic member location [Romdhani et al. 2004]. In mobile environments [Perkins 2002, Johnson et al. 2004, Koodli 2009],when a member moves from an access area to another, it changes its access point to the traffic. So, the complexity of key management increases since the member is not known in the new area even though a fast handover mechanism exists. This can re-route the traffic to the new access point but the security issue must also be considered. This can induce the generation of new TEKs in both old and new areas. In this case the member is considered as a leaving member in old area and as joining member in the new area even it is a valid member in the system.

In this paper, we propose a decentralized architecture for group key management in mobile environments where the group is organized into clusters of areas, and areas of the same clusters use a common TEK. We call it KMGM for Key Management to secure Group Communications in Mobile Environments.

The rest of this paper is organized as follows: In section 2, we overview group key management protocols in the literature. In section 3 and section 4, we present our protocol for group key management in mobile environments and our re-keying strategy, respectively. Section 5 details how members are verified in the system when they move. We present our simulation model and results in section 6. Finally, we conclude the paper in section 7.

Group key management has been extensively studied in the literature [START_REF] Rafaeli | [END_REF], Zhu and Jajodia 2004, Challal et Seba 2005]. Many classifications of group key management protocols have been proposed in the literature: centralized, decentralized, and distributed protocols. In centralized protocols, the key distribution function is assured by a single entity which is responsible for generating and distributing the traffic encryption key (TEK) whenever required. In decentralized protocols, a hierarchy of key managers share the labor of distributing the TEK to group members in order to avoid bottlenecks and single point of failure. In distributed key-agreement protocols, the group members cooperate to establish a group key. Another classification is done according to the manner that the TEK is shared between group members. Thus, we distinguish common TEK approaches and per subgroup TEK approaches. In the common TEK approach, a single TEK is used for the whole group, whereas in the per subgroup TEK approach, the group is organized into subgroups (areas) and a different TEK is used for each subgroup. Most of the centralized protocols proposed in the literature use a common Traffic Encryption Key (TEK) for group members [Challal et Seba 2005]. A typical solution that fits into this category is the Group Key Management Protocol (GKMP) [START_REF] Harney | [END_REF]. The drawback of this scheme is its high number of update messages (in the order of O(n) with n being the number of valid group members) to transmit the new TEK after membership changes. In the Logical Key Hierarchy (LKH) protocol proposed at same time by [START_REF] Wong | [END_REF]] and Wallner et al. in [Wallner et al. 1999], a hierarchy of keys is used to reduce the required number of TEK update messages induced by re-keying after membership changes to the order of log (n). The drawback of these centralized protocols is the fact that they require that all group members commit to a new common TEK, whenever a membership change occurs in the group, in order to ensure perfect backward and forward secrecy. This makes these solutions suffering from the 1-affects-n phenomenon. In order to mitigate the 1-affects-n phenomenon, another decentralized approach have been proposed and which consists in organizing group members into subgroups, where each subgroup uses its own independent TEK. Indeed, in this scheme, when a membership change occurs in a subgroup, it affects only the members of this subgroup. Mittra proposed in [Mittra 1997] the Iolus architecture which is a framework of a hierarchy of multicast subgroups. Each subgroup is managed by a Group Security Agent (GSA) which is responsible for key management inside the subgroup. A main controller called the Group Security Controller (GSC) manages the GSAs. When a membership change occurs in a subgroup, only that subgroup is involved in a re-key process. This way, Iolus scales to large groups and mitigates 1-affects-n phenomenon. However, Iolus has the drawback of affecting the data path since data is translated (decrypted and re-encrypted) each time it passes from a subgroup to another. Even though it is difficult to design efficient and scalable group key management protocols, the problem becomes more difficult while we consider node mobility. Indeed, in a wireless environment a node participating in a group session can move from a subnet or area to another. In traditional solutions, this mobility can induce a re-keying process two times since this can be considered as a leave in old area and a join in new area.

In the literature, few group key management protocols have been designed for mobile environments [Cao et al. 2006, Roh andLee 2006]. In [Roh and Lee 2006], Roh et al. propose two key management schemes (KTMM and WSMM) suited to the Mobile IP environment. The first scheme matches the key management tree to the mobile multicast network topology. The second scheme separately manages each the wired and wireless area. These solutions suffer from a single point of failure which is the group manager. In [START_REF] Pietro | [END_REF], Di Pietro et al. propose an improved version of LKH [START_REF] Wong | [END_REF], Wallner et al. 1999] called LKH++ for mobile wireless networks but it does not treats the mobility issue of members. In M-Iolus [START_REF] Kamat | [END_REF]] which is a version of Iolus that supports members mobility, subgroups are divided into micro-subgroups to reduce the 1-affects-n phenomenon. This has a price since it increases the number of encryption areas. When a member moves from a micro-subgroup to another micro-subgroup the TEK is not updated. M-Iolus proposes a null rekeying cost on member mobility, at the expense of raising a backward secrecy violation.

In [START_REF] Hernandez-Serrano | [END_REF], authors propose a group key management protocol for wireless networks with a slightly mobile set using clustered areas. They propose to use LKH for intra-area rekeying but the use an inter-area rekeying when the mobile node moves from area to another the same in [Zhang et al. 2002]. In [Zhang et al. 2002], where the group is divided into areas [Hardjono et al. 2000] using a common TEK authors propose several techniques for inter-area rekeying when members move: Static Rekeying (SR), Baseline Rekeying (BR), Immediate Rekeying (IR) and FEDRP (First Entry Delayed Rekeying) when mobile node moves from an area to another.

In [Mat Kiah andMartin 2007, Mat Kiah and[START_REF] Haberman | [END_REF], Kiah and Martin propose a key management protocol where they address the mobility issue of members. They consider a DKM (Domain key Manager ) as the main key manager of domain i and AKM (Area Key Manager ) as the key manager of the area j inside a domain. A list called M obList is used by the DKM and AKMs to keep trace of mobile members. Thus, each time a member moves from one area to another, the protocol stores in M obList IDs of the moving member, multicast group joined by the member, area that a member is moving from, ID of the visited area that a member is moving to. When a member M i moves from area i to area j it notifies the new and previous AKMs. The two messages are encrypted with two different keys ( A i M i Key shared between AKM i and M i and Sm Key ji between AKM j and M i ). The drawback of this protocol is the number of used keys and signaling messages. The protocol did not explain how leave re-keying is done since there is no re-keying while moving. In [Gharout et al. 2010], we proposed a host mobility management for group key management protocols.

Discussion and motivation

We notice that both existing approaches suffer from great concerns depending on group dynamism: the common TEK approach suffers from the 1-affects-n phenomenon, where a single group membership change (join or leave) results in a re-keying process that disturbs all group members to update the TEK. Moreover, centralized protocols are not scalable, and distributed ones bring new challenges such as synchronization and conflict resolution. On the other hand, the TEK per subgroup approach reduces the 1-affects-n problem. This is advantageous for highly dynamic groups. However, this approach requires translation of sent messages whenever they pass from a sub-group to another, and this may not be tolerated by applications that are sensitive to packet delivery delay variations. Besides, this approach would not be worthy with relatively static groups because the multiple translations would induce avoidable delays and useless computation overheads. These shortcomings are due to the lack of dynamism awareness in existing group key management schemes.

KMGM protocol: Mobility support to ASGK

Overview

In KMGM, we organize the group into a hierarchy of administrative areas where each area is managed by an Area Key Distributor (AKD). This hierarchy of areas is partitioned into clusters of areas (see figure 1). If there is only one cluster, our architecture is then similar to a common TEK approach, and if the number of clusters is equal to the number of areas our architecture becomes a TEK per subgroup approach.

In our architecture, an area represents an autonomous system which can be a corporate network, a multicast domain (e.g. PIM domain), or a wireless area. Figure 1 illustrates the different components of the KMGM architecture.

Each AKD is responsible for the key management process inside the area under its control and is considered as a member in its area and in its parent area. Thus, an AKD plays the role of a proxy for its area in the parent area. When an AKD receives a message from the parent area, it sends it to members of the area under its control. Areas of the same cluster use the same TEK which is different from TEKs of other clusters. The task of internal AKDs in a cluster is to forward received messages sent by the parent area. When messages pass from a cluster to another cluster, they must be translated (decrypted and re-encrypted) since different TEKs are used in each cluster. Therefore, upon receiving messages from the parent area (encrypted using the parent's TEK), the root AKD of the cluster , which is the entry point of the cluster, will decrypt them and re-encrypt them using the TEK used within its area before forwarding them downward to its area members. The root cluster AKD is said to be in active state because it decrypts messages received from parent area which belongs to a different cluster and re-encrypt them with its TEK before sending them to its area members. The internal AKDs of a cluster are considered passive since they forward received messages to their area members without any cryptographic transformation. The construction of clusters can be done using different heuristics presented in our previous works [Challal et al. 2008, Gharout et al. 2008, Challal et al. 2004].

When there is a membership change (join or leave) in any area, a new TEK is distributed to the overall areas of the same cluster because of using a common TEK.

In our solution, the mobility issue of members is treated without re-keying process since the moving member is still valid in the session. For this purpose, we propose a verification mechanism that we present in detail in subsequent sections. In conclusion, our solution deals with two main functionalities:

-Partitioning the group into clusters of areas while reducing the impact of 1-affects-n phenomenon. Areas in the same cluster uses a common TEK.

-Mobility management in term of re-keying. We handle the mobility of members between areas.

In [Challal et al. 2008, Gharout et al. 2008, Challal et al. 2004] we show how the partitioning of the group into clusters of areas is done while considering different heuristics relating to dynamism inside the group. In [Gharout et al. 2010], we presented a mobility support for group key management protocols. The solution we present in this paper is partially based on the protocol we proposed in [Gharout et al. 2010].

Definitions and assumptions

Let us denote a group member by m l , an area by a i and a cluster by C k . In table 1 we summarize the nomenclature used through the paper.

Each member m l has a personal secrete key called Member Encryption Key (M EK l ). The M EK is used to communicate secretly with any AKD in the group. We assume that each member has a certified pair of public and private keys. All the AKDs share a symmetric key called Session Encryption Key (SEK) which is used to generate and verify Members' Keys (M EKs) (see section 5). This key must be known only by AKDS. Let us recall that all the areas of the same cluster C k share the same TEK. This is the first key that each AKD i should maintain and share with all the members of its area a i . Each AKD i shares a secrete Key Encryption Key (KEK i ), used to encrypt new TEKs, with all its area members. We introduced KEK as a common key at the area level in order to optimize the number of re-keying messages whenever distributing a new TEK is required and the old one can not be used to encrypt the new one. In this case, the KEK will be used to encrypt and send the new TEK through a single multicast message to the corresponding area, instead of sending the new TEK encrypted with the individual keys of area members.

We assume that each AKD i maintains two lists : a list of members (denoted by ListM i ) which contains identities of current area members; and a list of old members (denoted ListO i ) which contains identities of members which were members of area a i and moved to other areas without leaving the secured group session.

We discuss in the following section how to use these keys for re-keying in cases of join, leave and member mobility inside the group.

Key distribution protocol

In our protocol, a common TEK is used by areas inside the same cluster. In order to guarantee perfect backward and forward secrecy, each time a membership change (join or leave) occurs in an area, our protocol KMGM generates a new TEK and distributes it in all the areas of the concerned cluster.

We distinguish four cases of re-keying:

join re-keying: when a new member joins the group for the first time, a new TEK is generated and distributed to this new member and the current group members. This scenario is illustrated by action (1) of figure 1.

leave re-keying: when a member leaves the group, a new TEK is generated and distributed only to the remaining members. This scenario is illustrated by action (4) of figure 1.

move re-keying: when a member moves from an area to another, there is no TEK generation but the member is verified in new area. This scenario is illustrated by actions (2) and (3) of figure 1.

split re-keying: when an AKD becomes active, a new TEKs are generated for the two resulting clusters.

merge re-keying: when an AKD becomes passive, a new TEK is generated for the resulting cluster.

periodic re-keying: this one can be triggered by the protocol itself to refresh the TEK and empty all lists. A new TEK is generated.

In what follows, we detail the re-keying protocol for each case.

Join re-reying

In KMGM, when a member m l located in area a i wants to join the group, it sends a Registration Request (RR) message with join option signed with its private key k sl to AKD i (action (1) in figure 1). Upon receiving the RR request, AKD i verifies if m l is authorized to join the group session. If so, AKD i generates a symmetric key M EK l (section 5) and sends it to m l encrypted with the public key of m l (k p l ). AKD i adds m l to its list of area members ListM i .

To guarantee backward secrecy, all the AKDs of the cluster where the new member has joined should commit to a new TEK and distribute it to the members in their areas. The commitment of new TEK is discussed in section 4.5. AKD i generates a new KEK i . To distribute the new TEK and KEK to the members in area a i , where the new member joins the session, AKD i sends a message containing the new TEK and the new KEK i encrypted with M EK l ({new T EK, new KEK i } M EK l ) to the new member m l and multicasts the new TEK to the other members in its area, encrypted with the old TEK ({new T EK, new KEK i } oldT EK ). To distribute the new TEK in the other areas a t of the cluster, each AKD t multicasts to its area a t the new TEK encrypted with the old one ({new T EK} oldT EK ).

Thereby, each join to the session induces a multicast message in each area of the cluster where the join occurred, in addition to a single unicast message to the new member.

An intruder cannot have access to the new TEK, and hence to the content, because it cannot know neither the old TEK (which is not compromised in case of a join), nor the secret key M EK l of the new member.

Mobility re-keying

A member can move from an area a i to another visiting area a j . We distinguish two kinds of member mobility :

1. Intra-cluster mobility: the node moves from area a i to area a j which is located in the same cluster (action (2) in figure 1).

2. Inter-cluster mobility: the node moves from area a i to area a j which is located in a different cluster (action (3) in figure 1).

When area a i and area a j belongs to the same cluster (action (2) in figure 1), area a i and area a j use the same T EK. In our solution, AKD j has just to verify if the member m l is a valid and really comes from area a i . When area a i and area a j are located in different clusters, area a i and area a j use different TEKs (action (3) in figure 1). In this case, besides verification AKD j sends to m l the TEK used in its area.

When m l moves from area a i to area a j the following operations are then executed:

-The member m l sends to AKD j a Registration Request (RR) with move option signed with M EK l ;

-AKD j verifies that m l is a valid member and really comes from area a i (see how in section 5);

if the verification succeeds, AKD j adds the visitor member m l to its list of members ListM j ;

-AKD i removes m l form its list of members ListM i and adds it to its list of old members ListO i .

We notice that when there is a move in the same cluster the TEK is not renewed since the same T EK is used in old and new areas, and the member is still valid. Even though the member changed a cluster, no new T EK was renewed because the member is still valid in the group session. Old AKD (AKD i ) has just to keep trace that m l was a member in its area a i so that AKD i updates the TEK whenever m l leaves the group definitively.

The keys that m l receives in the new area a j are:

1. Intra-cluster mobility (T EK i = T EK j ): AKD j sends KEK j to m l encrypted with M EK l .

2. Inter-cluster mobility (T EK i ̸ = T EK j ): AKD j sends KEK j and T EK j to m l encrypted with M EK l .

We conclude that in our solution the TEK is not renewed when a member moves form an area to another even though the two areas are located in different clusters.

Leave re-keying

A valid member m l located in area a i can be expelled from the group by AKD i or can intentionally leave the group by sending a leave message to the AKD i . In this case, all the AKDs of the same cluster where the leave occurs should commit to a new TEK and distribute it to the members in their areas, in order to guarantee forward secrecy.

The departing member might visit other areas inside the same cluster or other clusters. So, m l knows all KEKs and T EKs used in previously visited areas. Thereby, the TEK must be updated in each cluster C k where m l was member since it can know T EKs and KEKs used in previously visited areas of these clusters.

Lemma 1. Let T EK k be the TEK used in cluster C k and m l an expelled member from area a i . We have

∀C k , ∃a j ⊂ C k /m l ∈ ListO j ⇒ T EK k is compromised (1)

Proof

When m l moves from an old area to a new area, it receives the key material (TEK, KEK) used in the new area but the TEK used in old area is not changed (section 4.2). Thus, m l knows all T EKs and KEKs of areas it has already visited. Suppose E = {a 1 , a 2 , . . . , a j } the set of areas that m l has already visited. Now, when m l is expelled from a i it can be able to decrypt message destined to E since it knows KEKs and T EKs of areas in E.

When m l is expelled from a i , other AKDs are informed that m l has been expelled from the group (section 4.5) and thereby new T EKs are generated in clusters where equation 1 is verified. To distribute the new TEK in area a i , AKD i sends to each member m n (n ̸ = l) in its area the new TEK and the new KEK i encrypted with the secret key M EK n of member m n (AKD i → m n (n ̸ = l) : {new T EK, new KEK i } M EKn ). To distribute the new TEK in the other areas a t (not visited by the expelled member)of the cluster where the leave occurs, each AKD t multicasts to its area a t a message containing the new TEK encrypted with KEK t ({new T EK} KEKt ). AKD i removes m l from ListM i and empties ListO i .

Therefore, each remaining valid member m n in a i would be able to decrypt the new TEK and the new KEK using its secret key M EK n , and the expelled member m l will be prevented from having access to these new TEK and KEK, because its associated key M EK l would have not been used to encrypt them.

For each cluster C k where equation 1 is verified, to distribute the new TEK' in each area a p ⊂ C k where m l ∈ ListO p , AKD p sends to each member m n (n ̸ = l) in its area the new TEK' and the new KEK p encrypted with the secret key

M EK p of member m n (AKD p → m n (n ̸ = l) : {new T EK ′ , new KEK p } M EKn ).
To distribute the new TEK in the other areas a q in the cluster C k , each AKD q multicasts to its area a q a message containing the new TEK encrypted with KEK q ({new T EK ′ } KEKq ). Each AKD p empties ListO p .

We notice, that when there is a leave re-keying, lists of old members (ListO) of area a i and each area a p (a p /m j ∈ ListO p ) are emptied. Indeed, there is no need to treat further departures of these old members since their Member Encryption Keys (M EKs) are not used in the re-key message. Thereby, they will not be able to know new KEK and TEK of area a i and each area a p .

An intruder cannot have access to the new TEK, and hence to the content, because it cannot know any secret key M EK n of a remaining legitimate member, and cannot know any KEK of the other areas it had not visited. Note that, in case of an expulsion, we cannot use the old TEK to encrypt the new one because it is considered compromised since it is known by the expelled member. Since m l do not know KEKs of other areas it had not visited, we use in these areas KEKs to send the new TEK. This optimizes number of re-keying messages.

Periodic re-keying

In our solution, a batch re-keying can be envisaged to refresh T EKs. This can be done periodically or triggered by an AKD. An AKD i can trigger a Re-Keying if the size of its list of old members (ListO i ) is full enough. The cluster root can also have the role to schedule batch re-keying.

When a batch re-keying is done in a cluster C k , the new TEK is sent as in leave case since the members inside the list of old members (ListO) know the current TEK and KEK of concerned areas even though they are not members of these areas. We distinguish two kinds of areas: areas where list of old members (ListO) is empty and areas where this list (ListO) is not empty. To distribute the new TEK in each area a i where ListO i is not empty, AKD i sends to each area member m n (m n / ∈ ListO i ) in its area the new TEK and the new KEK i encrypted with the secret key M EK n of member m n . Each AKD i empties ListO i . To distribute the new TEK in the other areas a t of the cluster C k where ListO t is empty, each AKD t multicasts to its area a t a message containing the new TEK encrypted with KEK t ({new T EK} KEKt ).

The advantage of batch re-keying is that it allows to increase the robustness of T EKs by refreshing them and to empty lists of old members in the cluster. This decreases the number of key updates (see section 4.3) in further group membership changes.

TEK generation

When an AKD i needs to renew the TEK inside its area due to membership change or a triggered re-keying, it sends a re-key request to the cluster root asking it to generate a new TEK for the whole cluster. If the membership change type is a leave, AKD i must include the identity of the expelled member m l in the request. The cluster root generates a new TEK and sends it to its area members. If the type of the membership change is a leave the cluster root must include the identity of the expelled member in the re-key message. The cluster root AKD informs other AKDs of the system that m l has been expelled ({Expelled(m l ), . . .} SEK ). Upon receiving, the message Expelled(m l ) each AKD j checks if m l ∈ ListO j . If it is the case, it sends a key request to its cluster root AKD with leave option but it informs it that m l is an external member (message 2 below). This last indication is important to avoid that the cluster root AKD informs other AKDs about this leave. A cluster root AKD informs other AKDs about a member expulsion or leave only if this expulsion occurs in its cluster.

The following is the format of the re-key request message sent by an AKD i , which can be signed with its private key to prove authentication, to the cluster root AKD r :

AKD i → AKD r : {option, status, member id, ...} (2)
In formula 2, the field option can be join, leave or triggered. The field status can have two status: intern which means that the membership change occurs in current area; or extern which means that the membership change occurs in different area but compromises key materials in current area when the expelled member is present in the list of old members of area a i (ListO i ).

If the cluster root AKD receives other re-key requests with leave option and extern status caused by a member m l , it verifies if it has already treated a similar request caused by this member. If it is the case it ignores the request. The cluster root AKD sends the new TEK encrypted with the old one. But when a member leaves this key can not be used to encrypt the new one. In this case, AKD r can use either the MEK of each AKD since each AKD is considered as a member or the SEK of the current session.

Split re-keying

When AKD i takes the decision to become active (a split operation), it creates a new cluster. Therefore, AKD i generates a new TEK and distributes it downward encrypted with KEK i ({newT EK} KEKi ). When the child agents in the so formed cluster receive this message they forward it downward, encrypted with their respective KEK, until it hits active agents. Since the old TEK becomes obsolete, the root of the old cluster will also re-distribute a new TEK to ensure forward and backward secrecy in the same way. Afterward, AKD i assures the translation of received upward messages into the TEK used in its new cluster.

Merge re-keying

When AKD i takes the decision to become passive (a merge operation), it will use the same TEK of its parent AKD j . Since it is a member in its parent area, it knows the TEK used in its parent cluster, and thereby distributes it downward encrypted with the old TEK previously used in its cluster ({parentT EK} oldT EK ). When the downward child agents receive this message they forward it downward until it hits active agents. Afterward, the role of AKD i will be limited to forward received upward messages.

Mobility management

Recall that all AKDs share symmetric key SEK which is known only by AKDs. We assume that this key is generated by the AKD where the traffic source is connected at session setup, and distributed securely to other AKDs. Thus, we will have different SEKs for each group session.

When a new member m l located in area a i joins the group it sends a Registration Request (RR) message to AKD i encrypted with its private key. Thus, AKD i generates a member encryption key M EK l using formula 3 and sends it to m l encrypted with the public key of m l (k p l ). To generate the M EK of member m l AKD i uses a Key Derivation Function (KDF) as follows:

M EK l = KDF (SEK, data l ) (3)
where,

-SEK = The Session Key shared which is only known by AKDs.

data l = label l + optional data ("+" denotes concatenation).

label l = Contains member m l identity, the public key of m l and eventually other information concerning this member.

optional data = This field can be empty or contains some information about the concerned member or the group session.

Note that the MEK is valid only in current session since SEK depends on session information. A member will have different MEKs if it participates to many secured group sessions. Thereby, if a member is expelled from a session it can receive messages in other sessions.

As in [START_REF] Kelly | [END_REF], the KDF used is a PRF (Pseudo Random Function) which is a combination of one way hash functions (MD5, HMAC, SHA1, SHA256,..). Several PRFs can be used in the Key Derivation Function. However, in order to have a coordinated key derivation function the same PRF function must be used by all the AKDs. Some popular PRFs based on HMAC-SHA1, HMAC-MD5 , HMAC-SHA256 used in [START_REF] Kelly | [END_REF] are recommended.

The SEK key which is known only by AKDs plays a key role in M EKs generation. Thus, each AKD is able to verify the M EK presented by a user as follows: When m l moves from area a i to area a j it sends a Registration Request with move option to AKD j and presents its credentials such as a certified public key. According to formula 3, AKD j calculates M EK ′ l with m l credentials. If (M EK ′ l = M EK l ) then m l is accepted in area a j and receives the T EK in area a j .

Simulation and results

In this section, we present our simulation model and some results of the carried out simulations in which we compared KMGM with other protocols from literature: Iolus [Mittra 1997] which is a decentralized approach with independent TEK per subgroup,the Group Key Management Protocol (GKMP) [START_REF] Harney | [END_REF] which is a centralized solution with common TEK for the whole group and M-IOLUS which is a new version of Iolus for mobile environments. We also used in simulation our protocol ASGK which is a native version of KMGM but it does not support mobility. In our simulation a re-keying is done each time there a membership change (join or leave) in the group. In the protocols which not support mobility (GKMP, Iolus and ASGK) we consider a member move as a leave in the old area and a join in the new area. We study the 1 affects n behavior of each simulated protocol, the number of decryption / re-encryption operations required for the communication and the number of re-keying messages. For the number of re-keying messages we don't make a difference between a unicast message and a multicast message. We focus our evaluation on the number of these messages.

Simulation model

In our simulations, we use a KMGM hierarchy composed of 5 subgroups presented in figure 1. Almeroth et al. showed in [Almeroth andAmmar 1996, Almeroth and[START_REF] Almeroth | [END_REF]] that the dynamism of some multicast sessions over the MBone (Multicast Backbone) can be modeled as follows: the users arrive in a multicast group according to a Poisson process with rate λ (arrivals/time unit), and the membership duration of a member in the group follows an exponential distribution with a mean duration 1 µ time units. In our case, we apply this model to each area. Unless specified otherwise, we considered a session of 3 hours, where members arrive following a Poisson law with an average inter-arrival equal to 20 seconds, an inter-move equal to 15 seconds and remain in the session 30 minutes in average. After each θ = 15min, the area key distributors reconsider the dynamism information and decide to become active or passive using the heuristic described in [Challal et al. 2008]. The affectation of arriving members to the different subgroups is random and follows a uniform distribution with percentages varying over time. In table 2, we illustrate the percentage distribution of arrivals to the different subgroups during the whole session.

For mobility scenario (figure 1), we first choose the leaving area using a uniform distribution, so that, each area has the same probability of selection. After that, a destination area, unlike leaving one, is chosen using the same law. Finally, the mobile member is chosen from the leaving area. All the current members have the same selection probability independently from their joining date. The selection probabilities of areas and members during the mobility are then equiprobable.

Period 1 2 3 4 5 0h-1h 20% 20% 40% 15% 5% 1h-2h 40% 20% 20% 15% 5% 2h-3h 15% 20% 5% 40% 20%

Simulation results

Impact of the group size

In a first stage, we were interested in the size scalability of KMGM compared to the other approaches in what relates to 1-affects-n and decryption /re-encryption overheads which is a computation overhead. Two parameters of our simulation model control the size of the group: the average inter-arrival of members into the session, and the average membership duration of the members in the session. In figures 2 and 3 we varied the average inter-arrival from 1 second to 65 seconds and we measured the 1-affects-n, the decryption / re-encryption overheads and the number of re-keying messages, respectively.

The smallest values of the inter-arrival correspond to the largest sizes of the group. With the GKMP protocol, all the members are affected and hence protocol is bigger. For the same range of inter-arrival values, Iolus, M-IOLUS and KMGM reduce the number of affected members to the minimum. Therefore, our approaches and M-Iolus scale better to large and dynamic groups. Moreover, notice in figure 3 that when the inter-arrival increases, and hence the group size decreases, Iolus and M-Iolus performs always the same number of decryption / re-encryption operations (5 operations). We refer by operations to the number of encryption areas. Indeed, for Iolus and M-Iolus this number is always equals to 5 the number of areas in the group. However, KMGM reduces this overhead while maintaining low 1-affects-n overhead. For the smallest groups, KMGM reaches the same performance of the GKMP protocol in performing a single encryption at the source and decryption at receivers. In figure 4, we can easily see that the average number of re-keying messages in KMGM is smaller in other solutions. This is due to the fact when a member leaves the group the list of old members are emptied in all areas that the expelled member has previously visited. Thereby, in further departures, these areas will not be affected since their TEKs have been updated.

We can notice the same phenomenon by varying the average membership duration of the members in the session. In figure 5, we remark that KMGM and M-Iolus scale better to large groups. We remark also that KMGM scales better than the GKMP protocol.

In figure 6, we remark again that KMGM has the advantage over KMGM and M-Iolus of decreasing the decryption / re-encryption without dramatically increasing the 1-affects-n overhead. When membership duration increases, SM s have tendency to be passive, and thus the number of decryption/re-encryption operations decreases.

The same behavior of KMGM can be seen in figure 7 where the average number of re-keying messages is smaller comparing to other solutions.

Impact of the mobility

In a second stage, we were interested by the impact of mobility members inside the group. We have varied inter-moves from 1 second to 15 seconds in order to have a high mobility scenario. In figure 8, we can see that for smallest values of inter-moves ([1s,5s]), which corresponds to a high mobility, the average number of affected members in KMGM and M-Iolus is smaller than other protocols because they are not affected by mobility of members between areas. This number is few greater in KMGM because the size of affected areas is greater in KMGM. Indeed, for the same interval we see in figure 9 that the number of encryption areas is smaller in KMGM comparing to M-Iolus. This means that areas are merged to use the same TEK. However, in figure 10, we see that the average number of re-keying messages in KMGM is very smaller compared to M-Iolus and other protocols. This is due to the fact that list of old members are emptied when there is a leave. So, the corresponding members will not induce re-keying in future membership changes. We know that the great number or re-keying messages is generated in case of leave (cf. section 4.3).

We conclude that KMGM deals better with members mobility thanks to reducing both the number of affected members and the number of re-keying messages. Our protocols is suitable to dynamic groups and wireless mobile en- vironments where there is a high members' mobility.

Conclusion

Several group key management protocols have been proposed to minimize the overall overhead in a scalable and secure manner. However, all the approaches have some shortcomings in handling group dynamism. The centralized schemes suffer from the 1-affects-n phenomenon especially if the group membership is highly dynamic. The distributed nature of group-oriented services has a huge impact on security efficiency. On one hand, a group distribution tree can span large networks where members may be tremendously distant from each other. On the other hand, the efficiency of group security mechanisms can be severely affected by some phenomena that depend on their occurrence location in the network. Besides, in mobile environments the mobility of members between areas and subnets complicates key management and authentication in the group. Given this group communication feature, we proposed in this paper a group key management protocol to secure group communication in mobile environments where we treat members dynamism and mobility with minimizing re-keying messages. Indeed, we proposed a mechanism that avoids to renew the TEK when the member moves from an area to another. Simulation results showed that our protocols achieves a better performance trade-offs comparing to other protocols.

Figure 1 :

 1 Figure 1: The KMGM Architecture and mobilty scenarios.

Figure 2 :Figure 3 :Figure 4 :

 234 Figure 2: Impact of inter-arrival variation on 1-affects-n overhead.

Figure 5 :

 5 Figure 5: Impact of membership duration variation on 1-affects-n overhead.

Figure 6 :

 6 Figure 6: Impact of membership duration on decryption / re-encryption overhead (same behaviour for IOLUS and M-IOLUS).

Figure 7 :

 7 Figure 7: Impact of membership duration on re-keying overhead.

Figure 8 :

 8 Figure 8: Impact of inter-move variation on 1-affects-n overhead.

Figure 9 :

 9 Figure 9: Impact of inter-move variation on decryption / re-encryption overhead (same behaviour for IOLUS and M-IOLUS).

Figure 10 :

 10 Figure 10: Impact of inter-move variation on decryption / re-encryption overhead.

Table 1 :

 1 Nomenclature.

	Symbol	Signification	Role
	T EK	Traffic Encryption Key	Used to encrypt and decrypt group mes-
			sages. newT EK and oldT EK refers to the
			newly generated TEK and currently used
			TEK, respectively. This is a symmetric key.
	AKD	Area Key Distributor	This entity is responsible of key manage-
			ment inside an area.
	SEK	Session Encryption Key	This key is known only by AKDs. This is
			a symmetric key.
	KEK	Key Encryption Key	Used to encrypt other keys. This is a sym-
			metric key.
	ai	Area i	a set of group members using the same
			T EK.
	C k	Cluster of areas	A set of areas using the same T EK.
	M EK	Member Encryption Key	Used to encrypt messages between AKD
			and member. Each member m l owns its
			M EK identified by M EK l . This is a sym-
			metric key.
	ks	Private key	ks l is the private key of member m l . This
			is an asymmetric key.
	kp	Public key	kp l is the public key of member m l . This is an asymmetric key.
	ListMi	List of members	Contains the list of current members inside
			area ai.
	ListOi	List of old members	Contains the list of old members of area ai
			which moved to other areas.
	Xi	X of area ai	X refers to AKD, TEK, KEK, ListM or
			ListO

Table 2 :

 2 Percentage distribution of arrivals to the different subgroups.


Silvia Gil Casals
email: silvia.gil-casals@fr.thalesgroup.com

Philippe Owezarski
email: philippe.owezarski@laas.fr

Gilles Descargues
email: gilles.descargues@fr.thalesgroup.com

Risk Assessment for Airworthiness Security

Keywords: airworthiness, risk assessment, security, safety, avionic networks 1

The era of digital avionics is opening a fabulous opportunity to improve aircraft operational functions, airline dispatch and service continuity. But arising vulnerabilities could be an open door to malicious attacks. Necessity for security protection on airborne systems has been officially recognized and new standards are actually under construction. In order to provide development assurance and countermeasures effectiveness evidence to certification authorities, security objectives and specifications must be clearly identified thanks to a security risk assessment process. This paper gives main characteristics for a security risk assessment methodology to be integrated in the early design of airborne systems development and compliant with airworthiness security standards.

Introduction

The increasing complexity of aircraft networked systems exposes them to three adverse effects likely to erode flight safety margins: intrinsic component failures, design or development errors and misuse. Safety processes have been capitalizing on experience to counter such effects and standards were issued to provide guidelines for safety assessment process and development assurance. Safety-critical systems segregation from the Open World tends to become thinner due to the high integration level of airborne networks. Most of the challenging innovations to offer new services, ease air traffic management, reduce development and maintenance time and costs, are not security-compatible. They add a fourth adverse effect, increasingly worrying certification authorities: vulnerability to deliberate or accidental attacks. As a matter of fact, EUROCAE 1 and RTCA 2 are defining new airworthiness security standards: ED-202 [START_REF]European Organization for Civil Aviation Equipment (EUROCAE WG-72) and Radio Technical Commission for Aeronautics (RTCA SC-216): Airworthiness security process specification[END_REF] provides guidance to achieve security compliance objectives based on future ED-203 3 [2] methods.

EU and US 4 certification authorities are addressing requests to aircraft manufacturers so they start dealing with security issues. However, ED-203 has not been officially issued and existing risk assessment methods are not directly applicable to the aeronautical context: stakes and scales are not adapted, they are often qualitative and depend on experimented security managers criteria. Also, an important stake in aeronautics is costs minimization. On the one hand, if security is handled after systems have been implemented, modifications to insert security countermeasures, re-development and re-certification costs are overwhelming: "fail-first patch-later" [START_REF] Jacob | High assurance security and safety for digital avionics[END_REF] IT security policies are not compatible with aeronautic constraints. It is compulsory that risk assessment is introduced at an early design step of development process. On the other hand, security over-design must be avoided to reduce unnecessary development costs: risk needs to be quantified in order to rank what has to be protected in priority.

This paper introduces a simple quantitative risk assessment framework which is: compliant with ED-202 standard, suitable to the aeronautics, adaptable to different points of view (e.g. at aircraft level for airframer, at system level for system provider) and taking into account safety issues. This methodology is in strong interaction with safety and development processes. Its main advantage is to allow the identification of risks at an early design step of development V-cycle so that countermeasures are consistently specified before systems implementation. It provides means to justify the adequacy of countermeasures to be implemented in front of certification authorities.

Next chapter gives an overview of risk assessment methods; third one, depicts our six-step risk assessment framework, illustrated by a simple study case in chapter 4; last one concludes on pros and cons of our method and enlarges to future objectives.

About Risk Assessment Methods

Many risk assessment methodologies aim at providing tools to comply with ISO security norms such as: ISO/IEC:27000, 31000, 17799, 13335, 15443, 7498, 73 and 15408 (Common Criteria). For example, MAGERIT (Spain) and CRAMM (UK) deal with governmental risk management of IT against for example privacy violation. NIST800-30 provides security management steps to fit into the system development life-cycle of IT devices. Others, such as COBRA or OCTAVE aim at ensuring enterprise security by evaluating risk to avoid financial losses and brand reputation damage. Previously stated methods are qualitative, i.e. no scale is given to compare identified risks between them. MEHARI proposes a set of checklists and evaluation grids to estimate natural exposure levels and impact on business. Finally, EBIOS shows an interesting evaluation of risks through the quantitative characterization of threat sources of a wide spectrum of threats (from espionage to natural disasters) but scales of proposed attributes do not suit to the aeronautic domain.

Risk is commonly defined as the product of three factors: Risk = Threat × Vulnerability × Consequence. Quantitative risk estimations combine these factors with more or less sophisticated models (e.g. a probabilistic method of risk prediction based on fuzzy logic and Petri Nets [START_REF] Liao | Research on real-time network security risk assessment and forecast[END_REF] vs. a visual representation of threats under a pyramidal form [START_REF] Alhabeeb | Information Security Threats Classification Pyramid[END_REF]). Ortalo, Deswarte and Kaaniche [START_REF] Ortalo | Experimenting with quantitative evaluation tools for monitoring operational security[END_REF] defined a mathematical model based on Markovian chains to define METF (Mean Effort to security Failure), a security equivalent of MTBF (Mean Time Between Failure). Contrary to the failure rate used in safety, determined by fatigue testing or experience feedback, security parameters are not physically measurable. To avoid subjective analysis, Mahmoud, Larrieu and Pirovano [START_REF] Mahmoud | A risk propagation based quantitative assessment methodology for network security[END_REF] developed an interesting quantitative algorithm based on computation of risk propagation through each node of a network. Some of the parameters necessary for risk level determination are computed by using network vulnerability scanning. This method is useful for an a posteriori evaluation, but it is not adapted to an early design process as the system must have been implemented or at least emulated.

Risk Assessment Methodology Steps

Ideally, a security assessment should guarantee that all potential scenarios have been exhaustively considered. They are useful to express needed protection means and to set security tests for final products. This part describes our six-steps risk assessment methodology summarized in Figure 1, with a dual threat scenario identification inspired on safety tools and an adaptable risk estimation method.

Top-down approach

Bottom-up approach

Exposure criteria to be reduced Traceability Fig. 1. Risk assessment and treatment process: the figure differentiates input data for the security process as coming either from the development process or from a security knowledge basis.

3.1

Step 1: Context Establishment First of all, a precise overview of the security perimeter is required to focus the analysis, avoid over-design and define roles and responsibilities. Some of the input elements of a risk analysis should be: security point of view, depth of the analysis, operational use cases, functional perimeter, architecture perimeter (if available), assumptions concerning the environment and users, initial security countermeasures (if applicable), interfaces and interactions, external dependencies and agreements. A graphical representation (e.g. UML) can be used to gather perimeter information, highlight functional interfaces and interactions.

3.2

Step 2: Preliminary Risk Assessment (PRA)

PRA is an early design activity: its goal is to assess designers so they consider main security issues during the first steps of avionic suite architecture definition. Basically, it aims at identifying what has to be protected (assets) against what (threats).

Primary Assets. According to ED-202, assets are "those portions of the equipment which may be attacked with adverse effect on airworthiness". We distinguish primary assets (aircraft critical functions and data) from supporting assets (software and hardware devices that carry and process primary assets). In PRA, system architecture is still undefined, only primary assets need to be identified.

Threats. Primary assets are confronted to a generic list of Threat Conditions (TC) themselves leading to Failure Conditions (FC), e.g.: TC={misuse, confidentiality compromise, bypassing, tampering, denial, malware, redirection, subversion} and FC={erroneous, loss, delay, failure, mode change, unintended function, inability to reconfigure or disengage}.

Top-down Scenarios Definition. Similarly, to safety deductive Fault Tree Analysis (FTA), the security PRA follows a top-down approach: parting from a feared event, all threat conditions leading to it are considered to deduce the potential attack or misuse causes deep into systems and sub-systems. As a matter of time and cost saving, this assessment could be common both to safety and security preliminary processes as they share the same FCs.

Step 3: Vulnerability Assessment

Supporting Assets. Once architecture has been defined and implementation choices are known, all supporting assets of a given primary asset can be identified. Supporting assets are the ones that will potentially receive countermeasures implementation.

Vulnerabilities. They are weaknesses exploited by attackers to get into a system. TC are associated to types of attacks and all exploited vulnerabilities are listed to establish a vulnerability checklist.

Bottom-up Scenarios Definition. Similarly to the safety inductive approach of Failure Mode and Effect Analysis (FMEA), the security vulnerability assessment is a bottomup approach: it aims at identifying potential security vulnerabilities in supporting assets, particularly targeting human-machine and system-system interfaces. First with vulnerability checklists and then by testing, threat propagation paths must be followed to determine the consequences on sub-systems, systems and aircraft level of each item weakness exploitation.

To summarize, the top-down approach allows the identification of high-level security requirements. Whereas the bottom-up approach, allows completing these requirements with technical constraints and effectiveness requirements, as well as identifying threats left unconsidered during the top-down analysis.

3.4

Step 4: Risk Estimation

It would be impossible to handle all of identified scenarios. It is necessary to quantify their likelihood and safety impact, to determine whether risk is acceptable or not, and measure the effort to be provided to avoid most probable and dangerous threats.

Likelihood. It is the qualitative probability that an attack is successful. ED-202 considers five likelihood levels: 'frequent', 'probable', 'remote', 'extremely remote', 'extremely improbable'. As they are too subjective to be determined directly, we built Table 1 to determine likelihood by combining factors that characterize and quantify both attacker capability (A) and asset exposure to threats (E). Table 1 is usable whatever the amount of attributes used, and whatever the number of values each attribute can take, i.e. this framework allows flexible evaluation criteria as they may vary according to the context (aircraft or system level, special environment conditions, threats evolution). These criteria must be defined with an accurate taxonomy so the evaluation is exhaustive, unambiguous and repeatable.

Let ܺ ൌ ሼܺ ଵ , … , ܺ ሽ be a set of n qualitative attributes chosen to characterize the "attacker capability". Each attribute ܺ can take m values: ሼܺ ଵ , … , ܺ ሽ, ܺ being more critical than ܺ ିଵ and so on. To each qualitative value ܺ , we associate a quantitative value ݔ with ݔ > ݔ ିଵ and so on. Let us call ݂ ሺሻ the evaluation function performed by the security analyst allowing to assign the corresponding value ܽ to each ܺ for a given threat scenario: ܽ ൌ ݂ ୀଵ ሺݔ ሻ. Attacker capability is expressed by the normalized sum of the values assigned to all attributes of set ܺ (see equation 1). The same reasoning is made to express asset exposure E.

ܣ ൌ ቆ ܽ ݔ ቇ ୀଵ , ݔ ݔ  ݆ ൌ 1, … , ݉ ሺ1ሻ
Acceptability. To determine whether a risk is acceptable or not, we use Table 2: the ED-202 risk matrix that associates safety impact and likelihood. Safety impact levels are: 'N/E: no safety effect', 'MIN: minor', 'MAJ: major', 'HAZ: hazardous', 'CAT: catastrophic'.

Step 5 and 6: Security Requirements and Risk Treatment

For each non acceptable threat scenario, security objectives (i.e. asset exposure criteria to be reduced) are translated into Security Functional Requirements to find the best countermeasure to be implemented on most exposed supporting asset. A Security Level (SL) is assigned based on required risk reduction so that risk becomes acceptable. Depending if the likelihood has to be reduced of 0, 1, 2, 3 or 4 levels to be on an acceptable level, SL will respectively take the values E, D, C, B or A. SL has a dual signification, it stands both for effectiveness (assurance must be provided that countermeasures perform properly and safely their intended functions) and implementation assurance (assurance must be provided that security countermeasure has followed rigorous design and implementation process). SL is assigned on developed countermeasures and associated assurance requirements will be given by ED-203.

Study Case

Scope. Let us consider the Weight and Balance (WBA) function that ensures 3D stability control of aircraft gravity center. It determines flight parameters (e.g.: quantity of kerosene to be loaded, takeoff run and speed, climbing angle, cruising speed, landing roll) and requires interactions with ground facilities. Check-in counters furnish number and distribution of passengers in the aircraft. Ground agent enters weight of bulk freight loaded in aft hold. Weight data is directly sent via data link to the ground WBA calculation tool to compute flight parameters. On ground, flight crew imports flight parameters to be directly loaded in the Flight Management System (FMS). Risk Treatment. For case 1 and 2, an organizational countermeasure is having a third party checking the weight data entered by ground agent. For case 1, a technical countermeasure is simply having the software used by ground agent asking to type twice the value to avoid typing mistakes. For case 2, a personal authentication password should be added to ground agent computer. Case 3 does not need treatment as an attacker able to break into the system must be very prepared and have a critical knowledge of the system, which is considered as unlikely to happen.

Conclusion

This paper justifies the need to develop an efficient risk assessment method to build secured architectures for digital aircrafts. We aim at introducing security considerations at an early design step of the development, allowing a certain degree of freedom to use attributes that best fit to the scope of analysis. Criteria taxonomy rules should be improved by practice to make procedures as systematic and accurate as possible.

Readjustments will have to be made to comply with future ED-203 modifications.

Table 1 .

 1 Attack likelihood through attacker characteristics and asset exposure

				ATTACKER CAPABILITY SCORE
			0 ≤ A ≤ 0,2	0,2 < A ≤ 0,4 0,4 < A ≤ 0,6 0,6 < A ≤ 0,8 0,8 < A ≤ 1
		0 ≤ E ≤ 0,2	pI	pI	pII	pIII	pIV
	EXPOSURE	0,2 < E ≤ 0,4 0,4 < E ≤ 0,6 0,6 < E ≤ 0,8	pI pII pIII	pI pII pIII	pII pIII pIV	pIII pIV pV	pIV pV pV
		0,8 < E ≤ 1	pIV	pIV	pV	pV	pV

Table 2 .

 2 ED-202 acceptability risk matrix

					SAFETY IMPACT
			No Effect	Minor	Major	Hazardous	Catastrophic
	LIKELIHOOD	pV: Frequent pIV: Probable pIII: Remote pII: Extremely Remote	Acceptable Acceptable Acceptable Acceptable	Unacceptable Acceptable Acceptable Acceptable	Unacceptable Unacceptable Acceptable Acceptable	Unacceptable Unacceptable Unacceptable Acceptable	Unacceptable Unacceptable Unacceptable Unacceptable
		pI: Extremely Improbable	Acceptable	Acceptable	Acceptable	Acceptable	Acceptable*
	* = assurance must be provided that no single vulnerability, if attacked successfully, would result in a catastrophic condition

Table 5 .

 5 Risk estimation: likelihood, impact, acceptability and SL determination

	TS	Attacker capability a1 a2 a3 a4 a5 A e1 e2 e3 e4 e5 En Asset Exposure	Likelihood Impact Acceptable? SL

Respectively EASA (European Aviation Safety Agency) and FAA ( Federal Aviation Administration)

PRA. Figure 2 depicts the top-down approach of threat scenario building, with identified primary assets, Failure and Threat Conditions. It should be shaped as a FTA but we choose this representation for a matter of space, left-right rows are causal links. Fig. 2. Top-down approach threat scenario identification: from feared event to potential causes Vulnerability Assessment. Most of supporting assets in this study case are COTS which are vulnerable to malware. Let us say that these COTS present the following weaknesses: activated autorun, system bootable from peripherals, connection to Internet, no antivirus, no passwords. Then, these vulnerabilities could be exploited by intruders or by a certain kind of boot virus. These case will not be further developed.

Risk Estimation. We estimate threat scenarios (TS) derived from TC 1 to 3 on Fig. 2: "ground agent weight typing mistake on freight laptop"(TS1), "unauthorized person enters deliberately wrong weight data on freight laptop"(TS2) and "intruder modifies flight parameters by accessing directly to FMS"(TS3). Scenarios are evaluated with tables 3 and 4 and ݂ ୀଵ ൫ݔ ൯ ൌ ݆. Results are summarized on table 5.


M.D.; Mona Hedreville

Ph.D.; Philippe Connes
email: pconnes@yahoo.fr

Ph.D.; Marc Romana

M.D Guillaume Magnaval

M.D.; Thierry David

Ph.D.; Marie-Dominique Hardy-Dessources

M.D.; Marie-Sylvaine Belloy

M.D.; Maryse Etienne-Julan

Ph.D Olivier Hue

Central retinal vein occlusion in a sickle cell trait

Keywords: hemoglobinopathy, exercise, ophthalmologic complications, red blood cell, coagulation hemoglobinopathy, exercise, ophthalmologic complications, red blood cell, coagulation

à la diffusion de documents scientifiques 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

Paragraph 1: The heterozygous form of sickle cell anemia (sickle cell trait; SCT) is usually considered as a benign disorder by ophthalmologists, as compared with other forms of sickle cell disease known to be associated with ocular complications [START_REF] Wolf | Retinal vascular occlusion following traumatic hyphema and glaucoma, as a presenting sign of sickle cell trait[END_REF]. We report the first case of CRVO (central retinal vein occlusion) coincident with prolonged and intense exercise that rapidly worsened to neovascular glaucoma and painful blindness, in a young athlete with SCT. Since SCT carriers are often marked by coagulation activity imbalance [START_REF] Westerman | Coagulation changes in individuals with sickle cell trait[END_REF], blood rheological disorders [START_REF] Monchanin | Hemorheology, sickle cell trait, and alpha-thalassemia in athletes: effects of exercise[END_REF][START_REF] Tripette | Does Repeated and Heavy Exercise Impair Blood Rheology in Carriers of Sickle Cell Trait?[END_REF] and abnormalities in vascular adhesion processes [START_REF] Monchanin | Effects of a progressive and maximal exercise on plasma levels of adhesion molecules in athletes with sickle cell trait with or without {alpha}-thalassemia[END_REF][START_REF] Tripette | Patterns of exercise related inflammatory response in sickle cell trait carriers[END_REF], both at rest and in response to exercise, we propose that blood and vascular dysfunctions might have contributed to the occurrence of this adverse event.

Case report

Paragraph 2: A previously healthy 26-year-old Afro-Caribbean male cyclist was admitted to the Ophthalmology Department of the University Hospital of Pointe-à-Pitre the day after a prolonged and intense cycling race in Guadeloupe, a French West Indies island. The competition consisted of 138 kilometers in mountainous terrain and high ambient temperature (35°C) with 60% of humidity. The patient felt himself particularly thirsty all along the race. At hospital admission, he presented a sudden loss of visual acuity (VA) of the left eye (6/20). VA of the right eye was normal (20/20). Intraocular pressure (IOP) was normal in both eyes (14 mmHg). Ophthalmoscopy and fluorescein angiography of the left eye documented CRVO with massive retinal hemorrhage (Figure 1). The clinical interview revealed that 1) the patient had already experienced a loss of visual acuity of his left eye two months earlier with spontaneous recovery within two days and 2) he was a SCT carrier. Blood sampled was obtained to confirm the SCT status by isoelectric focusing and high performance liquid chromatography (Table 1). Hematological parameters, inflammatory and biochemical markers were normal (Table 1). The anticardiolipin antibody test was negative (Table 1). Unfortunately, a technical problem occurred during the analysis of the blood coagulation parameters that deprived us of data at that time. An in-depth assessment of cardiovascular function was also performed. The electrocardiographic measurements demonstrated sinusal rhythm, normal QRS and repolarization. Neither anomaly in the supra-aortic tree using arterial echo Doppler, nor evidence of structural heart disease on echocardiography was detected.

The trans-thoracic echocardiogram was normal but the trans-esophageal echocardiogram revealed the presence of four thrombi in the left atrium. Medical treatment associating troxerutin (Veinamitol®), a venotonic agent, and acetylsalicylic acid (Kardégic®) was prescribed by the Department of Ophthalmology. Anti-vitamin K medication was also given by the cardiologists to treat the left atrial thrombi. The patient was instructed to avoid physical exercise until the next visit. One month later, because of a severe ischemic form of the disease, panretinal photocoagulation treatment was given in emergency to manage CRVO.

Paragraph 3:

The patient returned one month later to the Department of Ophthalmology for headache, nausea and vomiting, blindness and eye pain in the left eye. The interview revealed that the patient had been doing heavy weight lifting, such as 3-5 maximal repetition method, when these medical signs suddenly appeared. Biomicroscopic exam demonstrated important iris rubeosis and neovascular glaucoma with corneal edema. The neovascular glaucoma was confirmed by gonioscopy. The patient was immediately hospitalized and hypotonic medication was given intravenously (acetazolamide, Diamox®) as well as locally (timolol maleate, Ophtim®), which decreased IOP to 20 mmHg. A complement of panretinal photocoagulation was performed in emergency as soon as the corneal edema was sufficiently reduced. Despite anticoagulation medication, a new trans-esophageal echocardiogram performed three days later revealed two remaining thrombi in the left atrium suggesting that blood coagulation disturbances were still persistent.

Paragraph 4: Two weeks later, the IOP was still high (> 21 mmHg) and the patient complained of eye pain. Cryotherapy was performed on both the ciliary body and retina. One month later, assessment of blood rheology by viscometric method (10,28) demonstrated high red blood cell (RBC) rigidity (Table 2). Blood coagulation parameters (activated partial thromboplastin time, prothrombin time and antithrombin III) were also successfully measured and showed normal values (Table 2).

Paragraph 5:

The eye pain disappeared at this time, and the patient has since been chronically medicated with rimexolone (Vexol®), dorzolamide (Trusopt®), brimonidine tartrate (Alphagan®) and latanoprost (Xalatan®) to stabilize the IOP. Medication for platelet anti-aggregation was also prescribed for the patient and exercise is not currently recommended. The patient is followed by the Department of Ophthalmology and the Department of Cardiology every two months to monitor IOP and cardiovascular function. The IOP is now stabilized (12 mmHg) but the left eye is marked by total retinal detachment and very low visual acuity, which is limited to weak luminous perception.

Paragraph 6: Informed consent was obtained from the patient and DNA studies were conduced.

Briefly, DNA from blood sample was extracted using standard procedure and detection of the prothrombin A 20210, methyltetrahydrofolate reductase T 677 and factor V Leiden alleles were performed as previously described [START_REF] Frosst | A candidate genetic risk factor for vascular disease: a common mutation in methylenetetrahydrofolate reductase[END_REF][START_REF] Nowak-Göttl | Prospective evaluation of the thrombotic risk in children with acute lymphoblastic leukemia carrying the MTHFR TT 677 genotype, the prothrombin G20210A variant, and further prothrombotic risk factors[END_REF][START_REF] Poort | A common genetic variation in the 3'untranslated of the prothrombin gene is associated with elevated plasma prothrombin levels and an increase in venous thrombosis[END_REF]. DNA analysis revealed that the patient did not carry any of these genetic risk factor for retinal vascular occlusion and thrombotic event [START_REF] Chak | Thrombophilia: genetic polymorphisms and their association with retinal vascular occlusive disease[END_REF].

Discussion

Paragraph 7: We report the first identified case of CRVO associated with prolonged and intense exercise in a SCT carrier with no past history of treatment for ocular complication or other disease.

The patient was well trained in endurance cycle and performed 3 cyclists outing per week (2 short ones of 60 -80 km and a longer one of more than 100 km). In addition, he practiced weight lifting twice a week to complete his training regimen. The situation rapidly deteriorated to neovascular glaucoma and blindness of the eye. Several studies have reported ocular complications in SCT but these complications have usually been described as the consequence of traumatic hyphema (19,[START_REF] Michelson | Retinal arterial occlusion following ocular trauma in youths with sickle-trait hemoglobinopathy[END_REF][START_REF] Wolf | Retinal vascular occlusion following traumatic hyphema and glaucoma, as a presenting sign of sickle cell trait[END_REF]. Ophthalmologists therefore consider SCT as a benign condition compared with SS or SC hemoglobinopathy [START_REF] Wolf | Retinal vascular occlusion following traumatic hyphema and glaucoma, as a presenting sign of sickle cell trait[END_REF]. However, this issue is still debated since several reports suggest that SCT could be viewed as a potentially dangerous disorder [START_REF] Ajayi | Should the sickle cell trait be reclassified as a disease state?[END_REF][START_REF] Wirthwein | Death due to microvascular occlusion in sickle-cell trait following physical exertion[END_REF], particularly in response to prolonged and intense exercise [START_REF] Connes | Counterpoint: Sickle cell trait should not be considered asymptomatic and as a benign condition during physical activity[END_REF][START_REF] Dincer | Compartment syndrome and fatal rhabdomyolysis in sickle cell trait[END_REF][START_REF] Jones | Sudden death in sickle-cell trait[END_REF][START_REF] Kark | Exercise and hemoglobin S[END_REF][START_REF] Gallais | Point-Counterpoint: Sickle cell trait should/should not be considered asymptomatic and as a benign condition during physical activity[END_REF][START_REF] Gallais | Point: Sickle cell trait should be considered asymptomatic and as a benign condition during physical activity[END_REF][START_REF] Wirthwein | Death due to microvascular occlusion in sickle-cell trait following physical exertion[END_REF].

Paragraph 8: Interestingly, impaired blood rheology was suggested to be a risk factor for CRVO [START_REF] Lip | Abnormalities in haemorheological factors and lipoprotein (a) in retinal vascular occlusion: implications for increased vascular risk[END_REF]. Gaudard et al. [START_REF] Gaudard | Exerciseinduced central retinal vein thrombosis: possible involvement of hemorheological disturbances. A case report[END_REF] recently demonstrated that hemorheological disturbances are likely to be involved in CRVO. SCT carriers usually have impaired RBC deformability in basal conditions [START_REF] Monchanin | Hemorheology, sickle cell trait, and alpha-thalassemia in athletes: effects of exercise[END_REF], as confirmed by the high RBC rigidity found in the present study. Unfortunately, it was not possible to assess RBC rigidity closer to the ocular incident (i.e., the day after the cycling race).

Exercise is known to further impair blood rheology in SCT carriers because of the increased sickling of erythrocytes, particularly in hot environment (4), and we recently demonstrated that RBC deformability is further impaired 24 hours after strenuous exercise [START_REF] Tripette | Does Repeated and Heavy Exercise Impair Blood Rheology in Carriers of Sickle Cell Trait?[END_REF]. Therefore, it is conceivable that RBC deformability was also impaired the day after the cycling race and that such abnormality would have been favorable to the occurrence of CRVO. Moreover, the patient reported that, despite its efforts to drink water, he felt particularly thirsty during and after the race. Sherry [START_REF] Sherry | Sickle cell trait and rhabdomyolysis: case report and review of the literature[END_REF] hypothesized that dehydration might contribute to the development of sickling and that SCT carriers might be naturally more predisposed to dehydration due to their inability to concentrate their urine when deprived of water [START_REF] Sherry | Sickle cell trait and rhabdomyolysis: case report and review of the literature[END_REF]. This defect might make SCT carriers less able to conserve water than non-carriers and could have played a role in the occurrence of CRVO. Indeed, higher amount of water intake with appropriate amount of electrolytes (notably sodium) (32) may be required for exercising SCT carriers in comparison with control subjects.

Paragraph 9: Abnormal coagulation activities are also among the several risk factors associated with CVRO [START_REF] Fruschelli | Coagulative, fibrinolytic and metabolic pattern in patients with central retinal vein occlusion[END_REF] The role of hemostasis-fibrinolysis balance in CRVO is supported by the recent results of Ghazi et al. [START_REF] Ghazi | Intravitreal tissue plasminogen activator in the management of central retinal vein occlusion[END_REF], who demonstrated that intravitreal tissue plasminogen activator injection may have a beneficial role in the management of CRVO. Westerman et al. [START_REF] Westerman | Coagulation changes in individuals with sickle cell trait[END_REF] reported elevated d-dimers, thrombin-antithrombin complexes and prothrombin fragments 1.2 in SCT carriers at rest, suggesting that they may be prone to a hypercoagulable state in resting conditions [START_REF] Westerman | Coagulation changes in individuals with sickle cell trait[END_REF]. In addition Austin et al. ( 3) recently provided strong evidences of higher risk to develop venous thromboembolism (odds ratio: 1.8) and pulmonary embolism (odds ratio: 3.9) among African Americans with SCT than in non SCT carriers, in agreement with the reported disequilibrium between coagulation and fibrinolytic activities in SCT carriers. Nevertheless, these results contrast with the present finding of no disorder of blood coagulation two and a half months after the incident (Table 2). Our patient did not carry any of the known genetic risk factor for retinal vascular occlusion, namely prothrombin A 20210, methyltetrahydrofolate reductase T 677 and factor V Leiden variants.

Paragraph 10: Due to technical problems, the markers of coagulation could not be obtained at the time of the incident and it is possible that, had we obtained them, the blood coagulation properties would have been different. The presence of four thrombi in the left atrium after the occurrence of CRVO strongly suggested the hypercoagulable state of the patient when the incident occurred.

Prolonged exercise usually causes changes in coagulation activity in healthy persons [START_REF] El-Sayed | Effects of exercise on blood coagulation, fibrinolysis and platelet aggregation[END_REF].

Mandalaki et al. [START_REF] Mandalaki | Marathon Run III: effects on coagulation, fibrinolysis, platelet aggregation and serum cortisol levels. A 3year study[END_REF] previously reported a decrease in antithrombin III activity after a marathon.

Therefore, the stress caused by the cycling race could have disturbed the balance between hemostasis and fibrinolysis [START_REF] Westerman | Coagulation changes in individuals with sickle cell trait[END_REF], leading to increased risk for CRVO. We recently demonstrated no difference in prothrombin time, activated partial thromboplastin time, antithrombin III activity and yield stress between SCT carriers and a control population, before and after a strenuous cycling exercise test conducted in laboratories condition [START_REF] Connes | Effects of strenuous exercise on blood coagulation activity in sickle cell trait carriers[END_REF]. Although large hemostatic dysregulations in SCT carriers following exercise, such as disseminated intravascular coagulation [START_REF] Koppes | Exertion-induced rhabdomyolysis with acute renal failure and disseminated intravascular coagulation in sickle cell trait[END_REF], have already been reported, we did not investigate fibrinolytic activity in that study [START_REF] Connes | Effects of strenuous exercise on blood coagulation activity in sickle cell trait carriers[END_REF].

Therefore, no conclusion regarding the coagulation activity of the patient at the time of the incident is possible.

Paragraph 11: Despite the panretinal photocoagulation and the venotonic and platelet antiaggregating agent treatment, the CRVO rapidly worsened to rubeosis iridis and neovascular glaucoma, which led to a second emergency hospital visit. Interestingly, the signs of ocular complication (blindness, eye pain, headache, nausea and vomiting) appeared immediately after a session of resistance training. Although it may prove difficult to tease out whether it was the intensity or just the type of exercise that contributed to this second incident, resistance training (and particularly heavy weight lifting) is also known to alter blood rheological parameters and blood coagulation [START_REF] Ahmadizad | The acute effects of resistance exercise on the main determinants of blood rheology[END_REF][START_REF] El-Sayed | Fibrinolytic and hemostatic parameter response after resistance exercise[END_REF]. These alterations could have been involved in the surprising and rapid ocular complication observed in our patient. Despite anti coagulation medication, two thrombi were present at that time in the left atrium suggesting, again, disequilibrium of the balance between hemostasis and fibrinolytic activity. Despite clear medical recommendations, the patient did not stop practicing intense physical activities, which illustrates the problem of preventing and managing further exercise related medical complication in a sportsman.

Paragraph 12: Although under multiple medical treatments, the patient unfortunately lost his left eye. The exact reasons for this severe ocular incident are not clearly understood, and the most surprising event was the rapid deterioration of CRVO to neovascular glaucoma. Usually, the occurrence of CRVO (whether induced by exercise or not) in young men is well managed, leading to recovery [START_REF] Gaudard | Exerciseinduced central retinal vein thrombosis: possible involvement of hemorheological disturbances. A case report[END_REF] with minimal visual after effects. However, this was not the case in the present study and the poor outcome for our patient could be related to its SCT carrier status. Indeed, the concomitant occurrence of hypoxia, dehydration and acidosis, conditions occurring during excercice, is favorable to the sickling process [START_REF] Bookchin | Determinants of red cell sickling. Effects of varying pH and of increasing intracellular hemoglobin concentration by osmotic shrinkage[END_REF] and coagulopathy [START_REF] Jones | Sudden death in sickle-cell trait[END_REF]. The presence of SCT and the associated hemorheological disorders could have played a role in the complications (i.e., retinal detachment and blindness).

Paragraph 13: Altogether, the data presented in this case study suggest that SCT status could be another genetic risk factor for severe ocular complications, particularly when severe exercise is performed in extreme climatic conditions. While SCT carriers often participate in sports and related training, particular attention to preventing dehydration and starting exercise gradually may be warranted. These recommendations have to be applied to the general population; but we do advocate that physicians and trainers should pay a greater attention to people (trained or untrained) carrying SCT. The recommendation on adequate hydration is particularly important for SCT carriers because they are naturally more predisposed to dehydration due to their inability to concentrate their urine when deprived of water [START_REF] Sherry | Sickle cell trait and rhabdomyolysis: case report and review of the literature[END_REF]. This defect might make SCT carriers less able to conserve water than non-carriers. Blood rheological disorders and coagulation imbalance following intense physical exercise such as heavy and prolonged cycling race could promote CRVO in SCT carriers. This report provides data suggesting that SCT could be considered as a risk factor for severe ocular complications when severe exercise is performed. Several forms of clinical complications related to exercise or not, have already been described in SCT carriers and might be related to different blood and vascular dysfunctions [START_REF] Connes | Blood rheology abnormalities and vascular cell adhesions mechanisms in sickle cell trait carriers during exercise[END_REF][START_REF] Connes | Physiological Responses of Sickle Cell Trait Carriers During Exercise[END_REF].

Figure legends : Figure 1 :

 :1 Figure legends:

Acknowledgments:

This work was supported by our academic funding. The results of the present study do not constitute endorsement by ACSM.

Conflict of interest:

We state that there is no conflict of interest.

Responses to the reviewers and list of changes

Med Sci Sports Exerc -MSSE-D-08-00064R1

Central retinal vein occlusion in a sickle cell trait carrier after a cycling race

Mona Hedreville, Philippe Connes, Marc Romana, Guillaume Magnaval, Thierry David, Marie-Dominique Hardy-Dessources, Marie-Sylvaine Belloy, Maryse Etienne-Julan, and Olivier Hue.

We would like to thank the reviewers for their critical appraisals and interesting comments on our manuscript. We have attempted to fully answer all the questions and to respond with more details where required. The changes introduced in the reviewed manuscript are in red to make the reviewing process easier.

Reviewer 1:

No further comments

Reviewer 2:

First, the authors would like to thank the reviewer for her/his additional comments.

General comments

1) Regarding the "centered" or "middle dot" ("•") character, perhaps this was converted to a "period" in the submission process, and copyediting will take care of this.

In any case, the units of measure in the tables should be in a format such as "g•l-1 (superscript)". A few additional specific changes need to be made (indicated below).

We apologize for this mistake. We made the corrections everywhere in the tables.

Specific comments 2) Abstract Line 24: It would be cleaner to change to read "observed two and a half months after the clinical event."

We made the corrections.

3) Abstract Line 38: Change to read "These data suggest that SCT."

We made the changes.

* Response to Reviewers (Revised Manuscripts)

4) Abstract Line 41: Change to read "factor for significant ocular ."

As requested, we replaced "severe" by "significant".

5) Abstract Line 43: Do the authors mean to say "SCT is a contributing factor in blood rheology and vascular dysfunctions"?

Yes, the reviewer is correct. We replaced our sentence by the sentence proposed by the reviewer.

6) Page 3 Line 14: CRVO needs to be defined here. We agree with the reviewer and we inserted the proposed reference.

8) Page 9 Line 50-3: Change to read "general population; but we also advocate."

We made the corrections.

9) Table 2 -Use "incident" vs. "accident" in the legend.

We made the changes. No parameter was outside the reference range