^{1}

^{*}

^{2}

^{*}

^{3}

^{*}

Group key security protocols play an important role in today’s communication systems. Their verification, however, remains a great challenge because of the dynamic characteristics of group key construction and distribution protocols. Security properties that are well defined in normal two-party protocols have different meanings and different interpretations in group key distribution protocols, specifically, secrecy properties, such as group secrecy, forward secrecy, backward secrecy, and key independence. In this paper, we present a method to verify forward secrecy properties for group-oriented protocols. The method is based on a correct semantical link between group key protocols and event-B models and also uses the refinement process in the B method to model and verify group and forward secrecy. We use an event-B first-order theorem proving system to provide invariant checking for these secrecy properties. We illustrate our approach on the Tree based Group Diffie-Hellman protocol as case study.

Security protocols are used to establish secure channels between communicating systems. These protocols need great care in their development and their implementation. The complexity of security-protocol interactions can hide security weaknesses that normal analysis methods cannot reveal. Security properties that are well defined in normal two-party protocols have different meanings and different interpretations in group key distribution protocols. Therefore, they require a more precise definition before we look at how to verify them. For group key distribution protocols, secrecy property has a further dimension since there are long term secret keys, short-term secret keys, in addition to present, future, and past keys; where a principal who just joined the group and learned the present key should not be able to have enough information to deduce any previous keys, or similarly a principal who just left the group should not have enough information to deduce any future keys.

