Intrusion-tolerant fine-grained authorization for Internet applications

Intrusion-tolerant fine-grained authorization for Internet applications

V. Nicomette ^{a,b, *} , D. Powell ^a,b , Y. Deswarte ^a,b , N. Abghour ^c , C. Zanon ^a,b

a

CNRS, LAAS, 7 Avenue du Colonel Roche, F-31077 Toulouse, France

b

Université de Toulouse; UPS, INSA, INP, ISAE; LAAS; F-31077 Toulouse, France

c

Université Hassan II Faculté des Sciences An Chock, Département de Mathématiques et Informatique, BP 5366 Maarif Casablanca 20100, Morocco

a r t i c l e i n f o

Article history:

Received 15 October 2009

Received in revised form 2 April 2010 Accepted 5 May 2010

Available online 13 May 2010

Keywords:

Authorization scheme Fined-grained Delegation Intrusion-tolerance

a b s t r a c t

This paper presents the architecture of an authorization service proposed for composite operations involving many Internet partners. The main contributions of this paper are: (1) a scheme for access con- trol systematically applied at the fine-grained level of each elementary operation, (2) a novel proof of authorization concept and flexible authorization delegation technique, and (3) the design and proof- of-concept implementation of an intrusion-tolerant prototype of the authorization architecture. The architecture is based on two component types: an authorization server and a set of reference monitors.

The authorization server is in charge of distributing proofs of authorization for composite operations in the system. On each site involved in the execution of the composite operation, a local reference monitor is in charge of checking the validity of the proofs of authorization used for each elementary operation. The paper presents the overall design of the authorization service. It also includes a brief description of the prototype that was developed as well as performance measures.

Ó 2010 Elsevier B.V. All rights reserved.

1. Introduction

Authentication and authorization are key issues in computer security. The authentication process provides a way for a user to prove his identity (typically by presenting a valid username and password) while the authorization process consists in determining whether a user has permission to execute given operations in the system. This paper deals with authorization. While it is not a sim- ple issue in standalone systems, it really becomes intricate when one considers distributed applications and particularly applica- tions distributed over the Internet.

Most protection models are based on the notion of a reference monitor [1] that controls all interactions in the system to check whether each access is authorized or denied, using an access matrix that stores all the access rights of the system. If we consider applications distributed across the Internet, we can imagine a di- rect application of the standalone system paradigm by using a cen- tral reference monitor located on one host of the distributed system. This reference monitor would check all interactions in the whole distributed system. An implementation of this paradigm has been proposed in [2]. A major drawback of this approach is

obviously the fact that security of the entire system relies on just one machine, which is thus a single point of failure. Even if the cen- tral reference monitor were to be implemented as a fault- and intrusion-tolerant server running on several separately adminis- tered machines, it would still be a major bottleneck regarding system performance. Another possible solution can be found in the Red Book [3]. In this approach, a local reference monitor in each site of the distributed system checks all the accesses from remote entities to local entities. The local reference monitor is part of the site’s Trusted Computing Base (TCB) and each TCB trusts all the other TCBs of the whole system: when an access from a remote entity is made to a local entity, the local TCB trusts the remote TCB to correctly supply the remote entity’s identity, which is used for the verification of the access rights. Thus, in this approach, if any of the TCBs is corrupted, the security of the whole system is compromised.

Our first objective was thus to design an authorization scheme that is a trade-off between totally centralized and totally distrib- uted systems and that has none of their drawbacks.

Today, most Internet applications are based on the client–server model. This model is not rich enough to cope with composite oper- ations involving more than two participants. For example, an elec- tronic commerce transaction typically requires the cooperation of a customer, a merchant, a credit card company, a bank, a delivery company, etc. Each of these participants has different interests, and may thus distrust the other participants. Moreover, in this model, typically, the server distrusts clients, and grants each client access 1383-7621/$ - see front matter Ó 2010 Elsevier B.V. All rights reserved.

doi:10.1016/j.sysarc.2010.05.005

* Corresponding author at: CNRS, LAAS, 7 Avenue du Colonel Roche, F-31077 Toulouse, France.

E-mail addresses: nicomett@laas.fr (V. Nicomette), dpowell@laas.fr (D. Powell), deswarte@laas.fr (Y. Deswarte), nabghour@fsac.ac.ma (N. Abghour), czanon@laas.fr (C. Zanon).

Contents lists available at ScienceDirect

Journal of Systems Architecture

j o u r n a l h o m e p a g e : w w w . e l s e v i e r . c o m / l o c a t e / s y s a r c

rights according to the client’s identity. This enables the server to record a lot of personal information about clients: identity, usual IP address, postal address, credit card number, shopping habits, etc. Such a model is thus necessarily privacy intrusive.

Our second objective was thus to design an authorization scheme that is able to distribute proofs of authorization to the par- ticipants of a composite operation whilst enforcing the ‘‘least priv- ilege principle”: each participant should be granted the minimum set of proofs of authorization necessary to execute the composite operation. For that purpose, our authorization scheme defines a new proof of authorization concept and an authorization delega- tion scheme that is more flexible that the usual ‘‘proxy scheme”.

The paper is organised as follows. Section 2 presents the design of the authorization scheme and the security properties of the main entities. In Section 3, we give the definitions of the different proofs of authorization that are used in our scheme and discuss our delegation scheme. Sections 4 and 5 give a detailed presentation of the two main entities of our scheme: the authorization server and the local reference monitor. Section 6 gives an overview of a proto- type implementation of the authorization service. Some perfor- mance measures are also provided. Finally, Section 7 presents related work and Section 8 draws conclusions and proposes future work.

2. Design of the authorization service

This section gives a global presentation of our authorization scheme and the security properties required by the different enti- ties that compose the authorization service.

2.1. Architecture

The authorization scheme aims to ensure that each participant is granted the rights it needs to execute its task, while only distrib- uting the information that is strictly necessary, i.e., a proof that the task is authorized and the parameters authorized for this execu- tion, without unnecessary information such as the identities of other participants. The scheme is based on two levels of protection:

An authorization server, which is in charge of granting or deny- ing rights for composite operations involving several partici- pants in a given realm; if a composite operation is authorized, the authorization server distributes proofs of authorization (see Section 3) for all the elementary operations that are needed to carry it out. This authorization server must be built in such a way that it is not a single point of failure.

A local reference monitor on each participating host, which is responsible for fine-grained authorization of atomic operations accessing local resources and objects, according to the proofs of authorization that accompany each request. The authorization to execute an atomic operation is represented by a capability issued by the authorization server and checked by a local refer- ence monitor. To enforce hack-proofing of such reference mon- itors on off-the-shelf computers connected to the Internet, critical parts of the reference monitor must be implemented in tamperproof hardware (see Section 6 for an example with JavaCards).

