1 introduction - unive.it€¦ · 1 introduction the wide diffusion of critical services, such as...

�� !�"$#�%'&)(+*,#�-/.'01*32�45#76!01892:(;-�&<*,#>=?&

@A.B='CD0:#>=?&:EGFG.'%H2D(+*�IJ.'(K#L.BMN#�0PO72Q-R%DS1*3.'(TIJ=U#>.'0V=B.

�WYXYX[Z]\;^_Z `bacNaedgfA\hd5W �i�]j_kAlml[nGj'o7oprqts,uwv$xwy!ubz_{|{t}

�R~��\�W5��ma��~��Z]\;^_fg�Da��i�~��GZ]d5WG\h`�a

��\hf��rf��?��WY�L�r��a��a+� ��5^H�rfG�5^Ha�d�WQ^Ha�Zb� �N\hZG^BZ]dgZb��a+� � Zb�ma��f �� 7aefG�5^��iWY��dA��+��

"�# %'&)(+*,#�-/.'01*�2¡4Q#m6¢0?8£2D(;-�&<*,#>=?&�¤m¥�0¦#¨§V.'(©Mt#ª*t«&¬OY&�Y®)2¦M¯=?&)(K#J45#�°T.'0V.B±)#�&°#�&²@A2D(K#�0V2´³|µHµ�¤�¶'·5³1¸H¹´º».BM�*w(©.w¼:°½.'0?.B±)#�&�¤m6>*¾&:EÀ¿

Freshness Analysis in Authentication Protocolsin Mobile Ambient Calculus

Chiara Braghin, Agostino Cortesi and Riccardo FocardiDipartimento di Informatica,

Universita Ca’ Foscari di Venezia

Abstract

Freshness of messages in authentication protocols is a key issue to prevent replay attacks. Inthis paper, we show how to model cryptographic protocols in the Mobile Ambient calculus, andhow, in this setting, a suitable control-flow analysis can beapplied in order to statically detectpossible lack of freshness occurring at run-time.

1 Introduction

The wide diffusion of critical services, such as e-commerceand home banking, which should providesecurity guarantees to entities located and possibly moving in different geographical areas, has enor-mously increased the interest in security and mobility issues in the last years. As a consequence, it isimportant to design formal methods that properly model and face both mobility and security.

In the literature, many different approaches to the formal definition of security properties havebeen recently proposed. See, e.g., [1, 2, 19, 26, 27, 34, 35].A first distinction among such approachesis based on the language which is used to describe the system or the program to be analysed. Processcalculi allow the description of a system, focusing on some specific aspects of it, such as communi-cation (e.g., CSP [26, 34], SPA [18],π-calculus and spi-calculus [5]) and mobility (e.g., AmbientCalculus [14]), and abstracting away all the details related to the local computation. An approachwhich is somehow orthogonal, is the so called language-based security [28, 33], in which programsto be analysed are described through simple programming languages, and security guarantees aretypically obtained by imposing some rules on how language primitives are used [35].

A verification method, which is typically adopted in the language-based approach, is static anal-ysis. Static analysis techniques do not require the generation of any operational model of the system.Instead, the property of interest is verified by only analysing the system source code. We observe thatstatic analysis is not exclusively tied to language-based security. For example, papers [10, 13] proposetype-systems and control-flow analyses which aim at verifying the absence of unwanted informationflows in mobile agents, described in Mobile Ambient calculus. In [7], static analysis techniques are ap-plied to guarantee absence of unwanted information flaws inπ-calculus processes. In [1, 2, 3, 22, 23],authors develop type-systems and control-flow analyses forverifying secrecy and authentication prop-erties of cryptographic protocols, specified through spi-calculus. Since static analysis techniques onlyneed to consider the system source code, they are very suitable to be automatically checked.

This paper originates from a couple of quite naive questionsin the scenario depicted above:

• As Mobile Ambient calculus [14, 15] seems to be one of the besthigh-level approaches to facemobility issues, what is needed to properly model also cryptographic protocols in that calculus?

1

• Is it possible to specialise existing abstract-interpretation based analyses of Mobile Ambi-ents [10, 32] to verify specific properties of cryptographicprotocols, thus preventing maliciousattacks?

We restrict our attention to a particular set of common attacks to cryptographic protocols, the socalled “replay attacks”, where an adversary records a communication session and replays the entiresession, or a portion thereof, at some later point in time. Inorder to avoid this kind of attacks, acrucial role in cryptographic protocols is played by message freshness, that guarantees against repli-cation of messages. So we focus on a specific goal: designing afreshness verification technique forcryptographic protocols within Mobile Ambient Calculus.

The main contributions of this paper can be summarised as follows:

• We show that the notion ofboundary, recently introduced to model information leakagein(pure) Mobile Ambient calculus [10], allows to model cryptographic primitives and crypto-graphic protocols, in a quite natural way. Intuitively, in amultilevel security setting, where anyentity can be either confidential or public, ambients labelled as boundaries represent locationswhere confidential information is confined and cannot be blabbed.

• We show how the common methods used to ensure freshness (nonces and sequence numbers)can also be expressed within Mobile Ambients.

• We show how freshness can be expressed in terms of information flow. Intuitively, a leakage ofconfidential information is generated as soon a principal receives the same nonce or sequencenumber more than once. Therefore, suitable ambient nestinganalyses [9, 24] (that may in factdetect information leakage) can be applied, thus enforcingfreshness verification.

• We report on the preliminary results of applying the nestinganalysis of the BANANA tool [8] tosimple cryptographic protocols drawn from the literature.

As far as we know, this is the first attempt to address the issueof verifying freshness either withinthe Mobile Ambient calculus or by a Control Flow Analysis approach. This can be seen as an al-ternative approach to the type and effect system approachesfor proving properties in security pro-tocols [21, 22, 23], and to the introduction of more sophisticated language primitives (like in SafeAmbients [25] or spi-calculus [5]) that are aimed at modeling cryptography.

Even if encoding cryptography in the core Mobile Ambients requires writing somewhat baroquecode, adopting a general purpose language for mobility, like the Ambient calculus, has some advan-tages: on the one hand, it allows us to directly re-use existing generic analysis tools, and, on theother hand, it can be easily specialized on more specific security and cryptography-oriented dialects,if needed.

The results reported in this paper represent a first step towards the design of a more general analy-sis and verification framework of security properties by a control-flow analysis/abstract interpretationapproach. Our preliminary experimental results seem to hint at a promising impact of static analysistechniques to security protocol verification.

The rest of the paper is organised as follows. In Section 2, weintroduce the basic terminology onambient calculus, we present the model of multilevel security for mobile agents, and we show howto model cryptographic protocols within such a framework. In Section 3, we introduce the controlflow analysis we use to verify message freshness. In Section 4, we report some experimental results.Section 5 concludes the paper.

2

2 Cryptographic Protocols in Mobile Ambients

In this section we introduce the basic terminology of MobileAmbients calculus (Section 2.1), andof Security Models (Section 2.2). Then, we use such a formalism to model cryptographic primitives(Section 2.3) and some of the mechanism commonly used to detect replay attacks (Section 2.4).

2.1 Background: Mobile Ambients

The Mobile Ambients calculus has been introduced in [14, 15]with the main purpose of explicitlymodeling mobility. Ambients are arbitrarily nested boundaries which can move around through suit-able capabilities. The syntax of processes is given in Figure 1, wheren ∈ Amb denotes an ambientname.

P,Q ::= (νn)P restriction

| 0 inactivity

| P | Q composition

| !P replication

| nà

[[P ]] ambient

| in`t

n.P capability to entern

| out`t

n.P capability to exitn

| open`t

n.P capability to openn

Figure 1: Mobile Ambients Syntax

The restriction operator(νn)P introduces the new namen and limits its scope toP ; process0does nothing;1 P | Q is P andQ running in parallel; replication provides recursion and iteration as!Prepresents any number of copies ofP in parallel. By nà

[[P ]] we denote the ambient namedn withthe processP running inside it. The capabilitiesin`t

n andout`t

n move their enclosing ambients inand out ambientn, respectively; the capabilityopen`t

n is used to dissolve the boundary of a siblingambientn. The operational semantics of a processP is given through a suitable reduction relation→. Intuitively, P → Q represents the possibility forP of reducing toQ through some computation(see [14, 15] for more details).

Labelsà ∈ Laba on ambients and labelst ∈ Labt on capabilities (transitions) are introducedas it is customary in static analysis to indicate “program points” [31]. They will be useful in the nextsections both when modeling multilevel security and developing the analysis. We denote withLabthe set of all the labelsLaba ∪ Labt. We use the special labelenv ∈ Laba to denote the externalenvironment, i.e., the environment containing the processunder observation.

2.2 Modeling Multilevel Security

Cryptographic protocols are an example of data exchange among two or more parties in which part ofthe exchanged information is, and has to remain, confidential, and part of it is public (e.g., during aprotocol session, principals names are usually public, while the content of the messages is confiden-tial).

1For the sake of readability, we will sometimes omit0. E.g., we will writein`t

n instead ofin`t

n.0

3

To be able to formalize such a framework and distinguish between private and public data, wefocus onMultilevel Security, a particularMandatory Access Controlsecurity policy: every entity isbound to a security level (for simplicity, we consider only two levels: high and low), and informationmay just flow from the low level to the high one. Typically, twoaccess rules are imposed:(i) No ReadUp, a low level entity cannot access information of a high levelentity; (ii) No Write Down, a highlevel entity cannot leak information to a low level entity. Figure 2 summarises this policy.

For example, a cryptographic key used to encrypt/decrypt data should be kept secret, i.e., neitherits owner should disclose it to unauthorized parties, nor a malicious user should be able to get it. Thesame holds for encrypted data, whose decryption should be allowed to authorized parties only.

Write

Read

Write

Read

Write−up

S1 O1

S2 O2

Read−down

Level n

Level n+k

Figure 2: Multilevel Security Policy: information can onlyflow from one level to a higher one.

In order to define Multilevel security in Mobile Ambients we first need to classify information intodifferent levels of confidentiality. We do this by exploiting the labelling of ambients. In particular, wepartition the set of ambient labelsLaba into three disjoint setsLaba

H , Laba

L andLaba

B, which standfor high, low andboundarylabels.

Given a process, the multilevel security policy may be established by deciding which ambientsare the ones responsible for confining Sconfidential information. These are all labelled with boundarylabels from setLaba

B and we will refer to them asboundary ambients. Thus, all thehigh level ambi-entsmust be contained in a boundary ambient and labelled with labels from setLaba

H . Finally, all theexternal ambients are consideredlow levelones and they are consequently labelled with labels fromsetLaba

L. This is how we will always label processes, and it corresponds to defining the security pol-icy: what is secret, what is not, what is a container of possible secrets. The intuition is the following:to guarantee absence of information leakage, every high-level data or process should be encapsulatedinto a boundary ambient, and a boundary ambient can be only opened when it is nested into anotherboundary ambient.

In the next section, we will see that encryption and decryption will be encoded as ambient moves.For this reason, it is useful to assign security levels also to capabilities, which are responsible ofmoves. To this aim, setLabt is partitioned into two disjoint setsLabt

H andLabt

L, representinghighandlow level capability labels.

In all the examples, we will use the label namesb, h, ` implicitly assuming thatb ∈ Laba

B , h ∈Laba

H ∪ Labt

H , ` ∈ Laba

L ∪ Labt

L. (Notice thath and` will be used to label both ambients andcapabilities.) For the sake of readability, we will sometimes omit low level labels.

2.3 Modeling Cryptographic Primitives and Protocols

An encryption primitive encodes aplaintext under the control of a cryptographic key, generating aciphertextwhich is unintelligible to any hypothetical attacker. A decryption primitive retrieves theplaintext from the ciphertext using the appropriate decryption key.

4

Encryption/decryption algorithms come in two flavors. Insymmetric-keyalgorithms (also calledshared-keyalgorithms), the same key is used for encryption and decryption. The key has to be keptconfidential: all parties sharing the same key can read each other’s encrypted data. Inpublic-keyalgo-rithms (also calledasymmetric-keyalgorithms), different keys are used for encryption and decryption.In this case, the encryption key can be made public, while thedecryption key has to remain private.Obviously, the two keys are algorithmically related, but itshould not be easy to derive the private keyfrom its public counterpart. In the rest of the paper, to differentiate between symmetric and public keycryptosystems, we will use the termsecret keyonly in the context of symmetric systems, andprivatekeyonly in the context of asymmetric systems.

In order to model cryptographic primitives in Mobile Ambients, an ambient calledencK is intro-duced to represent an encryption location, with keyK. In this scenario, cryptographic operations arerepresented by the capability to either enter or open such anambientencK . More in detail, encryptionis modeled by thein capability, while decryption is modeled by theopencapability. When ambientn enters ambientencK , such a move should be interpreted as the application of the encryption algo-rithm to datumn. On the other hand, when ambientencK containing ambientn (i.e.,encb

K[n[Q ] ] )

is opened, such a move should be interpreted as the application of the decryption algorithm tonencrypted withK.

A labeling is necessary to establish what is private: ambient encK must be labeledboundary

because it contains confidential data. In addition, in the case of symmetric systems, both capabilitiesmust be labeledhigh as the key must be kept secret. In the case of public key systems, the encryp-tion capability is labeled aslow, representing the fact that encrypting is a public operation. Table 1summarises the description above.

A Msg Flow B

Symmetric-key algorithm inhencK −→ openh

encK

openhencK ←− inh

encK

Public-key algorithm in`encK −→ openh

encK

Table 1: Cryptographic Keys Modeled in Mobile Ambients

The formalisms presented above, can be used to modelcryptographic protocols. A protocol is aset of rules or conventions defining an exchange of messages between a set of two or more partners.In a cryptographic protocol, part of the messages is encrypted.

When reporting cryptographic protocols, we adopt a notation common in the literature. SymbolA

andB represent arbitrary principals,S a server,N a nonce,KA A’s public key, andK−1

AA’s private

key. In symmetric cryptosystems,K andK−1 are always equal.{X}K representsX encrypted withkeyK. Anyone who knowsK−1 can decrypt{X}K and thus obtainX.

Consider, for instance, the following trivial protocol, consisting of a single message.Alice (A)wants to send toBob (B) some confidential informationhdata over an insecure network. To do so,she encryptshdata with keyK shared with Bob.

A → B : {hdata}K (1)

The protocol may be formalised in Mobile Ambients as follows:

P = Ab[[ encbK

[[ out A.in B ]] | hdatah[[ inh encK ]] ]]|Bb[[ openh encK | B′ ]]

5

P is the parallel composition of ambientsA andB: 2

• On Alice side (A), the confidential datahdatahas the capability to enter theencK ambient,which then migrates out of its parent ambientA and inside the sibling ambientB;

• On Bob side (B), the capabilityopenh encK may be applied as soon as ambientencK is re-ceived; the effect is to dissolve it, thus disclosing its content to the processB′ running insideB.

encK

in encK

hdata

A

in Bout A.

B

openencK

encK

hdata

in Bout A.

B

openencK

A

A

encK

hdata

in B

B

openencK

B

openencKencK

hdata

A

B

hdata

A

(a)) A needs to send confidential datahdatato B.

(b) The confidential datahdatais encrypted with a shared keyK.

(c) The confidential data is sent encrypted over the communication channel.

(d) The confidential data is safely received byB.

(e) B accesses the confidential data by decrypting it.

Figure 3:A andB exchange confidential information.

2Observe that in the Mobile Ambient calculus, messages decide of their own movement, while in reality they are sentby principals. Also notice thatencK could move toB beforehdata has entered it. We could obtain a correct behaviour ofencK by adding tohdata a further envelope which would be opened before moving, but we prefer simplifying the examplefor the sake of readability.

6

Looking in more detail to the possible evolution of processP , we may observe, with the help ofFigure 3, steps (a)—(d), thatP moves to:

Ab[[ ]]|

Bb[[ openh encK | B′ | encbK

[[ hdatah[[ ]] ]] ]]

and finally, through step (e) of Figure 3, it reduces to

Ab[[ ]]|Bb[[ B′ | hdatah[[ ]] ]]

Notice that, also in this case, a labeling is necessary to denote what is private and what is just re-sponsible for confining confidential information (i.e., a boundary). Since a cryptographic protocolis used when two or more parties are interested to exchange confidential information (e.g., a sessionkey, or their credit card number), protocol principals should be always considered asboundariesandthe confidential data they exchange should be labeledhigh. Also the encryption location should belabeled boundary as previously explained.

In the example above, everything is correct with respect to secrecy, as the confidential datahdataare always confined within a boundary ambient, i.e. never exposed to the possibly untrusted environ-ment.

2.4 Modeling Nonces and Sequence Numbers

A cryptographic protocol is meant to provide secure services. However, if the protocol has not beendesigned correctly, it may fail to do so, thus being exposed to various attacks from malicious users.A common attack in authentication protocols is thereplay attack, in which an adversary records oldmessages and use them at some later point in an attempt to subvert the protocol.

To prevent messages to be reused through actions of either anadversary or an unauthorized party,time-variant parameters are added to the protocol, in orderto distinguish one protocol instance fromanother. Upon receiving a message, the principal checks itsfreshnessand either accept or reject it.Two important classes of time-variant parameters are discussed in turn below. Timestamps are notconsidered as they are based on clocks, and, for that reason,their modeling is much more complex.

Nonces. They are random values used only once to provide uniqueness and timeliness assurance.The presence in a response of a freshly generated nonce assures that the received message islegitimate and not a replay of a response from a previous execution of the protocol. Protocol 1,can be modified as follows:

B → A : NB

A → B : {hdata,NB}K

whereNB is a nonce generated byB. When Bob receives the encrypted message, he checksthat the received nonce is equal toNB .

Sequence numbers.They are integer values which are incremented sequentially. A message is ac-cepted only if its sequence number is greater than the one previously received. Sequence num-bers are specific to a particular pair of entities, and must beassociated with both the originator

7

and the recipient of a message, thus distinct sequences are necessary for messages fromA to B

and fromB to A. Protocol 1, can be modified as follows:

A → B : {hdata, SeqA}K

When Bob receives the encrypted message, he checks that the received sequence numberSeqA

is greater than the last one received fromA. In such a case, Bob memorizesSeqA and acceptsthe message.

Let us see how nonces and sequence numbers may be modeled within Mobile Ambients calculus.When using nonces to check the freshness of a message, the principal should include the following

code (wherenonce is a new, restricted name):

(a) nonce[[Q ]] |(b) msg[[ opennonce | Routing ]] |(c) openenc.openmsg.0

(a) the new ambientnonce[[Q ]] represents the freshly generated nonce, and is kept by the principal.ProcessQ is the continuation of the protocol, i.e., the code that willbe activated after the noncewill be correctly checked;

(b) The capabilityopennonce, is sent to the other principal inside a messagemsg. ProcessRouting represents routing code, together with the code used to manipulate the message. Mes-sagemsg is encrypted by the other principal and sent back;

(c) The message is decrypted throughopenenc andopenmsg. This releasesopennonce whichopens the initially stored noncenonce releasing the continuation processQ. Notice that thenonce is opened only if the capabilityopennonce is contained inside the message. In case ofa replay of an old message we would have a capabilityopennonce′ with nonce 6= nonce′ andthe resulting process would block.

If the protocol requires the nonce to be incremented by one, such a situation can be modeled byintroducing a new ambientone, which is nested inside ambientmsg by the receiver. When checkingthe validity of the nonce, the principal will also check the existence of such an ambient insidemsg.This can be easily achieved by addingopenone inside the nonce:nonce[[ openone.Q ]] . If bothnonce andone exists, then the protocols continues, otherwise it fails.

Notice that sequence numbers can be modeled in the same way: an ambientone is added everytime the number has to be incremented by one.

Example 2.1 Consider the following challenge-response protocol, in which Alice andBob share thesymmetric keyK:

A → B : {NA}K

B → A : {NA + 1}K

(2)

This protocol is used byA to be guaranteed thatB is alive. To achieve this, Alice challenges Bob todecrypt and re-encrypt the nonce, incremented by one, usingkeyK. The motivation for incrementingthe nonce value, is to avoid a trivial reflection attack, in which the enemy would just send back thevery same{NA}K message to Alice.

8

The protocol may be formalized in Mobile Ambients as follows:

Ab[[ nonce[[ openone.Q ]]| enc1b

K[[ out A.in B | msg[[ opennonce | opencmd ]] ]]

| openh enc2K .openmsg.0 ]]|

Bb[[ openh enc1K |

| cmd[[ in msg | inh enc2K | one[[ ]] ]]| enc2b

K[[ out B.in A.0 ]] ]]

On Alice side, the nonce, represented by capabilityopennonce, is encrypted (i.e., included in ambientenc1K ), and then sent to Bob. Ambientnonce represents the fact that Alice records somewhere thenonce she has just sent to Bob. The reached state is the following:

Ab[[ nonce[[ openone.Q ]]| openh enc2K .openmsg.0 ]]

|

Bb[[ openh enc1K || cmd[[ in msg | inh enc2K | one[[ ]] ]]| enc2b

K[[ out B.in A.0 ]]

| enc1bK

[[ msg[[ opennonce | opencmd ]] ]] ]]

On Bob side, the nonce is received, decrypted by using the symmetric keyK (i.e., by consum-ing theopenenc1K capability), and manipulated by ambientcmd which entersmsg. This ambientis opened bymsg releasing ambientone (which represents nonce incrementation) and capabilityinh enc2K :

Ab[[ nonce[[ openone.Q ]]| openh enc2K .openmsg.0 ]]

|

Bb[[ enc2bK

[[ out B.in A.0 ]]

| msg[[ opennonce | inh enc2K | one[[ ]] ]] ]]

Capabilityinh enc2K encryptsmsg again and the obtained message is sent back to Alice:

Ab[[ nonce[[ openone.Q ]]| openh enc2K .openmsg.0

| enc2bK

[[ msg[[ opennonce | one[[ ]] ]] ]] ]]|

Bb[[ ]]

Now, the nonce and the incrementationone can be checked, after message is decrypted and the finalstate is the expected one:

Ab[[ Q ]]|

Bb[[ ]]

9

3 Verifying Freshness through Control Flow Analysis

In order to verify freshness conditions, we apply static analysis techniques that over-approximateinformation flows marking possible message duplications.

3.1 Interpreting Lack of Freshness as Information Flow

In [9], the authors develop an analysis to verify that no leakage of confidential data outside boundaryambients is possible. The aim of the analysis is to compute anover approximation of ambient nestings:the analysis returns a set which contains all the ambient nestings that are possibly generated at run-time. Nestings inside and outside boundaries are considered separately, yielding to an accurate toolfor detecting unwanted boundary crossings.

As we have already mentioned in the introduction, in this paper we aim at expressing the problemof replay attacks detection as a problem of information leakage. When a replay attack occurs, someinformation leakage will be generated. Then, lack of freshness of a cryptographic protocol can bestatically detected.

In replay attacks, an adversary records a communication session and replays the entire session, ora portion thereof, at some later point in time. A technique tostatically detect such a situation can bedesigned as follows: ambientflag (1), representing a flag, is added to each fresh outcoming message,while a watermark is bounded to every duplicated message(2). If a duplicate is sent by a malicioususer to any of the protocol principal,flag ambient is opened and a high level ambient is released,raising a flow.

(1) flagb[[ flowh[[ out` A.0 ]] ]](2) revealb[[ open` flag ]]

3.2 Overview of the Nesting Analysis

The static verification of freshness in cryptographic protocols can be obtained by post-processing thecontrol flow analysis presented in [9, 10]. It computes an over-approximation of all possible nestingof ambients and capabilities that may occur at run time. It isan extension of the control flow analysispresented in [24], as it explicitly keeps track of security boundary crossings.

Definition 3.1 The refined control flow analysis works on tuples (IB,IE ,H), where:

• The first componentIB is an element of℘(Laba × (Laba ∪ Labt)). If a process containseither a capability or an ambient labeled` inside an ambient labeleda which is a boundaryor an ambient nested inside a boundary (referred asprotected ambient) then(à, `) is expectedto belong toIB . As long as high level data is contained inside a protected ambient there is nounwanted information flow.

• The second componentIE is also an element of℘(Laba×(Laba∪Labt)). If a process containseither a capability or an ambient labeled` inside an ambient labeleda which is not protected,then(à, `) is expected to belong toIE.

• The third componentH keeps track of the correspondence between names and labels.If aprocess contains an ambient labeledà with namen, then(à, n) is expected to belong toH.

10

The control flow analysis is defined as usual by a representation and a specification function, see [31].They are depicted in the Appendix, where processP∗ runs at the top-level environment labeledenv.

The representation function maps processes to their abstract representation, i.e. a tuple(IB , IE , H)representing processP∗.

Example 3.2 Let P be a process of the form:P = nà1 [[ mà

2 [[ out`t

n ]] ]] , with à1 ∈ Laba

B andà2 ∈

Laba

L. The representation function ofP , denotedβB(P ), is the tuple({(à1, `

a2), (`

a2 , `

t)}, {(env, à1)},

{(à1, n), (à

2 ,m)}). The first component collects the protected nesting occurring in P : ambientnà1

contains ambientmà2 , which owns the capabilityout`

t

to get out of ambientnà1 . These are pro-

tected as we are assuming thatà1 ∈ Laba

B , i.e., thatn is a boundary. As a consequence, the secondcomponent only contains the nesting(env, à

1), which is the only unprotected one. Finally, the thirdcomponent records the mapping between labels and ambient names.

The specification of the analysis amounts to recursive checks of subprocesses, which provide con-straints that the tuple(IB , IE , H) should satisfy in order to be a correct solution for the process. Itis possible to prove that a least solution of this analysis always exists, and it may be computed asfollows: first apply the representation function to the processP∗, then apply the analysis to validatethe correctness of the proposed solution, adding, if needed, new information to the tuple until a fixedpoint is reached.

Example 3.3 Let P be the process of Example 3.2. The least solution ofP is the tuple(IB , IE , H)whereIB = {(à

1, à2), (`

a2 , `

t)}, IE= {(env, à1), (env, à

2),(à

2, `t)}, andH = {(à

1, n), (à2 ,m)}. Observe that(IB , IE , H) strictly containsβB(P ) componen-

