Towards a Methodology for Formally Analyzing Federated Identity Management Systems

Abstract

The aim of this paper is to develop an appropriate methodology for formally analyzing federated identity management (FIM) systems. For this purpose, two different formal frameworks are considered; the first uses TLA+, a specification language for modeling complex industrial systems, whereas the second uses the Maude language, a more research-oriented approach. Using these frameworks, we first model an API Connector, developed in the context of an EU eIDAS project to facilitate the integration of Service Providers with the eIDAS Network. On the basis of the produced specifications we verify the aforementioned API Connector by model-checking an important security property. Finally, the two approaches are compared in terms of efficiency and accessibility based on a set of carefully selected criteria.

A ANNEX

1.1 A.1 Maude: Basic Syntax and Notation

In Maude, operators are functions taking zero or more arguments of some sort and returning a term of a specific sort [22]. Sorts are declared as $sort\ \langle Sort \rangle$, or $sorts\ \langle Sort{\text {-}}1 \rangle \ \dots \ \langle Sort{\text {-}}n \rangle \$ Subsorts can also be defined as $subsort\ \langle Sort{\text {-}}1 \rangle \ \dots \ \langle Sort{\text {-}}2 \rangle$. Variables are constrained to range over a particular sort and are declared as $var\ \langle VarName \rangle \ :\ \langle Sort \rangle$. Operators are declared as $op\ \langle OpName \rangle \ :\ \langle Sort{\text {-}}1 \rangle \ \dots \ \langle Sort{\text {-}}n \rangle \ \rightarrow \langle Sort \rangle$, while a constant is defined by an operator having no domain $op\ \langle OpName \rangle \ :\ \rightarrow \langle Sort \rangle$. The ground terms of our system are defined by function symbols. Ground terms denote the data values, and are build up by the data constructors which are declared as $op\ \langle OpName \rangle \ :\ \langle Sort{\text {-}}1 \rangle \ \dots \ \langle Sort{\text {-}}n \rangle \ \rightarrow \ \langle Sort \rangle \ [ctor]$. Equations define the declared functions and have the form $eq\ \langle Term{\text {-}}1 \rangle \ =\ \langle Term{\text {-}}2 \rangle$. A term is either a constant, or a variable, or the application of an operator to a list of argument terms. Data types as natural numbers, and Boolean values are defined as many-sorted equational specifications which consist in: a set of sorts, a set of function symbols (operators), and a set of equations defining the functions. Rewrite rules are declared as $rl\ [ \langle label \rangle ]\ :\ \langle Term{\text {-}}1 \rangle \ \Rightarrow \ \langle Term{\text {-}}2 \rangle$. If a rule is conditional it has the form $crl\ [\langle label \rangle ]\ :\ \langle Term{\text {-}}1 \rangle \Rightarrow \langle Term{\text {-}}2 \rangle \ if\ \langle Cond{\text {-}}1 \rangle \wedge \dots \wedge \langle Cond{\text {-}}n \rangle$.

A Maude specification is organized as a collection of modules, each of which constitutes a rewrite theory comprising a term language, equations, and rewrite rules⁷. A module is declared as $[mod\ \dots \ endmod]$, except if it does not contain rewrite rules, in which case it is called functional, and is declared as $[fmod\ \dots \ endfm]$⁸. Thus functional modules are included as a special case in system modules. To build a new module on the basis of an old one we write $protecting\ \langle MODULE{\text {-}}NAME \rangle$.

The overall system has the form of a module - usually named SYSTEM - build upon a number of other modules, whose rewrite rules are meant to define its concurrent evolution. States can be expressed as tuples of values $\langle a_{1}, a_{2}, b_{1}, b_{2} \rangle$, or as collections of observable values $(o_{1}[p_{1}]: a_{1})\ (o_{1}[p_{2}]: a_{2})\ (o_{2}[p_{1}]: b_{1})\ (o_{2}[p_{2}]: b_{2})$, where observable values are pairs of (parameterized) names and values. The initial state is usually defined in a separate module called $SYSTEM{\text {-}}INIT$ as an equation: $init\ =\ \langle initial state \rangle$. When Maude executes, it rewrites terms according to the given specifications. Rules are applied at “random”, and if an equation might be applied to a term, it will always be applied before a rewrite rule. The command search performs a breadth-first search to check whether a given state pattern can be reached from the initial state and has the form $search\ [n, m ]\ in\ \langle ModId \rangle \ :\ \langle Term{\text {-}}1 \rangle \Longrightarrow \langle Term{\text {-}}2 \rangle$. Where n and m state the number of desired solutions and the maximum depth of the search respectively, ModId is the module where the search is performed, and $\langle Term{\text {-}}1 \rangle ,\ \langle Term{\text {-}}2 \rangle$ the terms we wish to match. Whenever there exists a match from the left-hand-side argument to the right-hand-side argument the predicate $\Longrightarrow$ evaluates to true. After the creation of the system’s specification using the appropriate notation and syntax, we can employ Maude’s built-in search command to model-check the desired system properties.