This two-level architecture (see Fig. 1) provides:

simplicity of administration, since only the rights for composite operations need to be assigned by the security administrators of the realm;

fine grain protection, since authorization is checked at each exe- cution of an atomic operation.

It should also be noted that this approach is more capable of preserving privacy than the usual client–server approach: in the client–server model, the server grants or denies a client’s access according to the identity of the client, which has to be recorded to- gether with other information to be used as evidence in case of dis- pute. Much more personal information is thus recorded than really needed. With the more flexible authorization scheme we propose, a composite operation is authorized if the corresponding permission is presented, which, by itself, discloses no personal information. Only the personal information really necessary for execution of the composite operation needs to be disclosed (appli- cation of the ‘‘need-to-know” principle to privacy).

method invocation authorization request

p4 ps1

f3 fs2

... ...

u

Site Site

Security Security

Site Security

Reference Monitor

Authorization Server

Monitor Reference Monitor

tamperproof hardware Reference

Fig. 1. Authorization architecture.

2.2. Security properties

The security of the overall system is ensured by the collabora- tion between the authorization server and the local reference mon- itors. We present in this section the security properties required for each of these two entities.

2.2.1. Security properties of the authorization server

The authorization server is in charge of creating all the proofs of authorization that allow objects in the system to execute opera- tions. As a consequence, the failure of the authorization server would compromise the security of the entire system (i.e., the security of all the applications of the system). Thus, the following security properties need to be enforced with respect to the autho- rization server:

AS1 : The authorization server generates only valid proofs of authorization (safety).

AS2 : The authorization server eventually generates proofs of authorization (liveness).

2.2.2. Security properties of the reference monitor

Our authorization scheme is intended for Internet applications, i.e., applications that require the cooperation of objects residing on geographically distributed hosts. Hosts may fail accidentally or may be maliciously compromised. In particular, we consider that each host is locally administered by a person who has complete control over that host but who is not necessarily trustworthy. An administrator does not necessarily trust the administrators of the other participating hosts, so there is no mutual trust between hosts supporting the objects involved in a distributed application. We re- fer to failing or compromised hosts as faulty hosts.

However, even if some hosts may be faulty, we want the follow- ing properties to be enforced:

RM1 : Only authorized operations will be executed on a non- faulty host (safety).

RM2 : If an authorized operation invocation is received by a non- faulty host, the invocation will be acknowledged and the operation will eventually be executed (liveness).

RM3 : A faulty host cannot generate a valid acknowledgment for an operation authorized for a different host (safety).

We show in Sections 4 and 5 how we design the authorization server and the reference monitor in such a way that these security properties are enforced.

3. Authorization proofs

3.1. Concepts and definitions

We build on the generic authorization scheme for distributed object systems that we proposed in [4]. In that scheme, an applica- tion is considered to be composed of objects that interact through method invocations. Execution can be viewed at two levels of abstraction: atomic operations and composite operations. An atomic operation is simply the execution of one method of one ob- ject. A composite operation corresponds to the coordinated execu- tion of several atomic operations towards a common goal. For instance, printing file F3 on printer P4 is a composite operation involving the execution of a particular method of the spooler object attached to P4, which itself has to request the execution of a par- ticular method of the file server object managing F3, etc.

Details on how the authorization server checks if a composite operation request is to be granted or denied are given in [5] and [6]. We give a brief description here and an example.

3.1.1. Symbolic rights

A request from object O to run a composite operation is autho- rized or denied by the authorization server according to symbolic rights rules applied to symbolic rights stored in an access control matrix. A symbolic right is a high-level right that is used in order to authorize the execution of a composite operation in the system (e.g., the right to print file f on any printer of the system is a sym- bolic right). In general, several symbolic rights are needed to authorize the realization of a single composite operation. In order to authorize a composite operation, the authorization server eval- uates symbolic rights rules. A symbolic rights rule describes the set of all symbolic rights that must be found in the access matrix in or- der to authorize the realization of a composite operation.

For example, in the access matrix described by Table 1, the first row represents symbolic rights that are granted to subject S. The symbolic right PF(this,PRINTER) in column f

means that S is authorized to print file f

on any printer of the system (any in- stance of class PRINTER). In the same way, PF(FILE,this) in col- umn p

means that S is authorized to print any file of the system on printer p

.

The last rows of the access matrix represent method rights that print server ps

and file server fs

respectively have on printer p

and file f

: ps

is authorized to access method print of p

and fs

is authorized to access methods read and write of f

.

The following symbolic right rule:

PF e;f ðf; pÞ; PF e;p ðf; pÞ CopðprintfileÞðe; f; pÞ

means that in order to authorize an entity e to execute the compos- ite operation ‘‘printing file f on printer p”, it must be checked, via the access matrix, that the entity holds the following symbolic rights:

PF for file f on a set of printers that includes p.

PF on printer p for a set of files that includes f.

3.1.2. Permissions

If the request is authorized, proofs of authorization are created by the authorization server for all the operations composing the composite operation. These proofs of authorization are delivered in the form of a list of permissions for O to perform operations

op

, . . ., op

, and the list is signed by the authorization server

(AS) to prevent forgery:

ðfPermðO; op ₁ Þ ; . . . ; PermðO; op _n ÞgÞ SK

ð1Þ The notion of a composite operation is recursive: the execution of a composite operation corresponds to the execution of a set of operations, each of them being either an atomic operation or a (nested) composite operation.

Atomic operations: The permission for an atomic operation (i.e., a method execution) contains the identification of the object O authorized to invoke the method, the identification of the

Table 1

Example of access matrix.

ps1 fs2 f3 p4

S PF(this,PRINTER) PF(FILE,this)

ps1 print

fs2 read, write

authorized method O

:m, some constraints parC on the invocation parameters, a capability for O to invoke O

:m with these constraints, and optionally a voucher (defined below):

PermðO; O ⁰ :mÞ ¼ O; O ⁰ :mðparCÞ; CapðO; O ⁰ :mðparCÞÞ½; VouchðO ⁰ :mÞ ð2Þ The capability CapðO; O

:mðparCÞÞ is a proof that object O is authorized to invoke method m of object O

with some constraints parC on the invocation parameters. These constraints can be simply the values of the authorized invocation parameters, or relations on the values of the parameters, such as a maximum authorized value.

When O invokes O

:m, the invocation must be accompanied by the capability, which will be checked by the local reference monitor lo- cated on the host of O

.

If, during its execution, O

:m needs to invoke other operations (atomic or composite), it will need proofs of authorization for these invocations. In that case, PermðO; O

:mÞ contains a voucher, which is a sealed list of permissions for O

to invoke op

; . . . ; op

: VouchðO ⁰ :mÞ ¼ ðfPermðO ⁰ ; op ₁ Þ ; . . . ; PermðO ⁰ ; op _n ÞgÞ SK