twise. This is what is expected, being(IB , IE , H) a safe approximation of all possible nestings thatmay occur during any execution of processP . Notice also thatIE contains the two new nestings(env, à

2) and(à2, `

t) representing the fact thatm exists fromn performing theout capability. Sincem is not protected anymore, these new nestings are recorded inthe second analysis component.

The fixed point algorithm described in [10] can be summarisedas follows:

Definition 3.4 (Fixed Point Algorithm)Input: a processP∗ and a partition labelingL.

(a) Apply the representation functionβB to processP∗ to get the initial tuple(IoB

, IoE, H);

(b) for all the constraints of the specification of the analysis, validate the last generated tuple

(IiB

, IiE, H):

1. if the constraint is satisfied, continue;

2. else, in case the constraint is not satisfied, this is due tothe fact that eitherIB or IE donot consider nestings that may actually occur. In this case,modify IB and IE by adding

the “missing” pairs, thus getting a new tuple( Îi+1

B,

Îi+1

E, H). Then, go back to (b) with

i = i + 1.

The iterative procedure above computes the least solution independent of the iteration order. Theresult of the analysis should be read, as expected, in terms of information flows [10].

Theorem 3.5 No leakage of secret data/ambients outside the boundary ambients is possible duringany execution of processP if in the result of the analysis ofP no high level label appears in thepossibly unprotected nesting componentIE.

11

3.3 Detecting Lack of Freshness by Control Flow Analysis

To detect absence of replay attacks using the nesting analysis described in the previous section, wefirst need to model the intruder explicitly. Then, we may compute the analysis of processP | T , whereP represents possibly many protocol sessions which run in parallel with the intruderT .

To simulate the intruder and his capabilities, we adopt the Dolev-Yao intruder model [16], whichconsiders intruders that can either compose, and replay messages, and decipher them with knowndecryption keys.

If there is a mechanism to detect replay attacks, such as nonces or sequence numbers, no informa-tion flow should arise, even in presence of an intruder. If there is not such a protection mechanism,the analysis safely detects information flow in case an attack occurs.

The result of the analysis should now be read in terms of message freshness.

Definition 3.6 (Freshness)Freshness of messages is guaranteed for any execution of theprotocolP if in the control flow analysis ofP no high level label occurs in the possibly unprotected nestingcomponentIE.

In fact, as soon as a replay attack occurs in a protocol execution, there is at least one trace of theanalysis which captures the attack, i.e., in which a pair(env, h) is added toIE due to the release offlowh[[ out` A.0 ]] . This is guaranteed by the soundness of the nesting analysisshown in [10].