1.2 A.2 TLA+: Basic Syntax and Notation

In TLA+ functions are closer in nature to hashes, or dictionaries, except that you can choose to programmatically determine the value from the key. More specifically, functions can be defined in two ways: either as $Function == [s \in S \mid \rightarrow eq]$, or as $Function[s \in S] == eq$, where eq can be any equation. An ordered n-tuple, declared as $\langle e_{1},\dots , e_{n}\rangle$, is a function with domain ${1, \ldots , n}$ that maps i to $e_{i}$. Records in TLA+ are functions (that is, hashes) specified as $[key \mid \rightarrow value]$, and we query them using either $[\text {``} key \text {''}]$, or .key. Note that instead of $key \mid \rightarrow value$, we can also write key : set, in which case instead of a record we get the set of all records having, for each given key, a value in the set.

Variables are of two types: rigid variables and flexible variables. Rigid variables are the well-known variables of predicate logic, which are here called constants (like the bound variables introduced by the constant operators). Flexible variables are simply called variables.

Non-constant operators include action and temporal operators. An action is a Boolean formula that may contain primed and unprimed variables. In an action an unprimed instance of a variable denotes its value in the current state, and a primed instance denotes its value in the next state. For action reasoning x and $x'$ can be considered to be completely unrelated variables. The action operators can be defined in terms of primed variables, i.e. $p'$ equals p with every variable x replaced by its primed version $x'$, $[A]_e$ equals $A \vee (e'= e)$, $<A>_e$ equals $A \wedge (e'\ne e)$, and UNCHANGED equals $e'= e$. Finally, some of the temporal operators are $\square F$ (F is always true), $\Diamond F$ (F is eventually true), and $F \leadsto G$ (F leads to G).

A TLA+ specification is organized as a collection of modules, each of which comprises a sequence of statements, where a statement is a declaration, definition, assumption, or theorem. A declaration statement adds to the module the declarations of constant and variable symbols, and has the form $CONSTANT\ Name1,\ Name2,\ Name3$ and $VARIABLES\ Name1,\ Name2,\ Name3$. A declared symbol is a “free parameter” of the module. A definition always defines a symbol to equal an expression containing only declared symbols, bound variables that are different from any symbols typed by the user, and built-in operators of TLA+. Symbols can also be defined to equal operators that take arguments. A module can contain assumptions of the form ASSUME exp, where exp stands for an expression which can contain symbols declared or defined anywhere in the module. A module can also contain theorems of the form $THEOREM\ P$, which assert that P can be proven using the module’s definitions and assumptions. Finally, one builds large hierarchical specifications by building a new module on the basis of old modules. One way of doing this is by using the EXTENDS statement at the beginning of the module i.e. $EXTENDS\ ModuleName$, which amounts to adding the declarations and definitions from an existing module to the current one.

In TLA+ an execution - or behaviour - of a system is modelled as a sequence of states, where an event is represented by a pair of consecutive states (a step). The overall system is represented as the set of behaviours describing all of its possible executions. Such a set is described in TLA+ by an initial condition specifying the possible starting states, and a next-state relation, specifying the possible steps. In other words, each possible system behaviour must begin with a state satisfying the initial condition and its every step must satisfy the next-state relation. Note that the next-state relation which consists of a finite number of next-state actions, specifies what steps may happen; it does not specify what steps, if any, must happen. Thus, the necessary steps for the verification of a system using TLC (a model-checker and simulator of executable TLA+ specifications) are the following: first the system’s specification is written using the language’s specific notation and syntax. Then a model is created, for which we specify the initial condition, the next relation, and the values⁹ of declared constants. Finally, after we have checked the type-correctness invariant (usually named TypeOK), we can proceed to check the invariance of further conditions¹⁰ (formulas which are required to be true in every reachable state), or the validity of desired properties (temporal formulas required to be true in every possible behaviour). Note that the execution time and space grow exponentially with the size of the model.