ð3Þ

VouchðO

:mÞ will be transmitted by O to O

when O invokes

O

:m, in the same way as the list of permissions was transmitted

by the authorization server to O as a reply to the request by O for a composite operation. The voucher is created by the authoriza- tion server during the process of permission generation, and is signed by the authorization server to prevent forgery. Note that the proofs of authorization represented by the voucher cannot be used directly by O. They can only be delegated by O to O

in order to execute m on behalf of O.

Composite operations: The permission for a (nested) composite operation contains the identification of the object O authorized to invoke the composite operation, the identification of the com- posite operation cop, some constraints parC on the invocation parameters, and a token for O to invoke cop with these constraints:

PermðO; copÞ ¼ fO; copðparCÞ; TokenðO; copðparCÞÞg ð4Þ TokenðO; copðparCÞÞ is a proof that object O is authorized to car- ry out the composite operation cop with constraints parC on the invocation parameters. With this token, object O can request from the authorization server all the proofs of authorization needed to perform cop.

3.2. Discussion 3.2.1. On tokens

Tokens are not strictly necessary. Since a token is a proof of authorization to be presented to the authorization server to gener- ate permissions, it would have been possible for the authorization server to generate these permissions in the first place and distrib- ute them instead of the token. But tokens are useful for flexibility and efficiency:

Flexibility: without tokens, when the authorization server receives a request for a composite operation, it would have to evaluate the complete invocation tree for all possible execu- tions of the composite operation, and to generate all the capa- bilities for all possible atomic operations. In this case, cycles must be prevented in the invocation sequences. On the con- trary, tokens enable dynamic evaluation of authorization during execution.

Efficiency: without tokens, the authorization server would have to generate all capabilities for all possible atomic operations in all possible executions of the composite operation. Many of these capabilities might not be used in the real composite oper- ation execution, so the authorization server would have wasted

its time in generating them. Moreover, this means that the objects would receive more capabilities than needed, in contra- diction with the least privilege principle. On the contrary, the authorization server will have only to evaluate at run time the tokens corresponding to composite operations that are really executed.

3.2.2. On delegation

The voucher-based delegation scheme presented above is more flexible than the usual ‘‘proxy” scheme [7–10], by which an object transmits to another object some of its access rights for this dele- gated object to execute operations on behalf of the delegating ob- ject. Our scheme also adheres more closely to the least privilege principle, since it helps to reduce the privilege needed to perform delegated operations. For instance, if an object O is authorized to print a file, it has to delegate a read-right to the spooler object for the latter to be able to read the file to be printed. To delegate this read-right, with the proxy scheme, O must possess this read- right; and thus O could misuse this right by making copies of the file and distributing them. Clearly, the read-right is a privilege much higher than a simple print-right. In our scheme, if O is autho- rized to print a file, O will receive a capability to call the spooler and a voucher for the spooler to read the file. The voucher, by itself, cannot be used by O. With the provided capability, O can only in- voke the spooler and transmit the voucher to the spooler. The spooler can then use the capability contained within the voucher to read the file. Thus O can have the right to print a file without being authorized to read it.

Let us also note that all the required permissions do not neces- sarily have to be transmitted in a voucher (or even in a reply to a request for composite operation authorization). The invoked object can have its own rights, stored as symbolic rights in the authoriza- tion server access control matrix. Thus, a composite operation cop can be launched by O

on behalf of O (i.e., by running a method O

:m invoked by O) without O delivering a voucher for cop, if O

is autho- rized to perform cop by itself.

3.2.3. On transient objects

Only persistent objects are known by the authorization server AS. Transient objects, such as buffers or temporary files, created for the execution of a single composite operation are not known by AS, and thus AS cannot generate capabilities for such objects.

The capabilities for transient objects are completely managed by the reference monitor associated with that host (a transient object capability can be ciphered by a persistent symmetric key of the lo- cal reference monitor; this symmetric key is never transmitted outside the reference monitor). A transient object can be created dynamically by another object, which then receives from the refer- ence monitor all capabilities for this object and it can transmit these capabilities to other local objects at method invocation. Tran- sient object capabilities cannot be transmitted to remote objects.

4. Authorization server

Since only composite operations are managed by the authoriza- tion server, system security is relatively easy to manage: the appli- cation security administrators of the realm have just to assign the rights to execute composite operations, they do not have to con- sider all the elementary rights to invoke object methods. Moreover, since only one request has to be checked by the authorization ser- ver for each composite operation, the communication overhead scales well.

The authorization server is a trusted third party (TTP), which

could be a single point of failure, both in case of accidental fail-

ure, or in case of successful intrusion (including by a malicious

administrator). To prevent this, the authorization server can be made tolerant to accidental faults and intrusions [6]. A fault and intrusion-tolerant authorization server is made of diverse security sites, administered by independent persons, so that acci- dental faults and malicious intrusions can be tolerated without degrading the service, as long as only a minority of security sites are affected.

To tolerate the failure of one or a small number of the sites composing the authorization server, several protocols specified in [11–14], are used (cf. Fig. 2):

Atomic multicast: the request sent by an object to the authoriza- tion server is distributed to all the sites composing the authori- zation server. The multicast communication is reliable in the sense that all requests (sent by a non-faulty site) are received correctly by all non-faulty receiving sites and atomic in the sense that non-faulty receiving sites receive identical message sets in the same order. This condition is useful for achieving mutual agreement.

Mutual agreement: all non-faulty sites agree on the decision to grant or deny the authorization corresponding to a given request. This guarantees a correct decision as long as there are at most f faulty sites, where the number f depends on the failure mode assumptions. If we assume that the faulty sites are fail- silent (e.g., thanks to dedicated hardware as presented in [15]), then f must be such that ðn > 2f Þ where n is the total number of sites. If we do not make any assumption on the fail- ure mode of the sites (e.g., by admitting that a security site might have a corrupt administrator), then Byzantine behavior needs to be taken into account and, under these hypotheses, we have the relationship ðn > 3fÞ. We use the ABBA protocol [11], which is a randomized Byzantine agreement protocol that terminates in a constant expected number of asynchronous rounds, except with negligibly small probability.

Threshold signature: the capabilities, tokens and vouchers are globally signed by the authorization server, using a threshold signature scheme. For that, each of the sites composing the authorization server generates a signature share (based on its own private key share) so that if at least t valid signature shares are available (t being the threshold), it is possible to combine these shares to generate a unique signature that can be verified with a global public key. This guarantees that if a capability (or a token, or a voucher) has a correct signature, the corresponding operation is indeed authorized (the signed capability cannot be

forged, even by conspiracy between f faulty sites, as long as f is strictly less than the threshold t).