4 Example: a simple Point-to-point Key Update Protocol

In this section, we show how the ideas and definitions presented so far, can be applied to a specificprotocol. To this aim, we exploit the tool BANANA [8], which implements optimizations [11] of thefix-point algorithm presented in the previous section.3

We consider a simple Point-to-point Key Update protocol [29], used to exchange a fresh sessionkey between two parties,A andB. It consists of two messages exchanged between principalsA andB. A long term symmetric keyKAB is assumed to be shareda priori between the two parties. ThenonceNB is used to guarantee the freshness of messages sent toB. In particular,B sends toA thefreshly generated nonceNB . ThenA sends back toB the nonceNB and the new session keyKs,both encrypted using the long term keyKAB:

B → A : NB

A → B : {Ks, NB}KAB

(3)

Our final aim is to show that the protocol above guarantees thefreshness of the second message. Weshow how the specification proceeds, step by step.

In order to simplify the readability of the example, we will use the following macro:

Msg(encAmb,Q, receiver)4= encAmb[[Q | in receiver.0 |

flagb[[ out receiver. f lowh[[0 ]] ]] ]]

to model the sending of a fresh message containing dataQ encrypted within the encryption locationencAmbto ambientreceiver. Both the freshness of a message and its lack are modeled by the flag-revealmechanism described in Section 3.1. Thus, the copy of a message will be modeled by a macro