In group key protocols, there are generally four types of security properties [

Event-B [

Group key protocols have special features, such as the concept of group secrecy, forward secrecy, and dynamic group events. These feature were rarely considered or addressed thoroughly when formal verification techniques were applied. In this paper, we provide an event-B based invariant checking for verification of group key protocols. We model group key protocols and verify their required properties, in particular secrecy and forward secrecy properties, using the event-B method. Event-B deals with tools allowing invariant checking, and can be used to verify group key secrecy properties. In order to model a group key protocol in event-B first order logic, a formal relation between the semantics of the event-B language [

We apply our approach on the tree based Group Diffie-Hellman (TGDH) protocol [

The rest of the paper is organized as follows. Section 2 discusses related work to ours. In Section 3, we present our methodology to verify forward secrecy using event-B refinement. In Section 4, we apply our approach on TGDH protocol. Finally, Section 5 concludes the paper with future work hints.

The recent years have seen the emergence of successful applications of formal approaches to reasoning about security protocols. Earlier methods were concerned with reasoning about the events that a security protocol can perform, and make use of a causal dependency that exists between protocol events. Methods like strand spaces [

Events-based verification of security protocols was used by Crazzolara [

Cremers [

Stouls and Potet [

Bert et al. [

Chridi et al. [

Compared to the above, we address security properties for group oriented protocols, which have special features that were not addressed in any of these approaches, such as the concept of group secrecy and forward secrecy and dynamic group events. In addition, we consider events that are specific for group key protocols that were never treated by the Event-B method. In [

Many methods were developed to verify certain aspects of security protocols such as secrecy and authenticcation. These methods have successfully tackled a number of protocols though in an ad hoc fashion. On the other hand, using formal methods like model checking can be efficient in the verification of authentication property, while modeling and reasoning about properties like forward secrecy requires first-order-logic based methods such as Event-B.

Event-B [

A descriptive specification describes what the system does by using a set of variables, constants, properties over constants and invariants which specify properties that the machine’s state verify. This constitutes the static definition of the model. Operational specification describes the way the system operates. It is composed of a set of atomic events described by generalized substitutions. An event has a guard and an action, and it may occur only when its guard evaluates to true. An event has one of the general forms where the SELECT form is just a particular case of the ANY form. SELECT takes the

form

Name event =

ANY P WHERE

G

THEN R

and similarly a SELECT statement takes the form

nbsp;Name event =

WHEN

G

THEN

R

The consistency of an event-B model is established by proof obligations which guarantee that the initialization verifies the invariant and that each event should preserve the invariant. The guard and the action of an event define a before-after predicate for this event. It describes a relation between variables before the event holds and after this. Proof obligations are produced from events in order to state that the invariant condition is preserved. Let M be an event-B model with v being variables, carrier sets or constants. The properties of constants are denoted by, which are predicates over constants, and the invariant by. Let E be an event of M with guard and before-after predicate that indeed yields at least one after value. The initialization event is a generalized substitution of the form. Initial proof obligation guarantees that the initialization of the machine must satisfy its invariant:.

Each event E, if it holds, has to preserve the invariant. The feasibility statement is illustrated in Lemma 3.1 and the invariant preservation is given in Lemma 3.2 [

An event-B model M with invariant I is well-formed, dented by, only if M satisfies all proof obligetions. The B syntax for generalized substitutions defines three predicates: a relation R, the subsets of the pre-states where G is true of the states in, and the subset of the pre-state where P is true. Let S be restricted to evaluations that satisfy the invariant,. Each event can be represented by a binary relation rel formally defined as. The fact that the invariant is preserved by event rel is simply formalized by saying that rel is a binary relation built on S:. It is shown that this binary relation yields to both Lemmas 3.1 and 3.2 above [

Lemma 3.1 guarantees that the active part of the relation is a total relation, i.e., when all predicates I, P, and G hold, formally, , while Lemma 3.2 guarantees that the postcondition of any operation must satisfy the machine invariant. The initial proof obligation guarantees that the initialization of a machine must satisfy its invariant.

We distinguish special rules for the initialization events. We use to denote the predicate of the generalized substitution associated with this event. Then we obtain the following initialization statements [

Refinement is a technique to deal with the development of complex systems. It consists in building, starting from an abstract model, a sequence of models of increasing complexity containing more and more details. These details could be introduced when using new variables, adding details to abstract events or adding new events. A model in the sequence is followed by a model it refines. The invariant of the refined model is not weaker than the model it refines and it may contain new variables. The events are the same but may be redefined. It is also used to transform an abstract model into a more concrete version by modifying the state description [_{M} with variables v and invariant is refined by a concrete model C_{M} with variables vc and gluing invariant. If and are, respectively, the abstract and concrete before-after predicates of the same event, we have to prove the following statement:

This statement means that under the abstract invariant and the gluing invariant, a concrete step can be simulated by an abstract one in such a way that the gluing invariant is preserved. A new event with before-after predicate must refine skip. This leads to the following statement to prove:

.

Moreover, we must prove that a variant (valuation of variable v) is decreased by each new event (this is to guarantee that an abstract step may occur). We have thus to prove the following for each new event with before-after predicate:

.

At last, we must prove that a concrete model does not introduce more deadlocks than the abstract one. This is formalized by means of the following proof obligation:

where stands for the disjunction of the guards of the events of the abstract model, and stands for the disjunction of the guards of the events of the concrete one. The essence of the refinement relationship is that it preserves already proved system properties including safety properties. The invariant of an abstract model plays a central role for deriving safety properties; the goal is to obtain a formal statement of properties through the final invariant of the last refined abstract model.

In order to reason about group protocols in the first-order logics, a map between the group protocol model and event-B model semantics is defined. The event-B tool guarantees the correctness of the invariant w.r.t the event-B model. The map from group protocols to eventB model guarantees certain equivalence between the two models, under certain conditions. Secrecy property is semantically implied in event-B invariant in a defined and proved lemma. Then, a theorem is defined to guarantees that once an event-B invariant is proved against event-B mode, we can conclude that the secrecy property is correct for the group protocol mode.

In the event-B method, compared to higher-order logic, the number of protocol participants that can be considered is limited, finally, modeling forward and backward simultaneously requires more than two levels of abstracttion, hence, generates more proof obligations, which will reduce automation as more interaction with the tool will be required to discharge these obligations, this is an open issue to be addressed in future work.

The security property is defined in the event-B model based on mapping sets, events, and invariants. For forward secrecy, we use refinement of secrecy. The soundness of the event-B model is then established based on a well-formed link to the group protocol model. The validity of the event-B invariant against its model is checked using the Rodin invariant checking tool. This way, we establish the formal link from the Rodin langauge to the group protocol model.

Let be a group key protocol model, and let be a set of all possible messages (messages space). We choose to represent the secret messages space, the set of all secret messages,. Thereafter, we define to be the set of all events, or dynamic operations, i.e., join, leave, merge, and split. An event is a term from the message space to the message space,. It represents an action the user can perform on the system to update his/her own set of knowledge.

Let be the set of initial knowledge of the intruder, where. The initial knowledge of the information is collected before executing the protocol events. This information is usually publicly known, . We then define as the set of knowledge of the intruder that is updated by executing events. The system starts with the initial set of knowledge and the set of events, then, by executing a sequence of events, it updates this set. and.

We define a safety property for a group key protocol model. This property states that the system cannot execute an event in in order to generate a message in, and is formally modeled as follows:

.

If this property is correct for the protocol, then we can write.

Forward secrecy guarantees that a passive adversary who knows a contiguous subset of old group keys (say) cannot discover any subsequent group key for all i and j, where. We will follow this definition in our model for the rest of the paper.

The proposed verification methodology consists of a number of steps as shown in

col specifications. In addition, the secrecy property expected to be checked by the system is described informally. In the second step, the obtained specification is translated into event-B specification using mapping relations to obtain an event-B model that captures the features of the group protocol model. Next, a secrecy property is specified as an invariant of the resulting event-B model I, and a forward secrecy property is specified as an invariant of the refined event-B model. Messages can be defined as a set with an enumeration of all possible secret and known messages. The intruder initial knowledge, , is directly defined as variable or set in the event-B initialization list. Secret messages are defined similarly. Protocol initial constraints, such as and, are defined as properties that will be included in the invariant. Protocol join or leave events are defined as event-B operations that update the intruder’s knowledge and the set of secret messages, including the new generated key. Finally, the property is checked from the obtained global system specification using the event-B invariant checking in Rodin platform.

In

The event-B semantics is close to the protocol model semantics. This relationship is demonstrated by establishing a well-formed link between the semantics of both models. To achieve this link, we are interested in showing that if the invariant I holds for event-B system M, then the safety property must hold for the group protocol model. Formally,. In terms of equivalence between the two models, we can say that the event-B model M is an abstract model of the protocol model, with regards to the security property, if the property holds in the model, and the invariant I holds in the abstract model M. To illustrate this equivalence, we need to show that. Therefore, it is

enough to show that the invariant I, with regards to M, implies the safety property, with regard to.

To show that, we need to establish a well-formed link between event-B invariant and the safety property. We split this formal link into two parts: the first deals with the initialization, and the second deals with executing the events. For this, we need to relate messages in to variables in M by mapping public messages and secret messages to event-B sets and messages sets to event-B constants properties. This map relates the variable m over the set of messages directly to the variable v over event-B carrier sets and constants. The semantical correspondence between the variable m and the variable v is defined by this map.

Theorem 4.1. Secrecy Soundness.

A group protocol, G, satisfies its secrecy property, , if there is an equivalent abstract event-B model, M, that satisfies an event-B invariant, I, and implies the property. More formally, for a model G, we need to find an abstract model M where means that the event-B model M can be abstracted from the group protocol G. This abstraction will be defined later. Let, and be correct lemmas, then,

.

The proof is divided into two parts, in the first we assume that holds, then we prove the theorem based on that. In the next stage we prove each lemma separately and we identify the relation between G and M such that holds.

Proof. Given, , and, we can deduce

We establish the abstract relation between G and M such that holds, then we prove the lemma. The lemma is assumed to be correct in the event-B tool.

Definition 4.1. A group protocol model G, is abstracted to an event-B model, M under certain conditions and semantically correct map from G to M. is defined as follows:

For every component and condition in G there is an equivalent one in M. A protocol model is composed of, we map each component in G into an equivalent one in M.

Messages sets are mapped into an event-B variable by defining v over the set, and messages sets relations are mapped to event-B constants properties. is a function of. These relations include the predicates about sets that should always hold.

Messages generation conditions are mapped into events guards. These conditions include predicates that should hold prior to executing an event, like having the appropriate key to encrypt or decrypt a message.

The secrecy property, , is mapped into an event-B invariant, I. This map is defined in Lemma 4.1.

An event in is mapped into event R, an event, with a precondition condition, where , the message generated from executing the even, can be defined concretely using an event-B statement such as:

Name event =

ANY mWHERE condition THEN

This map defines the relation.

To show that, we need to establish a wellformed link between event-B invariant and the safety property. We split this formal link into two parts: the first deals with the initialization, and the second deals with executing the events. First we relate messages in to variables in M. In

We define the invariant I as, where is the invariant predicate under the initial conditions, and is the invariant predicate under executed events. Similarly, we define the safety property.

Proof. We define the well-formed conditions that guarantee the correctness of this lemma in two steps, we first show that. We identify the initial events and initial set of messages in under which the formula holds. Then we define the predicates P, I, G, and R presented in Lemmas 3.1 and 3.2 for the protocol model such that Lemma 4.1 holds.

The definition of the group key protocol must satisfy the initial soundness conditions: and , where is an initial event that can be applied on the intruder's initial set of messages. We choose to be the set of events that can be executed on.

We will define the constants property P and the initialization predicate for the model that will satisfy Lemmas 3.3 and 3.4. Then we define P, R, the predicate guards G, and the invariant I for the model that will satisfy Lemmas 3.1 and 3.2.

Case 1.

•

•

The message generation event is equivalent to the transition relation. This yields the formula which is exactly Lemma 3.3 considering that.

The invariant definition for the model is . We need to show that the invariant I holds for both and. Since the protocol is initially sound, then both and hold by the fact that and that the initial events cannot generate secret messages in S. If then. Therefore we can write , which corresponds to Lemma 3.3 considering that.

Case 2.

•

•

•

This message generation event is equivalent to the transition relation. Therefore, applying the predicates P, I, and G will lead to the relation R. We can write the formula which is equivalent to Lemma 3.1 considering that the relation R is equivalent to an existing event.

The validity of the invariant for the model is expressed by the validity of the predicates P, I, R, and G, where. This can be written as , which corresponds to Lemma 3.2.

Under these conditions, we guarantee that when the invariant holds in event-B model, the secrecy property definition holds for the group key protocol model. These predicates should be considered carefully when providing the event-B implementation. Properties that can be expressed as invariants are verified using the translation process and the event-B tool.

This completes the proof of Theorem 4.1. The major restriction on this method is that it can reason about the execution of a single protocol event, i.e., join or leave. However, this is enough to model and verify group secrecy when a member joins or leaves the group.

In event-B, refinement can be done with events or variables. In our case, the group protocol join or leave events have the same semantics in both secrecy and forward secrecy, therefore, it will have the same definition in both the abstract and refined event-B models, i.e.,. We use to represent join or leave events, which update the intruder’s set of knowledge, the variable v here. In the refined model, we will use the same relation, we call it, that will update the intruder’s set of knowledge, , in the refined model.

The correctness of forward secrecy, , with regards to the event-B concrete model is achieved through the correctness of the gluing invariant.

A group protocol, , satisfies its secrecy property, , if there is an equivalent event-B model, M, that satisfies an event-B invariant, I, and a refined event-B model that satisfies an event-B invariant I, and a gluing variable that implies in the existence of a relation.

Formally, given, , , and, then

.

Assuming, , and, we can deduce:

.

.

This way, we guarantee that once a refined event-B

model is verified against its invariant, then the group protocol model is verified against its forward secrecy property.

Event-B invariant checking cannot reason about backward secrecy because invariants cannot be used in a reverse manner, i.e., refining the intruder’s knowledge back in time. In backward secrecy the intruder is assumed to be an active user in the group while trying to discover older secret shares prior to his/her membership. Therefore, refinement of secrecy can only be used for forward secrecy. Based on this, key independence (collusion) cannot also be modeled in this method as is.

In this section, we apply the approach on a group key protocol that generates a key in a distrusted group. We show how the conditions defined for the correctness of the above model can be concretely applied on a real protocol. The intended secrecy property, along with its conditions, are efficiently defined and checked as event-B invariant.

The Tree-based Group Diffie-Hellman protocol (TGDH) is intended for secure key generation.

A group key can be computed from any members secret share and all blind keys on the co-path to the root. Blind keys are the siblings of the nodes on the key path. The members own secret share and all sibling blind keys on the path to the root enable a member to compute all intermediate keys on its key-path, including the root group key.

The group key is calculated by each member based on his/her key-path and blind keys. For instance, for a member M_{3} at node, the key-path is the set of messages. The set of blind keys ordered as they appear up to the root is

. The group key at the root is calculated directly using the two sets:

The protocol designers presented four types of security properties: group key secrecy, forward secrecy, backward secrecy, and key independence. The authors of [

We illustrate our method on a group protocol composed of three members, then we apply a join event for a fourth member.

join event takes place:

where the sets of messages, , , and.

Then, we show the same components after the join event of a new member with a new secret contribution. Note that group key secrecy has the same definition and should be valid always, before and after a join (or leave) event takes place.

The event-B model for the protocol components is described below. We describe the current status of the group by initializations appropriate sets for messages and keys. The secrecy property is defined as an invariant that combines a set of conditions to be satisfied at the initialization and after executing the event:. Some of the protocol characteristics can also be encoded within this invariant, such as. We also define an event to represent the protocol action (join/ leave).

The TGDH protocol components are defined within the event-B model. The group key has basically the same definition, and secrecy property is defined as an event-B invariant that contains, in addition to group key secrecy, certain conditions on messages sets to ensure the consistency of the map,

.

An event-B definition that captures the behavioral semantics of a join event which will result in updating the intruder’s set of knowledge is described as follows:

MACHINE M0 SEES P0

VARIABLES K GKey S pwn INVARIANTS inv1: K Key GKey Key S M inv2: pwn N × N K inv3: K ∩ S = GKey K EVENTS Initialisation begin

act1: M := {n_{1}, n_{2}, n_{3}, pwn(g, n_{1}), pwn(g, n_{2}), pwn(g, n_{3}), pwn(g, n_{1} * n_{2}), pwn(g, n_{2} * n_{3}), pwn(g, pwn(n_{1} * n_{2})), pwn(g, n_{3} * g(n_{1}, n_{2}))}

act2: K := {n_{i}, pwn(g, n_{i}), pwn(g, n_{1}), pwn(g, n_{2}), pwn(g, n_{3}), pwn(g, pwn(g, n_{1} * n_{2}))}

act2: Key := {pwn(g, n_{3} * pwn(g, n_{1} * n_{2}))}

act3: S := {n_{1}, n_{2}, n_{3}, pwn(g, n_{1} * n_{2}), pwn(g, n_{3} * pwn(g, (n_{1} * n_{2})))}

act4: GKey := {pwn(g, n_{3} * pwn(g, n_{1} * n_{2}))}

end Event join any n_{4}

where grd1: n_{4} M then

act5: M := M {n_{4}, pwn(g, n_{4}), pwn(g, n_{3} * n_{4}), pwn(g, pwn(g, n_{3} * n_{4}) * pwn(g, (n_{1} * n_{2})))}

act6: S := S {n_{4}, pwn(g, n_{3} * n_{4}), pwn(g, pwn(g, n_{3} * n_{4}) * pwn(g, (n_{1} * n_{2})))}

act7: GKey := pwn(g, pwn(g, n_{3} * n_{4}) * pwn(g, (n_{1} * n_{2})))

act8: Key := Key {GKey}

act8: K := K {n_{4}, pwn(g, pwn(g, n_{3} * n_{4}))}

Event IntEvnt any m1, m2 where grd1: m1 K m2 K then act1: K := K {pwn(m1, m2)}

END The intruder set of knowledge is modeled with K in the above model, and is initialized with the public set of knowledge. We assume the intruder has access to the knowledge of users leaving the group. Therefore, with the execution of each event, this knowledge is updated dynamically. The function pwn models the exponent operator used to calculate keys. After the join event is executed, the new key will be generated and added to that set of secret keys based on the contribution of the joined member, n_{4}, as follows:

For the verification of the invariants, we first consider the static case of key construction under the assumption that basic DH key construction (on tree leaf nodes) is correct. We then consider the dynamic case by applying events such as join and leave and verify the correctness of key construction for a bounded tree size and bounded number of events. The event-B invariant has been proven totally. The number of generated proof obligations are three, all proof obligations are discharged, and then the initial model of the group key protocol is validated. The event-B invariant, I, defined in the Rodin platform above, implies the group protocol secrecy semantically,. The event-B tool guarantees that. We have shown in the previous section that the group protocol G is mapped into an event-B model M. Therefore, we can conclude the correctness of the secrecy property for the protocol model G,.

The proposed solution allows us to verify the required property, however, one limitation of our approach is its applicability on bounded number of participants and protocol events, this issue will be addressed in the future work. Another limitation is due to the fact that we verify the property under the execution of a single event. However, this approach is sufficient for the target property, where key distribution is abstracted away because we are concerned only with modeling key construction but not key distribution or authentication property. Even though there are some limitations for the approach, event-B can be used in modeling specific protocols behaviors, like key construction, and tree-based protocol primitives can be modeled directly in event-B for safety properties verification.

We illustrate the method on a group protocol composed of four members, then we apply a leave event for a specific member.

In

Then, after member M_{4} joins the group, as shown in

The next step, is that we let member, who will be assumed to be dishonest later, leave the group, where a new secret share is generated as in

Finally,

The intruder knowledge, K, as viewed by a member monitoring the group from outside, before joins the group is defined as:

Then we show the set of messages when member joins the group:

Secrecy implies that the intruder monitoring the group should not be able to calculate the group key GroupKey_{d} (or any secret share or sub-key).

In forward secrecy, the set of messages K is refined with the knowledge gained by user while member in the group, and is denoted:

Group key protocol secrecy properties were defined as invariants in Rodin platform, the tool generates proof obligations that were successfully discharged using event-B proof control. The results achieved here are important because our method allows semi-automated verification of these properties under dynamic operation of the protocol. In addition, the method allows modeling protocols at different levels of abstraction, where the model can be further refined in order to include more details about the protocol operation.

In this paper, we provided invariant checking approach for group key secrecy and forward secrecy. We used event-B invariants to model and verify group key secrecy, then, on top of this, we used event-B refinement to model and verify forward secrecy. For this purpose, a formal link between the semantics of the group protocol model and event-B was established. The result was combining the event-B and group protocol model to be able to use specific features in event-B to model protocol actions and verify the required property. However, we restrict the group protocol model to be verified to certain conditions in order to guarantee the correctness of the method and the applicability of first-order logic theorem proving. This includes the number of participants, abstracting the exponentiation operator for Diffie-Hellman style protocols, and finally, applying a single protocol event.

We applied this approach on a group key protocol, the tree based Group Diffie-Hellman protocol and provided invariant checking for secrecy under the static and the dynamic case by applying a single event (join/leave). In contrast to our work, the authors of this protocol [

Even though our approach can model and verify only invariant properties, while liveness related properties cannot be modeled in our approach, we believe that invariant checking is adequate to model secrecy related properties. This is due to the target model and the verifycation tool, namely, event-B and Rodin platform. EventB supports only safety related properties which are modeled and verified as invariants. In addition, a limited class of liveness properties can be modeled using invariants, such as termination, while more general liveness properties are not supported yet in Event-B. Hoang and Abrial [

As future work, an interesting issue to be considered is modeling and verifying liveness security properties using event-B. In addition, an extension of the event-B based model to handle a parameterized number of participants shall be explored. It will also be interesting to investigate modeling backward secrecy and key independence using event-B.