This set of protocols allows the safety property AS1 (cf. Section 2.2.1) to be enforced. Indeed, thanks to the protocols presented above, we can tolerate a number f of faulty sites: f depends on the assumption regarding the failure mode of the faulty sites as ex- plained above (n > 2f or n > 3f) and, furthermore, f must be less than t. Under the assumption that no more than f sites are faulty, the authorization server cannot generate false authorization proofs (property AS1), because the mutual agreement protocol guarantees a correct decision and because the threshold signature scheme guarantees a correct signature of the proofs of authorization.

Regarding the liveness property AS2, fault prevention and toler- ance mechanisms must be used so that no network denial of ser- vice attack can succeed and no network failure can occur. These mechanisms are out of the scope of this paper. However, some hints on how this might be done are as follows. Network failure can be prevented by using network redundancy and reconfigura- tion, in such a way that the network stays operational even during successful sub-network attacks. Regarding denial of service at- tacks, some research work has been done to identify malicious net- work flows and propose mechanisms and methods to tolerate them [34]. Even in the absence of network attacks, the authoriza- tion server must be dimensioned so that it can answer authoriza- tion requests in an efficient way for a particular realm. As a consequence, a precise evaluation of the necessary processing and networking resources must be done so that the authorization server does not suffer from unavailability. As presented in Section 6.3.1, the performance measures that we obtained for one proto- type implementation lead us to believe that this is quite realistic.

The dialogue between an object initiating a composite opera- tion and the authorization server is typically as follows. Object O asks the authorization server for the authorization to carry out the composite operation. If the authorization is granted by a major- ity of the sites composing the authorization server, each non-faulty site of the authorization server returns to O the same list of permis- sions for atomic operations, signed by its signature share. If Oreceives at least t copies of the list, Ocan rebuild the global autho- rization server signature for the list:

ðfPermðO; O 1 :m 1 Þ; . . . ; PermðO; O n :m n ÞgÞ SK

ð5Þ Each of these permissions contains a capability CapðO; O

:m

ðparCÞÞ or a token.

Security Security Authorization Server

Site

...

Site Security

hardware tamperproof Monitor

Reference threshold signature

mutual agreement atomic multicast transmission Site

Fig. 2. Protocols of the authorization server.

To prevent capability forgery or abuse, each one is ciphered

with the public key PK

of the host where O

is located, and signed by the global private key SK

of the authorization server AS:

CapðO; O i :m i ðparCÞÞ ¼ ððO; O i :m i ; parC; nonceÞ _PK

hðOiÞ

Þ SK

ð6Þ

The nonce is used to prove the freshness of the capability and pre- vent replay.

If the capability is accompanied by a voucher, this voucher con- tains a set of permissions needed by O

to execute m

on behalf of O.

The voucher itself is signed by the global private key SK

of the authorization server:

VouchðO i :m i Þ ¼ ðfPermðO ⁰ ; op ₁ Þ; . . . ; PermðO ⁰ ; p _n ÞgÞ _SK

ð7Þ

5. Reference monitor

There is a local reference monitor on each participating host.

The reference monitor is responsible for granting or denying atom- ic operations (i.e., local object method invocations), according to capabilities generated by the authorization server (or by the refer- ence monitor itself, for transient local objects). In the context of wide-area networks (such as the Internet), the implementation of such a reference monitor is quite complex since, due to the heter- ogeneity of connected hosts, it would be necessary to develop one version of the reference monitor for each kind of host. Moreover, since the hosts are not under the control of a global authority, there is no way to ensure that each host is running a genuine reference monitor, or the same version thereof.

The reference monitor host is thus composed into two parts: a tamperproof hardware-resident part and a host-resident part (called dispatcher). The dispatcher is a local object, run by each host, that is in charge of controlling all invocations by/to local ob- jects. To improve application transparency, the dispatcher also stores and manages the permissions that have been granted to all objects located on the host. For instance, when an object in- vokes another object, the dispatcher checks the permissions belonging to the invoking object to verify it has indeed a capability to carry out this invocation. It inserts the capability and (option- ally) the voucher into the invocation message, and sends the whole message to the destination dispatcher, which will then check the capability and store the permissions included in the voucher for the invoked object.

The dispatcher has the responsibility of deciding whether or not to authorize the invocation of particular methods on particular ob- jects on the local host by asking the tamperproof hardware part of the reference monitor to check that the corresponding capabilities are present and valid (through signature verification routines).

These checks represent the central part of the authorization scheme, and thus have to be protected as strongly as possible, which is why they must be implemented on tamperproof hard- ware. Note that, any software, even that within an operating sys- tem, can be copied and modified by a malicious user who possesses all privileges on a local host. In particular, on the Inter- net, any hacker can easily have these privileges on his own com- puter! With capability checks run on truly tamperproof hardware, we can be confident that any remote request is genuine (if the capability is correct), and that a genuine request can only be executed on the host for which the capability is valid. The hacker’s

privilege on his host gives him no privilege outside that host as long as he cannot hack the tamperproof hardware.

A private/public key pair associated to each host is generated and stored on its tamperproof hardware. The public key of the authorization server is also stored on this tamperproof hardware.

The public keys are stored on tamperproof hardware for integrity reasons, to prevent attacks that would modify these keys. The host’s private key is generated and stored on tamperproof hard- ware for confidentiality reasons: this private key never leaves the tamperproof hardware, it cannot neither be read nor modified.

Each capability generated by the authorization server is ciphered with the public key of the host where the invoked object resides and then signed with the private key of the authorization server.

These techniques allow the property RM1 (cf. Section 2.2.2) to be implemented: on a non-faulty host, if the capability is not cor- rectly ciphered and signed, the corresponding operation will not be executed. We trust the reference monitor to correctly check the capabilities. We think it is reasonable to trust the reference moni- tor because we trust the code and data that are embedded in the tamperproof hardware. Furthermore, a faulty host cannot generate false permissions for other hosts because these permissions must be signed by the private key of the authorization server.

An acknowledgement mechanism is used to prevent a faulty host from impersonating a non-faulty host without being detected:

each time a proof of authorization is received by a host, the latter returns an acknowledgement signed with its private key to the re- quester. This acknowledgment is accompanied by a certificate gen- erated by the authorization server. If the acknowledgment is received from a non-faulty host, the requester can verify its valid- ity (property RM2). If a faulty host tries to impersonate a non- faulty host by intercepting all the messages for this non-faulty host, it cannot send this acknowledgement because it cannot ci- pher it with the private key of the non-faulty host (this key is never transmitted outside of the tamperproof hardware). As a conse- quence, even if this faulty host intercepts messages for the non- faulty host in such a way that the non-faulty host no longer receives them (denial of service attack), the attack will be detected because the requester will not receive correct acknowledgements.