3BANANA tool is freely available athttp://www.dsi.unive.it/∼mefisto/BANANA/, as a Java applet.

12

namedMsgCopy, with ambientrevealinstead of ambientflag, and the capabilityopenflag in placeof ambientflow.

MsgCopy(encAmb,Q, receiver)4= encAmb[[ Q | in receiver.0 |

revealb[[ out receiver.openflag.0 ]] ]]

If the macro is used whith nonces, a further change is needed:an ambient nameddeliver enclosingeitherflag or revealmust be added to model the fact that messages are delivered only after the noncehas been checked. Moreover, aopendeliver capability must be added inside the ambient representingthe nonce.

Step 1.We start from a simpler flawed protocol, without nonce exchange:

A → B : {Ks}KAB

This protocol is specified in Mobile Ambients as:

Ab[[ encb[[ Khs [[0 ]] | out A.in B.0 ]] ]]

|Bb[[ openenc.0 ]]

Ambient enc represents the encryption of the session keyKs which moves out ofA and entersB.Finally, B decrypts the session key by performing theopenenc capability. As expected, the protocolterminates in the following state representing the successful session key exchange:

Ab[[ 0 ]]|Bb[[ Kh

s [[ 0 ]] ]]

If we analyse this protocol with BANANA , we find out that it isprotectivewith respect to the highlevel (confidential) information represented byKs. Thus the secrecy of session keyKs is preserved.However, secrecy is not enough.B should be also guaranteed thatKs is not a replay of an old sessionkey.