This protection mechanism ensures property RM3 (cf. Section 2.2.2) and is also useful against network denial of service attacks or net- work failures. We can rely on this acknowledgment mechanism because we trust tamperproof hardware not to reveal the crypto- graphic keys. We trust it not to reveal the keys because we con- sider that accessing data stored on this tamperproof hardware is sufficiently difficult.

Let us emphasize the following point: the mechanisms pre- sented are not sufficient to guarantee the correct behaviour of a complete application. If a host is corrupted, the local processes can do anything locally, and thus can totally change their behav- iour with respect to the whole application. They can decide to in- voke operations on local objects that do not form part of the composite operation, or to invoke constantly the same method of the same local object, or not to invoke necessary operations on ob- jects located on other hosts. The mechanisms we implement aim to enforce the security policy of the system and cannot guarantee that the behaviour of each process is correct as regards the application it is part of. Other mechanisms such as object replication are needed to deal with these problems. The only information that is managed by our authorization scheme (authorization server and reference monitors) is authorization information and our mecha- nisms only deal with this information. In summary, the authoriza- tion mechanisms guarantee that only authorized operations will be executed on a non-faulty host and guarantee that a faulty host cannot prevent other non-faulty hosts from operating correctly.

Furthermore, the tamperproof hardware used to carry out crypto- graphic verification allows Sybil attacks to be prevented.

1

A capability is the only proof of authorization that needs to be ciphered and

signed; tokens are only signed, because the knowledge of their contents cannot give

any authorization privilege. Nevertheless, it would also be useful to cipher (with the

reference monitor’s public key) the lists of permissions and the vouchers, if the

knowledge of their contents is considered a breach of privacy.

6. Prototype: an implementation example

In this prototype, we chose to implement all the objects of a complete distributed application in Java. Invocation between ob- jects are carried out through Java RMIs (Remote Method Invoca- tions). The tamperproof hardware-resident part of the reference monitor is a JavaCard.

6.1. Cryptographic keys

Several cryptographic keys are stored in the JavaCard:

The realm public key, that we note PK

. This key is associated with the realm private key SK

, which is not stored in the Java- Card. SK

is used to sign realm-compliant code.

A private/public key pair specific to JavaCard j, that we note SK

, PK

.

The authorization server public key, PK

(this key is associated with the private key shares of the authorization sites, using a threshold signature algorithm, see Section 4).

The secret symmetric key K

used to cipher the capabilities for local transient objects.

6.2. Capability verification

A distributed application in the context of a realm is executed by means of method invocations between realm objects located on realm-compliant hosts. The realm object codes are signed off- line by the global realm private key SK

, and this signature is checked by the local JVM of the realm host by using the corre- sponding public key PK

, which can be read on the JavaCard by the JVM. The invocation parameters and returned values are thus exchanged between objects by passing messages through these Java RMIs.

Each capability is ciphered by the public key PK

of the JavaCard of the host where the invoked object is located and signed by the private key SK

of the authorization server. Capability verification is thus done in three steps: (1) the JavaCard checks the signature of the capability by using the authorization server public key PK

; (2) the JavaCard deciphers the capability with its own private key SK

; (3) the JavaCard verifies that the invocation is compatible with the capability contents (identity of the invoker, identity of the invoked method including the invoked object identity, compatibility of the invocation parameters with the parameter constraints included in the capability).

As explained in Section 3, a capability is generally accompanied by a voucher, which contains the permissions needed for the in- voked method to be authorized to invoke other operations.

A permission can be a capability to invoke an object method or a token to initiate a composite operation. If the permission is a capa- bility, this capability is ciphered by the public key of the JavaCard associated with the host on which the invoked object resides and will be checked by the corresponding JavaCard (step 3 of Fig. 3).

If the permission is an authorization to carry out a composite oper- ation, the token is presented to the authorization server as a proof that the object is authorized to carry out that operation (step 3 of Fig. 4). The authorization server simply checks the validity of the token and then delivers the corresponding permissions to the object.

6.3. Proof-of-concept implementation

We implemented an experimental prototype of our approach and carried some performance measurements with the aim of identifying potential bottlenecks in the security mechanisms.

The authorization server of our prototype is composed of four security sites, configured to tolerate a single Byzantine fault (i.e., n = 4, f = 1). The equipment we had available to implement the ser- ver consisted of two Dell desktops (with Intel Xeon and Core2 Duo processors, and 2 and 6 Gb of RAM respectively), and two MacBook laptops (both with Intel Core2 Duo processors and 2 Gb of RAM).

These four machines communicate through a 100 Mbps network.

O’

. This capability is verified by the reference monitor of the host O’

2. The corresponding method of is invoked once the capability O

O message

1

2

3

3. The voucher contains the capability for to invoke a method of 1. An invocation message carrying a capability and a voucher

PKm, PKas SKj,PKj, Ki

is received by the local reference monitor

authorizing this access has been certified by the Java Card O

O’

Java Card

of when invokes the corresponding method of O O’

Reference Monitor

Java Card Reference

Monitor

Fig. 3. Example of a voucher containing a capability on a remote object.

2

A previous version of this prototype was implemented in the context of the

MAFTIA project (European project IST 1999-11583: Malicious and Accidental Fault

Tolerance for Internet Applications).

The application scenario we chose was drawn from healthcare and is described in detail in [17].

6.3.1. Authorization server performance

We ran an experiment to gauge the performance of the autho- rization server in the following situation. Our experiment consid- ers three main operations:

1. Authentication.

2. Authorization for a composite operation. This requires the gen- eration of two proofs of authorization: a capability C

and a voucher V

. Voucher V

is itself composed of a capability C

and another voucher V

, which is in turn composed of a capabil- ity C

and a token T. The generation of these proofs of authori- zation thus requires three ciphering operations (for C

, C

and C

) and seven threshold signature operations (for C

, C

, C

, V

, V

, T and the whole set of permissions).

3. Token handling. This requires the generation of two proofs of authorization: a capability C

and a voucher V

, with voucher V

composed of a single capability C

The generation of these proofs of authorization thus requires two ciphering operations (for C

and C

) and four threshold signature operations (for C

, C

, V

and the whole set of permissions).

We measured the real time and CPU time (on a single security site) required by the authorization server to:

authenticate a user or a site;

respond to an authorization request (measured from the recep- tion of the request until the complete generation of all the cor- responding proofs of authorization: capabilities, tokens and vouchers);

generate the proofs of authorization associated with a single token.

The results are summarized in Table 2:

To analyze these performance figures, we measured the time for the different functions of the AS. Fig. 5 shows the results of these measures.

The authentication process requires two executions of the con- sensus protocol. One is executed to check the validity of the certif- icate presented by the host making an authorization request, and the other is executed to check the validity of the challenge used for the authentication. We observe on this figure that 99% of the authentication duration is the time needed to run these two con- sensus protocols. The remaining time is dedicated to the local ver- ification of the certificate (before the consensus protocol) and the storage of the public key of the host.