Step 2.To perform this freshness analysis we modify the specification as suggested in Section 3:

Ab[[ encb[[ Khs [[0 ]] | out A.in B.0

| flagb[[ out B. flowh[[ 0 ]] ]] ]] ]]|Bb[[ openenc.0 ]]

The idea is to add a boundary ambientflag, that exitsB once the message is decrypted. Ambientflag contains a high level ambientflow that will be released to the environment as soon asflag isopened. This process is trivially still protective (it may be analysed through BANANA ), as no messagereplay is modeled.

Step 3. In order to observe what happens when a replay is possible, weexplicitly introduce a copyof the encrypted message. Recall that we are assuming that copies differ from original messages by

13

having the capabilityopenflag in place of ambientflag. The state of the protocol afterA has sentout the message containing the session keyKs is the following:

Ab[[ 0 ]]|Msg(encb, Kh

s [[ 0 ]] , B1)|MsgCopy(encb, Kh

s [[ 0 ]] , B2)|B1b[[ openenc.0 ]]|B2b[[ openenc.0 ]]|openreveal.0

Notice that we now have two instances of processB: B1 andB2, which representB in two differentrunning of the protocol. The copy of the encrypted message has been added at the environment leveland contains ambientreveal instead offlag. Notice also that in the copy of the message all theinstances ofB1 have been replaced byB2, to indicate that this message is routed toB2 instead ofB1. When the two messages are decrypted byB1 andB2, the two ambientsflag andreveal exit B1andB2, respectively, reaching the following state:

Ab[[ 0 ]]|B1b[[ Kh

s [[0 ]] ]]|flagb[[ flowh[[0 ]] ]]|

B2b[[ Khs [[0 ]] ]]

|revealb[[ openflag.0 ]]|openreveal.0

When ambientreveal is opened by the processopenreveal.0, it releases the capabilityopenflag

that opensflag, finally generating a flow. This is captured by the BANANA tool which outputs thefact that the protocol is non-protective.

Step 4.Now that we have a mechanism to reveal the delivery of two copies of the same message, wecan specify and analyse the full protocol (3), based on nonceexchange. We first specify the protocolwithout considering the possibility of replaying messages:

Ab[[ encb[[ Khs [[ 0 ]] | out A.in B.0 ]]

| cmd`[[ in msg.in enc.0 ]] ]]|Bb[[ openenc.openmsg.0

|nonce`[[ B′ ]]|msg`[[ out B.in A.opencmd.opennonce.0 ]] ]]

14

Ambient msg represents the first protocol message: it exits fromB and entersA. Then it opensambientcmd, representing the fact that it is willing to execute new commands provided byA. In-deed, ambientcmd entersmsg after it has been received byA, and, once opened, encryptsmsg byperforming the capabilityin enc. The resulting state is the following:

Ab[[ encb[[ Khs [[0 ]] | out A.in B.0 | msg`[[ opennonce.0 ]] ]] ]]

|Bb[[ openenc.openmsg.0

|nonce`[[ B′ ]] ]]

Notice that sending a nonce amounts to keeping an ambient (with a fresh name)nonce and sendingout the capabilityopennonce. Now, the encrypted message is sent toB who opens it and opensmsg,releasingopennonce. The final effect is to opennonce releasing processB′, which represents thecontinuation of the protocol, i.e., whatB does with the received session key. ProcessB′ is executedonly if the received message contains the correctopennonce capability, i.e., only if the receivednonce matches the one that has been previously sent out. The final state is the following:

Ab[[ 0 ]]|Bb[[ Kh

s [[ 0 ]] | B′ ]]

Step 5.We finally want to study if this nonce mechanism is sufficient to avoid replay attacks. To thisaim we explicitly add the same replay attack of the previous example and we exploit theflag–reveal

mechanism presented above to reveal it:

Ab[[0 ]]|Msg(encb, Kh

s [[ 0 ]] | msg`[[ opennonce.0 ]] , B1)|MsgCopy(encb, Kh

s [[ 0 ]] | msg`[[ opennonce.0 ]] , B2)|B1b[[ openenc.openmsg.0

|nonce`[[ opendeliver.0 ]] ]]|