Regarding the authorization duration, we observe once again that two thirds of the duration are due to the consensus algorithms, the remaining third being the generation of the proofs of authorization.

The real time required for the token handling is slightly less than the real time required for authorization handling (cf. Table 2) because fewer proofs of authorization are generated.

This performance is quite acceptable but could be improved by using some specialized cryptographic hardware (e.g., [18]). From these measures, we can easily affirm that, by using such crypto- graphic hardware, the performance cost for these security mecha- nisms would be less than 1s of CPU time, which is totally acceptable for a complex transaction distributed over the Internet.

6.3.2. Reference monitor performance

The performance of the access control mechanisms at the reference monitor level is strongly connected to the duration of communications between objects. In our system, such communica- tion is carried out by remote method invocation. We thus mea- sured the duration of a method invocation between two objects.

This duration is measured from the viewpoint of the object making the invocation (sending the request message and receiving the re- sponse). We compare the durations of method invocations both Java

Card Reference

Monitor

O 3

Card Java Monitor

Reference message

1

2

O’

Authorization Server

1. An invocation message carrying a capability and a voucher PKm, PKas

SKj,PKj, Ki

is received by the local reference monitor

authorizing this access has been certified by the Java Card operation. This token is presented to the authorization server

in order to obtain the corresponding permissions.

O

3. The voucher contains a token for to carry out a composite 2. The corresponding method of is invoked once the capability O

Fig. 4. Example of a voucher containing a token.

Table 2

Real time (CPU time) consumed for various AS functions (in seconds).

Key length Authentication Authorization request handling

Token handling

1024 bits 2.6 (0.640) 3.8 (1.13) 3.48 (0.75)

with and without access control, and for remote and local invoca- tions. The results are given in Table 3.

The measures show that the duration of access control is about 45% of the duration of method invocation for a remote invocation and about 70% for a local invocation. In our proof-of-concept implementation, these figures can be explained by the limitations of the employed JavaCard technology: 9600 bps serial communica- tion; 256-byte maximum message length. When a message has to be deciphered by the JavaCard, it has to be first split into several 256-byte pieces. All the pieces of the message are sent to the JavaCard, then gathered to obtain the whole message before being deciphered. These measures would be much better with the recent improvements in JavaCard technology, i.e., with more powerful computation and better communications.

7. Related work

International standard ISO 10181-3 [19] defines a general framework for access control in open interconnected systems. This standard distinguishes two access control functions: the Access Control Decision Function (ADF) and the Access Control Enforce- ment Function (AEF). The AEF ensures that only allowable accesses, as determined by the ADF, are performed on the target. The explicit separation of the ADF and AEF functions is one of the characteris- tics of our authorization scheme. In our scheme, the authorization server performs typically the ADF, while the security kernels implement the AEF. Our authorization scheme is thus compliant with this international standard.

OASIS standard XACML [20] proposes a common security-policy language, based on XML, to be used for access control for distrib- uted applications. Security policies of large enterprises, for exam-

ple, or security policies for large distributed services, may have many elements and many points of enforcement. These points of enforcement may be completely different (applications, switches, routers, firewalls, . . .). XACML proposes a solution to express a security policy in a uniform way. XACML proposes four levels to enforce the access control rules: the Policy Administration Point (PAP), the Policy Enforcement Point (PEP), the Policy Information Point (PIP) and the Policy Decision Point (PDP). The four entities collaborate in order to grant or deny an authorization request. This architecture is comparable to our authorization service architec- ture in the sense that it can be considered as an instanciation of the ISO 10181 standard.

XACML can be used in conjunction with another OASIS stan- dard, SAML (Security Assertions Markup Language). As stated in [33], ‘‘SAML assertions are XML-format messages that can transfer decision information about authentication operations performed by subjects, attribute of subjects and authorization decisions”.

The report [33] presents the GOLD project, in which the authors combine XACML and SAML to offer a single login mechanism (en- abling the crossing of organizational boundaries) and access con- trol using the policy semantics defined by XACML.

Our authorization server can be considered as an example of a PDP and the reference monitor an example of a PEP. From an archi- tectural viewpoint, our authorization scheme is similar to the authorization scheme of the GOLD project. In order to make our authorization scheme OASIS-compliant, we should have to express the security policy using the XACML formalism and the messages exchanged between PDP and PEP using to the SAML formalism.

However, our authorization server goes further than XACML and SAML by defining and distributing new kinds of permissions and a fine-grained authorization and delegation scheme, which we be- lieve more suited for Internet.

The idea of managing and delegating rights for elementary operations, i.e., fine-grained authorization and delegation, has also been explored in RBAC (role-based access control) models, such as in [21,22]. In these papers, the authors argue that the notion of del- egation in RBAC models is usually a role-delegation which deals with user-to-user delegation. They propose to add flexibility in these delegation models so that they allow fine-grained control over what rights a user wishes to delegate as opposed to delegation at the role level. Our authorization scheme implements this fine- grained authorization and delegation principle but we consider that it goes further. As a matter of fact, in these RBAC models, the delegation right is still a classic notion where an entity can only delegate a right that it possesses. Our model adds flexibility to the delegation concept.

Fig. 5. Real time percentage of AS functions.

Table 3

Additional CPU time induced by the access control mechanisms of a method invocation.

With access control Without access control Invocation

time

Control time

Invocation time Remote invocation

1024 bits CPU (s) 0.2 0.020 0.012

Real Time (s) 8.2 3.45 1.2

Local invocation

1024 bits CPU (s) 0.12 0.018 0.011

Real Time (s) 5.25 3.30 0.9

Many distributed systems ([7–10] for example) include the no- tion of delegation but, as previously explained, this delegation of rights from an object O to another object O

always requires O to possess the rights delegated. In Kerberos for example, in order for an object O to delegate a privilege to an object O

, O must first possess this privilege. Our authorization scheme offers a better enforcement of the least privilege principle. The originality of this approach is that Ocan delegate rights (included in a voucher) that it does not possess. Crispo, in [23–25], investigated the notion of del- egation. He distinguishes the delegation of rights and the delega- tion of responsibilities, and argues that it is crucial for the accountability and traceability of operating systems to distinguish these two aspects. Crispo gives several examples of real complex delegation situations. He explains that the delegation of responsi- bility is not trivial and that it is complementary to the notion of delegation of rights. Our scheme proposes a very simple way to solve this responsibility problem. Each object that carries out an elementary operation in our system acts on its own behalf and is thus entirely responsible for that operation. In usual delegation systems, when B carries out an operation on behalf of A (thanks to delegated rights from A), A is still considered as responsible for this operation. This does not enable B to be identified as buggy or malicious. In our model, rights delegated from A to B are rights that can be used by B and nobody else since the identity of B is in- cluded in the corresponding capability or token. Thus, B is identi- fied as the entity responsible for the execution of the operations authorized by these rights. In case of abuse, e.g,, by a Trojan horse, B will be the first suspect.