B2b[[ openenc.openmsg.0

|nonce2`[[ opendeliver.0 ]] ]]|openreveal.0

Notice that, as done at step 4, we have two instances ofB: B1 andB2. The latter has a different noncenonce2, and is going to receive the replay with the wrong nonce capability opennonce. Noticealso thatflag andreveal have been enveloped into a special ambientdeliver which is opened bythe process insidenonce andnonce2. This models the fact that messages are delivered only afterthe nonce has been checked. This process turns out to be protective (this can be checked throughBANANA ). It is interesting to observe that by changing ambient namenonce2 to nonce, the protocolbecomes non-protective. This shows the fact that nonce freshness guarantees message freshness.

15

5 Conclusions and Future Works

The encoding of cryptographic primitives in pure Mobile Ambient calculus presented in this paper canbe seen as an interesting application of the notion of boundary ambient, initially designed for facinginformation flow leakage issues. The advantage of reusing existing analyses definitions and tools is astrong motivation to further investigate the possibility of expressing security properties in terms of asuite of simpler ones, following the lines drawn in [17] and [19].

There are a few open issues that deserve to be investigated based on this work. On one side,variants of the core Mobile Ambient calculus should be considered that express objective actions,such as copy primitives. This would allow to overcome the main current limitation of our approach:the need of explicitly modeling any attack “by hand”. On the other side, more sophisticated abstractdomains might be studied and implemented, in order to reducefalse alarms due to the possible lackof accuracy of the analysis.

References

[1] Martın Abadi. Secrecy by Typing in Security Protocols.Journal of the ACM, 46(5):749–786,1999.

[2] Martın Abadi and Bruno Blanchet. Secrecy Types for Asymmetric Communication. InProc.of the 4th Int. Conf. on Foundations of Software Science and Computation Structures (FoS-SaCS’01), volume 2030 ofLecture Notes in Computer Science, pages 25–41. Springer–Verlag,Berlin, 2001.

[3] Martın Abadi and Bruno Blanchet. Analyzing Security Protocols with Secrecy Types and LogicPrograms. InProc. of the 29th ACM SIGPLAN-SIGACT Symposium on Principles of Program-ming Languages (POPL’02), pages 33–44. ACM Press, 2002.

[4] Abadi, Martın and Fiore, Marcelo. Computing Symbolic Models for Verifying CryptographicProtocols. InProc. of 14th Computer Security Foundations Workshop (CSFW’01). IEEE Com-puter Society Press, 160–173, 2001.

[5] Martın Abadi and Andrew D. Gordon. A Calculus for Cryptographic Protocols: The Spi Calcu-lus. Information and Computation, 148(1):1–70, January 1999.

[6] Abadi, Martın and Gordon, Andrew D. A Bisimulation Method for Cryptographic Protocols.Nordic Journal of Computing 5, 4 (Winter), 267–303, 1998.

[7] Chiara Bodei, Pierpaolo Degano, Flemming Nielson, and Hanne Riis Nielson. Static Analysisfor the π-calculus with Applications to Security.Information and Computation, 168:68–92,2001.

[8] Chiara Braghin, Agostino Cortesi, Stefano Filippone, Riccardo Focardi, Flaminia L. Luccio,and Carla Piazza. BANANA A Tool for Boundary Ambients Nesting ANAlysis. InProc. of 9thInt. Conf. on Tools and Algorithms for the Construction and Analysis of Systems (TACAS’03),volume 2619 ofLecture Notes in Computer Science, pages 437–441. Elsevier Science Inc., NewYork, 2003.

16

[9] Chiara Braghin, Agostino Cortesi, and Riccardo Focardi. Control Flow Analysis of MobileAmbients with Security Boundaries. In Bart Jacobs and ArendRensink, editors,Proc. of FifthIFIP International Conference on Formal Methods for Open Object-Based Distributed Systems(FMOODS’02), pages 197–212. Kluwer Academy Publishers, Dordrecht, NL,2002.

[10] Chiara Braghin, Agostino Cortesi, and Riccardo Focardi. Security Boundaries in Mobile Ambi-ents.Computer Languages, 28(1):101–127, Nov 2002. Revised and extended version of [9].

[11] Chiara Braghin, Agostino Cortesi, Riccardo Focardi, Flaminia L. Luccio, and Carla Piazza. ANew Algorithm for Control Flow Analysis of Mobile Ambients.In Lenore D. Zuck et al., editor,Proc. of 4th International Conference on Verification, Model Checking and Abstract Interpreta-tion (VMCAI’03), volume 2575 ofLecture Notes in Computer Science, pages 86–101. ElsevierScience Inc., New York, 2003.

[12] Chiara Braghin, Agostino Cortesi, Riccardo Focardi and Steffen van Bakel. 2002c. BoundaryInference for Enforcing Security Policies in Mobile Ambients. In Proc. of 2nd IFIP Interna-tional Conference on Theoretical Computer Science (TCS’02). Kluwer Academy Publishers,Dordrecht, NL, 383–395, 2002.

[13] Michele Bugliesi, Giuseppe Castagna, and Silvia Crafa. Boxed Ambients. InProc. of 4th Int.Conference on Theoretical, Aspects of Computer Science (TACS’01), number 2215 in LectureNotes in Computer Science, pages 38–63. Springer–Verlag, Berlin, 2001.

[14] Luca Cardelli and Andrew D. Gordon. Mobile Ambients. InM. Nivat, editor,Proc. of Founda-tions of Software Science and Computation Structures (FoSSaCS’98), volume 1378 ofLectureNotes in Computer Science, pages 140–155. Springer–Verlag, Berlin, March 1998.

[15] Luca Cardelli and Andrew D. Gordon. Mobile Ambients.Theoretical Computer Science,240(1):177–213, 2000.

[16] D. Dolev and A.C. Yao. On the Security of Public Key Protocols. IEEE Transactions on Infor-mation Theory, IT-29(2):198–208, 1983.

[17] Focardi, Riccardo and Gorrieri, Roberto. A Classification of Security Properties for ProcessAlgebras.Journal of Computer Security,3(1): 5-33, 1995.

[18] Riccardo Focardi and Roberto Gorrieri. The Compositional Security Checker: A Tool for theVerification of Information Flow Security Properties.IEEE Transactions on Software Engineer-ing, 23(9):550–571, September 1997.

[19] Riccardo Focardi, Roberto Gorrieri, and Fabio Martinelli. Non Interference for the Analysisof Cryptographic Protocols. In U. Montanari, J. Rolim, and E. Welzl, editors,Proc. of the Int.Colloquium on Automata, Languages and Programming (ICALP’00), volume 1853 ofLectureNotes in Computer Science, pages 354–372. Springer–Verlag, Berlin, August 2000.

[20] Focardi, Riccardo and Martinelli, Fabio. A Uniform Approach for the Analysis of CryptographicProtocols. InProc. of the 2nd Conf. Security Communication Networks (SCN’99), 1999.

[21] Andrew D. Gordon and Alan Jeffrey. Authenticity by Typing for Security Protocols. InProc.of 14th Computer Security Foundations Workshop (CSFW’01), pages 145–159. IEEE ComputerSociety Press, 2001.

17

[22] Andrew D. Gordon and Alan Jeffrey. Typing Correspondence Assertions for CommunicationProtocols. InProc. of 17th Conf. on the Mathematical Fundations of Programming Semantics(MFPS’01), pages 99–120. Elsevier Science Inc., New York, 2001.

[23] Andrew D. Gordon and Alan Jeffrey. Types and Effects forAsymmetric Cryptographic Proto-cols. InProc. of 15th Computer Security Foundations Workshop (CSFW’02), pages 77–91. IEEEComputer Society Press, 2002.

[24] Rydhof Rene Hansen, Jacob Grydholt Jensen, Flemming Nielson, and Hanne Riis Nielson. Ab-stract Interpretation of Mobile Ambients. In A. Cortesi andG. File’, editors,Proc. of StaticAnalysis Symposium (SAS’99), number 1694 in Lecture Notes in Computer Science, pages 134–148. Springer-Verlag, 1999.

[25] Francesca Levi and Davide Sangiorgi. Controlling Interference in Ambients. InProc. of 28thACM Symposium on Principles of Programming Languages (POPL’00), pages 352–364, 2000.

[26] G. Lowe. Casper: A Compiler for the Analysis of SecurityProtocols. InProceedings of The10th Computer Security Foundations Workshop, pages 18–30. IEEE Press, 1997.

[27] G. Lowe and B. Roscoe. Using CSP to detect Errors in the TMN Protocol. IEEE Transactionson Software Engineering, 23(10):659–669, 1997.

[28] Mantel, Heiko and Sabelfeld, Andrei A Generic Approachto the Security of Multi-threadedPrograms. In14th IEEE Computer Security Foundations Workshop. 126–144, 2001.

[29] Menezes, A. J. and van Oorschot, P. C. and Vanstone, S. A.Handbook of Applied Cryptography,CRC Press, 1997.

[30] Mitchell, J. C. and Mitchell M. and Stern, U. Automated Analysis of Cryptographic ProtocolsUsing Murphi, InProc. of the 1997 IEEE Symposium on Research in Security and Privacy,IEEE Computer Society Press, 1997.

[31] Flemming Nielson, Hanne Riis Nielson, and Chris Hankin. Principles of Program Analysis.Springer–Verlag, Berlin, 1999.

[32] Nielson, F. and Hansen, R.R., and Nielson, H.R. Abstract Interpretation of Mobile Ambients.Science of Computer Programming, 47(2-3) (May), 145-175, 2003.

[33] A. Sabelfeld and A. Myers. Language-Based Information-Flow Security. IEEE Journal onSelected Areas in Communications, 21(1):5–19, 2003.

[34] S. Schneider. Verifying authentication protocols in CSP. IEEE Transactions on Software Engi-neering, 24(9), September 1998.

[35] Volpano, Dennis and Smith, Geoffrey. Secure information flow in a multi-threaded imperativelanguage. In25th Symposium on Principles of Programming Languages,pp. 355-364, ACMPress, 1998.

18

A Representation and Specification functions of the NestingAnalysis

For the sake of completeness, we report in this Appendix the representation and specification functionof the nesting analysis in [10].

Within the specification of the analysis (depicted in Figure5), some predicates are used to enhancereadability, namely

• pathB (à, `) =

True if à = ` ∨ ∃`1, `2, . . . , `n 6∈ Laba

B : n ≥ 0∧

(à, `1), (`1, `2), . . . , (`n, `) ∈ IB & à, ` 6∈ Laba

B,

False otherwise.

• pathE (à, `) =

True if à = ` ∨ ∃`1, `2, . . . , `n 6∈ Laba

B : n ≥ 0∧

(à, `1), (`1, `2), . . . , (`n, `) ∈ IE & à, ` 6∈ Laba

B ,

False otherwise.

βB(P∗) = βBenv,False(P )

(res) βB`,Protected((νn)P ) = βB

`,Protected(P )

(zero) βB`,Protected(0) = (∅, ∅, ∅)

(par) βB`,Protected(P | Q) = βB

`,Protected(P ) t βB`,Protected(Q)

(repl) βB`,Protected(!P ) = βB

`,Protected(P )

(amb) βB`,Protected(nà

[[ P ]] ) = caseProtectedof

True :βBà,Protected(P ) t ({(`, à)} , ∅, {(à, n)})

False: if ( a ∈ LabaB) then

let Protected′

= True else Protected′

= False in

βBà,Protected

′ (P ) t (∅, {(`, à)} , {(à, n)})

(in) βB`,Protected(in

`t

n.P ) = caseProtectedof

True :βB`,Protected(P ) t ({(`, `t)} , ∅, ∅)

False:βB`,Protected(P ) t (∅, {(`, `t)} , ∅)

(out) βB`,Protected(out`

t




(open) βB`,Protected(open`t




Figure 4: Representation Function for the refined Control Flow Analysis

19

(res) (IB , IE , H) |=B (νn)P iff (IB , IE , H) |=B P

(zero) (IB , IE , H) |=B0 always

(par ) (IB , IE , H) |=B P | Q iff (IB , IE , H) |=B P ∧ (IB , IE , H) |=B Q

(repl) (IB , IE , H) |=B !P iff (IB , IE , H) |=B P

(amb) (IB , IE , H) |=B nà

[[ P ]] iff (IB , IE , H) |=B P

(in) (IB , IE , H) |=B in`t

n.P iff (IB , IE , H) |=B P ∧

∀à, à′

, à′′

∈ Laba :

case((à, `t) ∈ IB ∧ (à′′

, à) ∈ IB ∧ (à′′

, à′

) ∈ IB ∧ (à′

, n) ∈ H)