Our proofs of authorization are also a form of anonymous cre- dentials, as presented in many papers, such as [26,27] and more re- cently [28]. As a matter of fact, the identity of the user who is authorized to perform a composite operation is never transmitted along the path of atomic operations that constitute the composite operation. Each object that carries out an atomic operation on be- half of a user presents proofs of authorization that do not include the identity of the user but only the identity of the object itself.

Observing an atomic operation in the system and capturing the corresponding proof of authorization does not provide any infor- mation about the user who initiated the composite operation.

SPKI [29] proposes to consider a certificate as a way to asso- ciate permissions to the owner of a cryptographic key, which is less restrictive than the usual association of a person to a cryp- tographic key. In this vision, a certificate still establishes a link between a key and an identity but, furthermore, holds a set of attributes and permissions, which are possibly confidential.

These certificates can be generated by any entity that controls the access to some resource and can be delegated. They include the public key of the issuer, the public key of the recipient of the certificate, a delegation bit, permissions granted to the recipi- ent of the certificate and a validity field. Other papers, such as [30,31], also discuss the use of such certificates to delegate ac- cess rights. Ref. [30] presents the advantages and limitations of delegation certificates while [31] proposes a definition for X.509 Proxy Certificates for the purpose of providing restricted proxying and delegation within a PKI-based authentication sys- tem. These approaches are interesting in the context of a distrib- uted application on the Internet but they still correspond to a client/server vision of authorization. Furthermore, the separation of decision and enforcement functions is not explicitly detailed, which makes this scheme possibly not compliant with ISO 10181.

8. Conclusion

In this paper, we have proposed an architecture of an authori- zation service designed for composite operations involving many

Internet partners. The proposed architecture matches our original objectives: (1) finding a compromise between a totally central- ized and totally distributed authorization scheme (which both have significant drawbacks), (2) designing an authorization scheme that is able to distribute proofs of authorization to the participants of a composite operation whilst enforcing the least privilege principle.

The architecture is based on two main components: the autho- rization server and the reference monitors. The authorization ser- ver is in charge of granting or denying rights for composite operations involving several participants. It is built in such a way that it is not a single point of failure. On each participating host, a reference monitor is responsible for fine-grained authorization, i.e., for controlling the access to all local resources and objects, according to the proofs of authorization that accompany each request.

The design and the security properties of these components have been presented, as well as a proof-of-concept implementa- tion. We gave some measures of the performance obtained with this implementation and analyzed the various overheads. The measurements obtained point to the need for specialized hard- ware for the required cryptographic operations. Another interest- ing direction for future research would be to investigate the performance enhancements that might be obtained by applying recent advances in Byzantine fault tolerance (e.g., [32] to the authorization server).

References

[1] US Department of Defense Trusted Computer Security Evaluation Criteria (TCSEC), 5200.28-STD, December 1985.

[2] J.M. Rushby, B. Randell, A distributed secure system, IEEE Computer 16 (7) (1983) 55–67.

[3] Trusted Network Interpretation of the Trusted Computer Security Evaluation Criteria, National Computer Security Center, December 1987.

[4] V. Nicomette, Y. Deswarte, An authorization scheme for distributed object systems, in: Proceedings of the International Symposium on Security and Privacy, IEEE Computer Society Press, Oakland, CA, USA, 1997, pp. 21–30.

[5] V. Nicomette, Y. Deswarte, Symbolic rights and vouchers for access control in distributed object systems, in: J. Jaffar, R.H.C. Yap (Eds.), Proceedings of the Second Asian Computing Science Conference (ASIAN’96), Singapour, 1996, Concurrency and Parallelism, Programming, Networking and Security, LNCS, vol. 1179, Springer-Verlag, pp. 193–203.

[6] Y. Deswarte, N. Abghour, V. Nicomette, D. Powell, An Intrusion-tolerant authorization scheme for internet applications, in: Workshop on Intrusion Tolerant Systems, Supp. of the Proceedings of 2002 International Conference on Dependable Systems and Networks (DSN 2002), Washington DC, 23–26 June 2002, pp. C.1.1–C.1.6.

[7] B. Neuman, Proxy-based authorization and accounting for distributed systems, in: Proceedings of the 13th International Conference on Distributed Systems, May 1993, pp. 283–291.

[8] J. Tardo, K. Alagappan, Spx: global authentication using public key certificates, in: Proceedings of the IEEE Symposium on Security and Privacy, 1991, pp. 232–

245.

[9] M. Gasser, E. MacDermott, An architecture for practical delegation in a distributed system, in: Proceedings of the IEEE Symposium on Security and Privacy, 1990, pp. 20–30.

[10] T.A. Parker, A secure European system for applications in a multi-vendor environment (the SESAME Project), in: Proceedings of the 14th National Computer Security Conference, NCSC and NIST, Washington, October 1991, pp.

505–513.

[11] C. Cachin, K. Kursawe, V. Shoup, Random oracles in constantinople: practical asynchronous byzantine agreement using cryptography, in: Proceedings 19th ACM Symposium on Principles of Distributed Computing (PODC), 2000, pp.

123–132.

[12] C. Cachin, J. Poritz, Secure intrusion tolerant replication on the internet, in: Proceedings of the 2002 International Conference on Dependable Systems and Networks (DSN 2002), Washington, DC (USA), 23–26 June 2002, pp. 167–176.

[13] C. Cachin, M. Correia, T. McCutcheon. N.F. Neves, B. Pfitzmann, B. Randell, M.

Schunter, W. Simmonds, R. Stroud, P. Verssimo, M. Waidner, I. Welch, Service and Protocol Architecture for the MAFTIA Middleware, MAFTIA Project IST 1999-11583 Deliverable D23, 92, January 2001, p. 25.

[14] J. Algesheimer, C. Cachin, K. Kursawe, F. Petzold, J.A. Poritz, V. Shoup, M.

Waidner, MAFTIA: Specification of Dependable Trusted Third Parties, IBM

Research, Zurich Research Laboratory, Zurich (CH), MAFTIA Project IST 1999-

11583 Deliverable D26, 22 January 2001.

[15] P.E Verissimo, N.F. Neves, C. Cachin, J. Poritz, D. Powell, Y. Deswarte, R. Stroud, I. Welch, Intrusion-Tolerant Middleware, IEEE Security and Privacy, July/

August 2006, pp. 54–62.

[17] N. Abghour, Schéma d’Autorisation pour Applications Réparties sur Internet, Thèse de Doctorat de l’Institut National Polytechnique de Toulouse (in French), June 2004, Rapport LAAS No. 04327.

[18] Nadia Nedjah, Luiza de Macedo Mourelle, Fast reconfigurable systolic hardware for modular multiplication and exponentiation, Journal of Systems Architecture 49 (7–9) (2003) 387–396.

[19] ISO/IEC 10181-3, International Standard, first ed., 1996-09-15.

[20] OASIS, eXtensible Access Control Markup Language Specification v1.1, 24 July 2003. <http://www.oasis-open.org/committees/xacml/repository/cs-xacml- specification-1.1.pdf>.

[21] X. Zhang , S. Oh, R. Sandhu, PBDM: a flexible delegation model in RBAC, in:

Proceedings of the Eighth ACM Symposium on Access Control Models and Technologies, Como, Italy, June 02–03, 2003.

[22] J. Wainer, A. Kumar, A fine-grained, controllable, user-to-user delegation method in RBAC, in: Proceedings of the Tenth ACM Symposium on Access Control Models and Technologies, Stockholm, Sweden, 2005, pp. 59–66.

ISBN:1-59593-045-0.

[23] B. Crispo, B. Christianson, A note about the semantics of delegation, in:

Proceedings of the Third Conference on Autonomous Agent (Agent ’99), 1–5 May 1999, Seattle.

[24] B. Crispo, Delegation of responsibilities, in: Proceedings of the 1998 Security Protocols International Workshop, LNCS, vol. 1550, Springer-Verlag, Cambridge, UK, April 15–17, 1998, pp. 118–13. ISBN 3-540-65663-4.

[25] B. Crispo, Delegation protocols for electronic commerce, in: Proceedings of the Sixth IEEE Symposium on Computers and Communications (ISCC01), Hammamet, Tunisia, IEEE Press, 2001.

[26] David Chaum, Security without identification: transaction systems to make big brother obsolete, Communications of the ACM 28 (10) (1985) 1030–1044.

[27] David Chaum, J.-H. Evertse, A secure and privacy-protecting protocol for transmitting personal information between organisations, CRYPTO’98, LNCS, vol. 263, Springer-Verlag, 1987, pp. 118–167.

[28] J. Camenisch, A. Lysyanskaya, An efficient system for non-transferable anonymous credentials with optional anonymity revocation, in: Pfitzmann Birgit (Ed.), Advances in Cryptology, EUROCRYPT 2001, LNCS, vol. 2045, Springer, pp. 93–118. doi:10.1007/3-540-44987-6_7, ISBN 978-3-540-42070- 5.

[29] C.M. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen, SPKI Certificate Theory, RFC, vol. 2963, 1999.

[30] T. Aura, Distributed access-rights managements with delegations certificates, in: Secure Internet Programming, LNCS, vol. 1603, Sringer-Verlag, 1999, pp.

211–235.

[31] V. Welch, I. Foster, C. Kesselmann, O. Mulmo, L. Pearlman, S. Tuecke, J. Gawor, S. Meder, F. Siebenlist, X.509 Proxy Certificates for Dynamic Delegation, in:

Third Annual PKI R&D Workshop, 2004. <http://www.globus.org/Security/

papers/pki04-welch-proxy-cert-final.pdf>.

[32] R. Kotla, L. Alvisi, M. Dahlin, A. Clement, E. Wong, Zyzzyva: speculative byzantine fault tolerance, ACM SIGOPS Operating Systems Review 41 (6) (2007) 58.

[33] J. Wu, P. Periorellis, Authorization–Authentication Using XACML and SAML, Technical Report CS-TR-907, School of Computing Science, University of Newcastle, 20p. 2005. <http://citeseerx.ist.psu.edu/viewdoc/

summary?doi=10.1.1.67.1821>.

[34] J. Mirkovic, P. Reiher, A taxonomy of DDoS attack and DDoS defense mechanisms, ACM SIGCOMM Comput. Commun. Rev. 34(2) (2004) 39–53.

ISSN: 0146-4833, doi:http://doi.acm.org/10.1145/997150.997156.

Vincent Nicomette is currently a teacher of Institut National des Sciences Appliquées de Toulouse (INSA) and member of the ‘‘Dependable Computing and Fault Tolerance” research group at LAAS–CNRS in Toulouse, France. He received his Ph.D. degree from Institut National Polytechnique de Toulouse (France) in 1996 and his Diploma of Computer Engineer from ENSEEIHT (France) in 1992.

His research mainly deals with security in distrib- uted computing systems.

Yves Deswarte is currently a Research Director of CNRS, member of the ‘‘Dependable Computing and Fault Tolerance” research group at LAAS–CNRS in Toulouse, France. Successively at CII, CIMSA, INRIA and LAAS, his research work has dealt mainly with fault tolerance and security in distributed computing systems. Recently, his main research interests were in intrusion tolerance, quantitative security evaluation, dependability evalua- tion criteria, protection of safety – critical systems with multiple levels of integrity, flexible security policies, and privacy-preserving authorization schemes. He is the author or co-author of more than 100 international publications in these areas. He has been consultant for several organizations in France and for SRI-international in the USA. He has been a member of many international conference program committees and has chaired several of them. He is a senior member of SEE, a member of the IEEE TC on Security and Privacy and a member of the ACM SIGSAC. He is representing the IEEE Computer Society at IFIP TC-11 (Technical Committee on Security and Protection in Information Processing Systems).

David Powell is Directeur de Recherche at CNRS. He received his Bachelor of Science degree in Electronic Engineering from the University of Southampton, Eng- land in 1972, a Specialty Doctorate degree from the Toulouse Paul Sabatier University in 1975, and his Docteur ès-Sciences degree from the Toulouse National Polytechnic Institute in 1981. He is a member of the Dependable Computing and Fault Tolerance Research Group at LAAS–CNRS, Toulouse, France. His research interests include dependability in the face of accidental and intentional human faults, fault-tolerant distributed systems, and dependability assessment. His current focus is mobile computing and autonomous robot systems. He has authored or co- authored 3 books, 125 papers and 19 book chapters, managed several national and European research contracts, and acted as a consultant for companies in France and for the European Commission. Dr. Powell is a member of IEEE, ACM and the IFIP 10.4 working group on Dependable Computing and Fault Tolerance.

Noreddine Abghour is currently associate professor in the Faculty of Science of Hassan II University, Morocco.

He received his Ph.D. degree from Institut National Polytechnique de Toulouse (France) in 2004. His research mainly deals with authorization schemes in distributed computing systems.

Christophe Zanon is currently research engineer at

LAAS–CNRS, Toulouse. He received his Masters degree

in 2001. He was involved in the European projects

MAFTIA (Malicious and Accidental Fault Tolerance for

Internet Applications) from 2000 to 2003, and PRIME

(Privacy and Identity Management for Europe) from

2004 to 2008.