=⇒ (à′

, à) ∈ IB

case((à, `t) ∈ IB ∧ (à′′

, à) ∈ IE ∧ (à′′

, à′

) ∈ IE ∧ à ∈ LabaB ∧

(à′

, n) ∈ H) =⇒

if ( à′

∈ LabaB) then(à′

, à) ∈ IB

else(à′

, à) ∈ IE

case((à, `t) ∈ IE ∧ (à′′

, à) ∈ IE ∧ (à′′

, à′

) ∈ IE ∧ (à′

, n) ∈ H) =⇒

if ( à′

∈ LabaB)

then(à′

, à) ∈ IB ∧{

(`, `′) ∈ IE | pathE(à, `)}

⊆ IB

else(à′

, à) ∈ IE

(out) (IB , IE , H) |=B out`t


∀à, à′

, à′′

∈ Laba :

case((à, `t) ∈ IB ∧ (à′

, à) ∈ IE ∪ IB ∧ (à′′

, à′

) ∈ IE ∧ (à′

, n) ∈ H) =⇒

if ( à ∈ LabaB) then(à′′

, à) ∈ IE

else(à′′

, à) ∈ IE ∧{

(`, `′) ∈ IB | pathB(à, `)}

⊆ IE

case((à, `t) ∈ IB ∧ (à′

, à) ∈ IB ∧ (à′′

, à′

) ∈ IB ∧ (à′

, n) ∈ H)

=⇒ (à′′

, à) ∈ IB

case((à, `t) ∈ IE ∧ (à′

, à) ∈ IE ∧ (à′′

, à′

) ∈ IE ∧ (à′

, n) ∈ H)

=⇒ (à′′

, à) ∈ IE

(open) (IB , IE , H) |=B open`t


∀à, à′

∈ Laba :

case((à, `t) ∈ IE ∧ (à, à′

) ∈ IE ∧ (à′

, n) ∈ H) =⇒

if ( à′

∈ LabaB) then

{

(à, à′′

) | (à′

, à′′

) ∈ IB

}

⊆ IE ∧{

(`, `′) | (`, `′) ∈ IB ∧ (à′

, `′′

) ∈ IB ∧ pathB(`′′

, `)}

⊆ IE

else{

(à, `) | (à′

, `) ∈ IE

}

⊆ IE

case((à, `t) ∈ IB ∧ (à, à′

) ∈ IB ∧ (à′

, n) ∈ H)

=⇒{

(à, `) | (à′

, `) ∈ IB

}

⊆ IB

Figure 5: Specification of the refined Control Flow Analysis

20

1 introduction - unive.it€¦ · 1 introduction the wide diffusion of critical services, such as...

Documents