67
Type Systems for Access Control and Information Flow in Programming Languages Marija Kolundˇ zija Universit` a di Torino Universit´ e de Nice Sophia Antipolis Thesis directors: Mariangiola Dezani erard Boudol Thesis submitted for the Degree of Doctor of Philosophy Universit` a di Torino & Universit´ e de Nice Sophia Antipolis · 2008 ·

Type Systems for Access Control and Information Flow in

  • Upload
    others

  • View
    1

  • Download
    0

Embed Size (px)

Citation preview

Type Systems for Access Control and Information Flow inProgramming Languages

Marija Kolundzija

Universita di TorinoUniversite de Nice Sophia Antipolis

Thesis directors:Mariangiola Dezani

Gerard Boudol

Thesis submitted for the Degree of Doctor of PhilosophyUniversita di Torino & Universite de Nice Sophia Antipolis

· 2008 ·

И уповая буду на Него, и спасуся Им. . . .

С нами Богъ!

Abstract

This thesis explores language–based security for access control, declassification and information flow inthe context of two different languages.

In the first part, we integrate programming constructs for managing confidentiality in an ML-like impera-tive and higher-order programming language, dealing with both access control and information flow control.Our language includes in particular a construct for declassifying information, and constructs for granting,restricting or testing the read access level of a program. We introduce a type and effect system to staticallycheck access rights and information flow. We show that typable programs are secure, that is, they do notattempt at making illegal read accesses, nor illegal information leakage. This provides us with a naturalrestriction on declassification, namely that a program may only declassify information that it has the rightto read.

In the second part, we integrate security into a service–centered calculus.The growing importance of service-oriented computing has triggered development of formal computational

models for service description and orchestration. Several versions of the Service Centered Calculus (SCC)and its successor, the Calculus of Services with Pipelines and Sessions (CaSPiS) have emerged as outcomeof those studies, and are based on the notion of interaction patterns called sessions between the service andthe client who invokes it. We propose a security oriented extension of Bruni and Mezzina’s typed variant ofCaSPiS, where security levels have been assigned to service definitions, clients and data. In order to invokea service, a client must be endowed with an appropriate clearance, and once the service and client agree onthe security level, the data exchanged in the initiated session will not exceed this level. We study a typesystem that statically ensures these security properties.

Contents

Acknowledgments iv

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Integrating Access Control and Information Flow . . . . . . . . . . . . . . . . . . . . . 1

1.1.2 Security Types for a Service Calculus . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 4

2.1 Language based security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Service Calculi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Declassification and Access Control 7

3.1 The language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.1 Security (pre-)lattices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1.3 Operational Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 The type and effect system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3 Secure information flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4 Type System Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Subject Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Syntactically High Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.4.1 Soundness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

i

Behavior of “Low”-Terminating Expressions . . . . . . . . . . . . . . . . . . . . . . . . 20

Behavior of Typable Low Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Behavior of Typable Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 Security Types for Sessions and Pipelines 34

4.1 Service Oriented Calculi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1.1 Services and Security Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 The Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.2 Operational Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3 Type System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.5 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.5.1 Subject Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.5.2 Security Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.6 Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5 Conclusion 57

Bibliography 60

ii

List of Figures

3.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 The Type and Effect System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4 The relation TF,low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.5 The relation RF,low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Reduction Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3 Structural Equivalence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.4 Syntax of Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.5 Duality Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.6 Subtyping Relation ≤ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.7 Typing Rules for Inner Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.8 Function pipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.9 Typing Rules for Top Level Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.10 Typing Rules for Runtime Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.11 Consumption Relation <: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.12 Labeled Operational Semantic Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.13 Security Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

iii

Acknowledgments

I am truly grateful to my PhD supervisor Mariangiola Dezani for the availability, guidance and support she

offered me throughout my PhD studies.

Further, I would like to thank the Universita Italo-Francese / Universite Franco-Italienne for the financial

support of my PhD studies through the Vinci integrative program for conjoint PhD curriculums in French-

Italian co-tutorship.

I would also like to thank the research group on “Semantics and Logics of Computation” of the Diparti-

mento di Informatica of the Universita di Torino and the MIMOSA group from INRIA, Sophia Antipolis for

hosting me during my PhD studies.

Finally, I would like to thank my family, friends an colleagues for their affection, friendship and support

which accompanied me in happy as well as hard periods, and made the former more enjoyable, and the latter

more endurable.

iv

Chapter 1

Introduction

1.1 MotivationThis work addresses the issues of security and confidentiality in the context of “global” or “ubiquitous”computing. The processors, and consequently the software, are introduced more and more into all aspectsof everyday life. This also implies that the communication and the diffusion of information is often carriedout by average data processing, toward the subjects a priori unknown. In such a context, where “attacks” ofa new type appear (viruses, hacking, etc.), the aspects of safety become crucial. These are the aspects thatwe address in this thesis. The purpose of this work is to obtain methods of program analysis that aim atguaranteeing properties of security.

1.1.1 Integrating Access Control and Information FlowA well–known security property is the confidentiality, which ensures that a user (which can be a program)can know only the information which it has the right to access. Mechanisms of access control have for a longtime been implemented in the information processing systems. However, this control has been proven to beinsufficient [15, 24, 34] because an authorized user can disclose confidential information to other users, thusrevealing a secret. This is why the access control must be supplemented by the control of information flow.

So far, the classical way of abstractly specifying secure information flow is to use a lattice of securitylevels [15]. The “objects” – information containers – of a system are then labeled by security levels, andinformation is allowed to flow from one object to another if the source object has a lower confidentialitylevel than the target one. That is, the ordering relation on security levels determines the legal flows, and aprogram is secure if, roughly speaking, it does not set up illegal flows from inputs to outputs. This was firstformally stated via a notion of strong dependency, which is most often referred to as non-interference.There is still a number of issues to investigate in order to make the techniques developed following thelanguage–based approach to information-flow security useful in practice. One of the challenges is declassi-fication. Indeed, there are many useful programs that need to declassify information, from a confidentialstatus to a less secret one. A typical example is a password checking procedure, which delivers to any userthe result of comparing a submitted password with secret information contained in a database, thus leak-ing a bit of confidential information. Such a program is, by definition, ruled out by the non–interferencerequirement, which is therefore too strong to be used in practice. The problem of taking into account de-classifying programs in checking secure information flow has recently motivated a lot of work [1, 3, 30, 31, 36].

In a paper by Almeida Matos and Boudol [3], the authors have introduced a programming constructfor managing declassification, that consists in declaring flow policies with a local scope thus defining a new

1

2 1.1 Motivation

confidentiality policy, called the non-disclosure policy, that generalizes non-interference while allowing oneto deal with declassification.

There is no constraint on using the declassification construct in [3], and this is in contrast with most otherstudies, which aim at restricting the use of such an operation (sometimes without justifying such constraints,for lack of a corresponding extensional notion of security). By putting access control into the picture, wehave provided a natural way to restrict declassification, namely: a program may only declassify informationthat it has the right to read.

In order to do this, we have integrated into the language a formal approach to access control thathas recently been introduced to deal with the “stack inspection” mechanism of Java security architecture[19, 33, 38]. That is, we add to the language of [3] the constructs for managing access control: restricting,augmenting and testing of the access rights enforced by the context.

Our main results are, first, a type safety property showing that access control is indeed ensured bythe type system, that is, a typable program never attempts to read a reference for which it would notbe granted the appropriate reading clearance. Second, we extend the soundness result of [3], showing thatsecure information flow is ensured by our type system. In this way, we achieve the enforcement of “end-to-endconfidentiality” in our language, while restricting declassification in a natural way.

This part of the thesis is an expanded version of [10].

1.1.2 Security Types for a Service CalculusPopularity of communication centered applications distributed over the web (web services) has provokedurgent interest in the development of automatic tools to assure safe uses of these applications. ServiceOriented Computing (SOC) has emerged as a new computational paradigm. Services are heterogeneouscomputational entities, that are developed separately and often are scarcely reliable. Each service has fullautonomy in denying a request or abandoning a pending interaction, therefore, a language for SOC shouldfix some standard mechanism for programming such decisions and to handle their consequences. A languagefor SOC should support programming of complex and safe client-service interactions. By interaction, wemean the main unit of activity in a service-oriented application, which is essentially a conversation betweena client and an instance of a service. The interaction may be complex as it will in general comprise boththe exchange of several messages and the invocation of subsidiary services. Orchestration is the process ofassembling different services to build a new one or simply to perform a specific computation. A central aspectof orchestration is the organization of the data flow among different activities. This flow also determinessynchronization of activities.

A lot of research has been done in this direction, and as a consequence, various process calculi have beendesigned to model service behaviour (see for example the references in [9]).

An interesting proposal is the Calculus of Services with Pipelines and Sessions (CaSPiS) [9], which is adataflow–oriented successor of the Service Centered Calculus (SCC) [8]. In both these calculi communicationscan either follow fixed protocols (session) between clients and services, or be disciplined data flows (pipelines).

The pipeline constructor of CaSPiS was first introduced in [22]. In [21], the authors have proposed thesession as a language construct for communication based programming.

There are also various type disciplines for calculi originated from SCC [25, 26] and in particular for minormodifications of CaSPiS [2, 12]. In both typed versions of CaSPiS the communications between parallelprocesses are controlled by session types, which are lightweight descriptions of protocols first used in [21].The typed versions of CaSPiS have safe communications, since they enjoy the subject reduction and theprogress property (formalized in [18, 17]). Surprisingly, little work has been done to address security issuesin the session–type setting. The authors of [7] have proposed correspondence assertions as means of control ofdata propagation over multiple parties. However, to the best of our knowledge, no notion of secrecy has beenconsidered so far, and therefore no assurance that private data will never become visible to unauthorizedbodies can be given.

3 1.1 Motivation

The second part of this thesis tries to fill this gap by building on well-known typing techniques forcontrolling access rights [39, 4, 38, 33, 19, 10].

From an access control point of view, clients are regarded as “subjects”, and services and basic valuesas “objects”. Therefore, a client is required to possess an appropriate clearance to activate a service or tocommunicate a value. On the other hand, services are regarded as trusted entities, and they are allowed toact on behalf of the client who invoked them (this is reflected in the operational semantics, where the bodyprocess of the service definition “inherits” the clearance from the client after the activation).

We have developed a type system, which ensures at compile time that a service can be activated only byclients with appropriate clearance, while preserving the safety and progress properties of previous versionsof CaSPiS.

This part of the thesis is an expanded version of [23].

Chapter 2

Background

Early work on the confidentiality problem developed mandatory access control [16]. In this approach, eachdata item is labeled with a corresponding security level that is a simple confidentiality policy. Information flowis controlled by augmenting the ordinary computation of data within a running program with a simultaneouscomputation of the corresponding label that controls its future dissemination. This approach, prescribedby the U.S. Department of Defense “orange book” for secure systems, has proved to be too restrictive forgeneral use. It’s additional weakness was its inability to track implicit information flows, the so–called covertchannels.

Further research has come up with static analysis techniques for controlling information flow. Thesetechniques provided a more precise information flow control at compile-time, hence eliminating the run-timeoverhead.

In the type-checking approach, every program expression has a two-part security type: a basic type(such as boolean or integer, for example), and a static label which defines an information-flow policy onthe use of the labeled data. Security is enforced by type checking; the compiler reads a program containinglabeled types, and while performing the typechecking procedure, it ensures that the program cannot containimproper information flows at run time.

2.1 Language based securityThis thesis focuses on language–based techniques (program semantics and analysis) [41, 34] for the specifi-cation and enforcement of security policies for data confidentiality.

The standard security mechanisms are unsatisfactory for protecting confidential information in the emerg-ing, large networked information systems (such as military, medical, and financial information systems, aswell as web-based services such as mail, shopping, and business-to-business transactions are applications).The privacy issues which arise in these large-scale systems have not yet been adequately addressed.

There are many aspects to be taken into account when asserting confidentiality properties of a system -from unintentional omissions in the design or implementation to interaction with untrusted (and potentiallymalicious) entities.

The standard way to protect confidential data used to be (discretionary) access control: some privilegeis required in order to access files or objects containing the confidential data. When data is released from itscontainer, the access control mechanism asserts that data has been released to a privileged entity. However,access control mechanism has no power over the propagation of the released data - once it has been takenover by the program, the program could - intentionally or accidentally - transmit it to an untrusted entity.To ensure that information is used only in accordance with the relevant confidentiality policies, it is necessary

4

5 2.2 Service Calculi

to analyze how information is propagated within the using program.A system is said to be secure with respect to confidentiality as a result of a rigorous analysis that

asserts that the system enforces the confidentiality policies of its users. This analysis must show thatinformation controlled by a confidentiality policy cannot flow to a location where that policy is violated.Information–flow policies are a natural way to apply the well-known systems principle of end-to-end designto the specification of computer security requirements; therefore, we also consider them to be specificationsof end-to-end security. In a truly secure system, these confidentiality policies could be precisely expressedand translated into mechanisms that enforce them.

An approach to practical methodology for enforcement of information-flow policies that has been devel-oped by the research community is the use of type systems for controlling information flow [11, 13, 30, 27,31, 34]. In a security-typed language, the types of program variables and expressions are augmented withannotations that specify policies on the use of the typed data.

These security policies are then enforced by compile-time type checking, and, thus, add little or no run–time overhead. Like ordinary type checking, security–type checking is also inherently compositional: securesubsystems combine to form a larger secure system as long as the external type signatures of the subsystemsagree. The recent development of semantics based security models (i.e., models that formalize security interms of program behavior) has provided powerful reasoning techniques about the properties that security-type systems guarantee. These properties increase security assurance because they are expressed in terms ofend-to-end program behavior and, thus, provide a suitable vocabulary for end-to-end policies of programs.

2.2 Service CalculiAn important group of calculi for modeling and proving properties of services is the one based on the explicitnotion of session [21]. A session corresponds to a private channel that is instantiated when calling a service:it binds caller and callee and is used for their communication.

To manage inter-session communication, different mechanisms have been proposed that are at the momentunder evaluation. The first model was a single core calculus (SCC) [8], whose successors are variants thathave branched on different inter-session communication mechanisms. SCC has been influenced by Cook andMisra’s Orc [22], a basic programming model for structured orchestration of services, and by π–calculus [29],the by now classical representative of name passing calculi. Indeed one could say that SCC combines theservice oriented flavour of Orc with the name passing communication mechanism of π–calculus. In particular,Orc has been appealing to us because of its simplicity and yet great generality: its three basic compositionoperators can be used to model the most common workflow patterns; SCC emerged as a result of combiningdescriptive power similar of Orc but with the mathematical cleanness of π–calculus.

SCC supports explicit modeling of sessions that are rendered as private bi–directional channels createdupon services invocation and used to bind caller and callee. The interaction is programmed by two com-munication protocols installed at each side of the bi-directional channel. This session mechanism permitsdescribing and reasoning about interaction patterns that are more structured than the classical one–way andrequest-response pattern. Essentially, SCC is a name passing process calculus with explicit notions of servicedefinition, service invocation and bi-directional sessioning.

Within SCC, services are seen as sort of interacting functions (and even stream processing functions) thatcan be invoked by clients. A service invocation causes activation of a new session. Client and service protocolsare then instantiated each at the proper side of the session. More generally, within sessions communicationis bi–directional, in the sense that the interacting protocols can exchange data in both directions. Valuesreturned outside the session to the enclosing environment can be used for invoking other services.

The original proposal of SCC was somehow unsatisfactory with respect to the handling of intersessioncommunications, thus variants of SCC that make use of different communication mechanisms have been putforward.

6 2.2 Service Calculi

• CaSPiS [9] is dataflow oriented and makes use of a pipelining operator (a la ORC) to model the passageof information between sessions; return is used by sessions for passing values to the environment.

• SSCC [25] is stream oriented and has primitives for inserting/retrieving data in/from streams that areused both for inter-session communication and for communication with the environment.

• CSCC [26] is message oriented and has explicit and distinct message passing primitives to model interand intra session communication and for communicating with the environment.

CaSPiS is variant of SCC that is dataflow oriented and makes use of a pipelining operator to model thepassage of information between sessions. Specific care is devoted to formal semantics and minimality of theoperators. A session is a chain of dyadic interactions whose collection constitutes a program. Services areseen as passive objects that can be invoked by clients and service definitions can be seen as specific instancesof input prefixed processes. The two endpoints of the same session can communicate by exchanging messages.A fresh shared name is used to guarantee that messages are exchanged only between partners of the samesession, so that two instances of the same persistent service (that was invoked from two different sessions)run separately and cannot interfere. The central role assigned to sessions and the direct use of operatorsfor modeling sessions interaction renders the logical structure of programs more clear and leads to a welldisciplined service specification language that enable us to guarantee proper handling of session closures andin general simplifies reasoning on the specified services.

Chapter 3

Declassification and Access Control

We shall address combining access control and information flow in the presence of declassification. Thepurpose is to introduce, in an imperative (higher-order) lambda-calculus with thread and reference creation,a flow declaration construct that locally extends the global flow policy, thus providing a mechanism forexpressing declassification within the scope of the declaration, constructs for constraining, enabling andtesting access rights.

Then we present the non–disclosure policy dependent on the access privilege, and show that introductionof access control adds a way of restricting declassification – a program can declassify only what it has theright to read.

We present a type and effect system for enforcing this policy.

3.1 The language

3.1.1 Security (pre-)latticesThe security levels are hierarchically organized in a pre-lattice, a structure defined as a pair (L,�), where �is a preorder relation over the set L, that is a reflexive and transitive, but not necessarily symmetric relation,such that for any x, y ∈ L there exist a meet x f y and a join x g y satisfying:

x f y � x x � x g y

x f y � y y � x g y

z � x & z � y ⇒ z � x f y x � z & y � z ⇒ x g y � z

The pre-lattices we use are defined as follows. We assume given a set Pri of principals, ranged over by p, q . . .(From an access control perspective, these are also called permissions [5, 19], or privileges [33, 38], while a“principal” is a set of permissions.) A confidentiality level is any set of principals, that is any subset ` of Pri .The intuition is that whenever ` is the confidentiality label of an object, i.e. a reference, it represents a setof programs that are allowed to get the value of the object, i.e. to read the reference. Then a confidentialitylevel is similar to an access-control list (i.e. a set of permissions). From this point of view, a reference labelledPri (also denoted ⊥) is the most public one – every program is allowed to read it – whereas the label ∅(also denoted >) indicates a secret reference, and reverse inclusion of security levels may be interpreted asindicating allowed flows of information: if a reference u is labelled `, and ` ⊇ `′, then the value of u may betransferred to a reference v labelled `′, since the programs allowed to read this value from v were alreadyallowed to read it from u.

We follow the approach of [3], where declassification is achieved by dynamically updating the lattice

7

8 3.1 The language

M, N . . . ∈Exp ::= V | if M then N else N ′ | (MN) expressions| M ; N | (ref`,θ N) | (! N) | (M := N)

| (` n M) | (enable ` in M) | (test ` then M else N)

| (flow F in M)

V ∈ Val ::= x | u`,θ | %x.M | λx.M | true | false | () values

Figure 3.1: Syntax

structure of confidentiality levels, by the means of local flow policies. A flow policy is a binary relation overPri . We let F , G . . . range over such relations. A pair (p, q) ∈ F is to be understood as “information mayflow from principal p to principal q”, that is, more precisely, “everything that principal p is allowed to readmay also be read by principal q”. As a member of a flow policy, a pair (p, q) will be written p ≺ q. We denote,as usual, by F ∗ the preorder generated by F (that is, the reflexive and transitive closure of F ). Any flowpolicy F determines a preorder on confidentiality levels that extends reverse inclusion, as follows:

` �F `′ ⇔def ∀q ∈ `′. ∃p ∈ `. p F ∗ q

It is not difficult to see that the preorder �F induces a pre-lattice structure on the set of confidentialitylevels, where a meet is simply the union, and a join of ` and `′ is

{ q | ∃p ∈ `. ∃p′ ∈ `′. p F ∗ q & p′ F ∗ q }

This observation justifies the following definition.Definition (Security Pre-Lattices) 1.1. A confidentiality level is any subset ` of the set Pri ofprincipals. Given a flow policy F ⊆ Pri×Pri, the confidentiality levels are pre-ordered by the relation

` �F `′ ⇔def ∀q ∈ `′. ∃p ∈ `. p F ∗ q

The meet and join, w.r.t. F , of two security levels ` and `′ are respectively given by ` ∪ `′ and` gF `′ = { q | ∃p ∈ `. ∃p′ ∈ `′. p F ∗ q & p′ F ∗ q }.

3.1.2 SyntaxThe syntax of the language considered in this chapter is given in Figure 3.1. The language is a higher-order λ–calculus, extended with imperative constructs of ML, conditional branching and boolean values.The language is further enriched with constructs for dynamic manipulation and testing of access rights([5, 19, 33, 38]), and dynamic extension of the flow policy ([3]).The language consists of expressions and values, where values are the expressions that cannot be furthercomputed. The values include variables, functions, boolean values true and false, memory references and anil command (), used to denote inactivity.The expressions include:conditional branching if M then N else N ′ on a boolean value M , which executes N or N ′, depending onevaluation of M being true or false;application (MN) of function obtained by evaluation of M to the result of evaluation of N ;the sequential composition M ; N , which executes N after the termination of M ;reference creation (ref`,θ N), which creates a new memory location of type θ and with a security level `in which the value obtain by evaluation of N is written;dereferencing (! N), which reads the reference obtained by evaluation of N ;

9 3.1 The language

(IfT) ` `G (E[if true then M else N ], µ) → (E[M ], µ)

(IfF) ` `G (E[if false then M else N ], µ) → (E[N ], µ)

(App) ` `G (E[(λx.MV )], µ) → (E[{x 7→ V }M ], µ)

(Rec) ` `G (E[(%x.M)], µ) → (E[{x 7→ %x.M}M ], µ)

(Seq) ` `G (E[V ; N ], µ) → (E[N ], µ)

(Ref) ` `G (E[(ref`′,θ V )], µ) → (E[u`′,θ], µ ∪ [u`′,θ/V ]) u fresh for µ

(Deref) ` `G (E[(! u`′,θ)], µ) → (E[V ], µ) µ(u`′,θ) = V &`′ �G bEc`

(Assign) ` `G (E[(u`′,θ := V )], µ) → (E[()], µ[u`′,θ := V ])

(Sign) ` `G (E[(`′ n V )], µ) → (E[V ], µ)

(Enable) ` `G (E[(enable `′ in V )], µ) → (E[V ], µ)

(TestT) ` `G (E[(test `′ then M else N)], µ) → (E[M ], µ) `′ �G bEc`

(TestF) ` `G (E[(test `′ then M else N)], µ) → (E[N ], µ) `′ 6�G bEc`

(Flow) ` `G (E[(flow F in V )], µ) → (E[V ], µ)

Figure 3.2: Reduction

reference updating (M := N), which updates the reference obtained by evaluation of M with the resultof evaluation of N ;access restriction (` n M) (inspired by the “framed” expressions of [19], and by the “signed” expressionsof [33]), used to restrict the access right of M to `; this is a scoping construct: the current reading clearanceis restored after termination of M ;access extension (enable ` in M), used to locally extend the read access right of M by `; it is also a scopingconstruct;local flow declaration (flow F in M), which enables extension of the current flow policy by a local policyF while reducing M , usually for declassification purposes.

A reference is a memory location u to which a confidentiality level ` is assigned. For technical reasons,we also record the type θ (see Section 3 below) of the contents of the reference.We denote by loc(M) the set of decorated locations u`,θ occurring in M . These references are regarded asproviding the inputs of the expression M . We let fv(M) be the set of variables occurring free in M , and wedenote by [x/V ]M the capture-avoiding substitution of V for the free occurrences of x in M , where V ∈ Val .As usual, (let x = N in M) denotes (λx.MN).

3.1.3 Operational SemanticsMemory, or heap, ranged by µ, ν, is defined as a mapping mapping from a finite set dom(µ) of references tovalues.The reduction relation is a transition relation between configurations of the form (M,µ) where M is anexpression, and µ is the memory.The operation of updating the value of a reference in the memory is denoted as µ[u`,θ := V ]. We say thatthe name u is fresh for µ if v`,θ ∈ dom(µ) ⇒ v 6= u.In what follows we shall only consider well-formed configurations, that is pairs (M,µ) such that loc(M) ⊆dom(µ) and for any u`,θ ∈ dom(µ) we have loc(µ(u`,θ)) ⊆ dom(µ) (this property will be preserved by the

10 3.1 The language

operational semantics).The operational semantics consists in reducing a redex (reducible expression) inside an evaluation context(see [40]).Reducible expressions are given by the following grammar:

R := if true then M else N | if false then M else N | (%x.M) | (λx.MV )

| V ; N | (ref`,θ V ) | (! u`,θ) | (u`,θ := V )

| (` n V ) | (enable ` in V ) | (test ` then M else N)

| (flow ` in V )

Evaluation contexts are defined as expression shapes that contain a special expression called a hole, thatdetermines the precedence of reduction. The grammar for evaluation contexts is as follows:

E ::= [] | E[F] evaluation contextsF := if [] then M else N | ([]N) | (V []) frames

| [] ; N | (ref`,θ[]) | (! []) | ([] := N) | (V := [])

| (` n []) | (enable ` in []) | (flow F in [])

The operational semantics of an expression depends upon a given global flow policy G and a default con-fidentiality level `, which represents the access right assigned to the evaluated expression – as if we had toevaluate (⊥n (enable ` in M)). Then the statements defining the operational semantics have the form

` `G (M, µ) → (M ′, µ′)

Given a global flow policy G, for any confidentiality level ` representing the current access level, we definethe level granted by the evaluation context E, denoted bEc`, as follows:

b[]c` = `

bE[F]c` =

8><>:(bEc`) fG `′ if F = (`′ n [])

(bEc`) gG `′ if F = (enable `′ in [])

bEc` otherwise

Computing bEc` is a form of “stack inspection,” see [19, 33, 38].We will also be using the flow policy dEe granted by the evaluation context E, which is defined as follows:

d[]e = ∅

dE[F]e =

(dEe ∪ F if F = (flow F in [])

dEe otherwise

The reduction rules are given in Figure 3.2. They are fairly standard, as regards the functional andimperative fragment of the language. One may observe that (flow F in M) behaves exactly as M , and thatthe semantics of the constructs for managing access rights are as one might expect, given the definition ofbEc` above. We denote by ∗→ the reflexive and transitive closure of the reduction relation. More precisely,we define:

` `G (M, µ)∗→ (M, µ)

` `G (M, µ)∗→ (M ′′, µ′′) ` `G (M ′′, µ′′) → (M ′, µ′)

` `G (M, µ)∗→ (M ′, µ′)

In order to prove certain properties of the type system presented in Section 3.2, we will need to refer tothe “current” flow policy or the “current” access right, i.e. the local flow policy or access right that holdsfor the current computation step, and is imposed by the evaluation context. To facilitate this reference, weintroduce the decorated reduction relation, of the form ` `G (M,µ) −→

F(M ′, µ′) and ` `G (M,µ)

−→ (M ′, µ′),

11 3.1 The language

where F is the flow policy and is the access right that holds for the current this step. More precisely wedefine:

` `G (R,µ) → (M,µ′)

` `G (E[R], µ)bEc`−−−→ (E[M ], µ′)

` `G (R,µ) → (M,µ′)

` `G (E[R], µ) −−→dEe

(E[M ], µ′)

provided that R is any redex.An expression is said to converge if, regardless of the memory, its evaluation terminates on a value, that

is:M⇓ ⇔def ∀µ ∃V ∈ Val ∃µ′. (M, µ)

∗→ (V, µ′)

One can see that a constraint that could block the reduction is the dynamic checking of read access rights,that is the condition `′ �G bEc` when reading a reference u`′,θ in the memory, with ` as the given readingclearance. (Since we are only considering well-formed configurations, the value µ(u`′,θ) is always defined.)Indeed for instance the expression (omitting the types attached to references)

(flow H ≺ L in vL := ! uH)

is blocked if the current access right is {L}, and can only proceed if this right is at least {H}. This indicatesthat, using (flow F in M), one can only declassify information that one has the right to read. This is becausethe local flow policy declarations do not interfere with access control, i.e. they do not play any role in thedefinition of bEc`. More generally, to let information flow, such as in v`′ := ! u`, a program must have theright to read it.

One can easily check the usual property (see [40]) that, given a pair (`,G), a closed expression is eithera value, or a reducible expression, or is a faulty expression, either for typing reasons, or because it does nothave the appropriate access rights, that is:

Lemma 3.1.1 Let M be a closed expression. Then, for any ` and G, either M ∈ Val , or for any µ thereexist F , M ′ and µ′ such that ` `G (M,µ) −→ (M ′, µ′), or M is (`,G)-faulty, that is:(i) M = E[if V then N else N ′] and V 6∈ {true, false}, or(ii) M = E[(V V ′)] and V is not a functional value λx.M ′, or(iii) M = E[(! V )] or M = E[(V := V ′)] where V is not a reference u`′,θ, or(iv) M = E[(! u,θ)] with 6�G bEc`.

A key property of our calculus is that by reducing the same expression is two different memories, if weobtain different expressions but the new memory locations created by the reduction coincide, then the redexwas a dereferencing and the memories are unchanged.

Lemma 3.1.2 (Splitting Computations) If ` `G (M,µ1) → (M1, µ′1) and ` `G (M,µ2) → (M2, µ

′2),

with M1 6= M2, and dom(µ′1) − dom(µ1) = dom(µ′2) − dom(µ2), then there exist E and u,θ, such thatM = E[! u,θ], and M1 = E[µ1(u,θ)], M2 = E[µ2(u,θ)], with µ1 = µ′1 and µ2 = µ′2.

The condition dom(µ′1)−dom(µ1) = dom(µ′2)−dom(µ2) is necessary for the validity of previous lemma,take for example ` `G (ref`′,θ V, µ) → (u`′,θ, µ ∪ [u`′,θ/V ]) and ` `G (ref`′,θ V, µ) → (v`′,θ, µ ∪ [v`′,θ/V ]).

We conclude this section by two examples that illustrate the (decorated) reduction relation.

12 3.2 The type and effect system

Example 3.1.1 The first example shows the local behaviour of the flow construct. We consider the reductionof the process:

(test {p} then (flow p ≺ q in v{q},θ := ! u{p},θ) else ())

assuming that p ∈ `, µ(u{p}) = V , V being of type θ, and omitting θ from the reference decoration.

(1) ` `G ((test {p} then (flow p ≺ q in v{q} := ! u{p}) else ()), µ) −→ (TestT)(2) ` `G ((flow p ≺ q in v{q} := ! u{p}), µ) −−−−→

{p≺q}(Deref)

(3) ` `G ((flow p ≺ q in v{q} := V ), µ) −−−−→{p≺q}

(Assign)

(4) ` `G ((flow p ≺ q in ()), µ[v{q} := V ]) −→ (Flow)(5) ` `G ((), µ[v{q} := V ]).

Example 3.1.2 This is an example of an expression with dynamic use of the test construct. We considerthe reduction of the process:

let x = λy(test ı then vı := ! uı else ()) in

if ! u′` then (enable ı in x()) else x()

assuming that µ(uı) = V , V and all of the references are of type θ, ` � ı and µ(u′`) = true.

(1) ` `G (let x = λy(test ı then vı := ! uı else ()) in if ! u′` then (enable ı in x()) else x(), µ) −→ (App)(2) ` `G (if ! u′` then (enable ı in λy(test ı then vı := ! uı else ())()) else λy(test ı then vı := ! uı else ())(), µ) −→ (Deref)(3) ` `G (if true then (enable ı in λy(test ı then vı := ! uı else ())()) else λy(test ı then vı := ! uı else ())(), µ) −→ (IfT)

(4) ` `G ((enable ı in λy(test ı then vı := ! uı else ())()), µ)`gGı−−−−−→ (App)

(5) ` `G ((enable ı in (test ı then vı := ! uı else ())), µ)`gGı−−−−−→ (TestT)

(6) ` `G ((enable ı in vı := ! uı), µ)`gGı−−−−−→ (Deref)

(7) ` `G ((enable ı in vı := V ), µ)`gGı−−−−−→ (Assign)

(8) ` `G ((enable ı in ()), µ[vı := V ]) −→ (Enable)(9) ` `G ((), µ[vı := V ])

3.2 The type and effect systemOur main aim in this chapter is to show that we can design a type system that guarantees both secureinformation flow, as in [3], and, as in [5, 33], the fact that a well-typed expression is never stuck, andtherefore that the run-time checking of the access rights is useless for such expressions.

Our type system elaborates on the one of [3], and, as such, is actually a type and effect system [28]. This isconsistent with our “state-oriented ” approach – as opposed to the “value-oriented” approach of [19, 32, 33, 38]for instance – where only the access to the “information containers”, that is, to the references in the memory,is protected by access rights. In particular, a value is by itself neither “secret” nor “public,” and the typesdo not need to be multiplied by the set of confidentiality levels. Then the types are

τ, σ, θ . . . ::= bool | unit | θ ref` | (τs−−→

`,Fσ)

where s is any “security effect” – see below. Notice that a reference type θ ref` records the type θ of valuesthe reference contains, as well as the “region” ` where it is created, which is the confidentiality level at whichthe reference is classified. Since a functional value wraps a possibly effectful computation, its type recordsthis latent effect [28], which is the effect the function may have when applied to an argument. It also recordsthe “latent reading clearance” ` and the “latent flow policy” F , which are assumed to hold when the functionis called.

The judgements of the type and effect system have the form

`; F ; Γ `G M : s, τ

where Γ is a typing context, assigning types to variables, and s is a security effect, that is a triple (`0, `1, `2)

13 3.2 The type and effect system

`; F ; Γ `G u`′,θ : ⊥, θ ref`′

(Loc)`; F ; Γ, x : τ `G x : ⊥, τ

(Var)

`; F ; Γ, x : τ `G M : s, σ

`′; F ′; Γ `G λx.M : ⊥, (τs−−→

`,Fσ)

(Abs)`; F ; Γ `G () : ⊥, unit

(Nil)

`; F ; Γ `G tt : ⊥, bool(BoolT)

`; F ; Γ `G ff : ⊥, bool(BoolF)

`; F ; Γ `G M : s, bool `; F ; Γ `G Ni : si, τ s.r �F ∪G s0.w ∪ s1.w

`; F ; Γ `G if M then N0 else N1 : s g s0 g s1 g (⊥,>, s.r), τ(Cond)

`; F ; Γ `G M : s, τs′−−−→

`′,F ′σ `′ �G ` s.t �F ∪G s′′.w

`; F ; Γ `G N : s′′, τ s.r g s′′.r �F ∪G s′.w

`; F ∪ F ′; Γ `G (MN) : s g s′ g s′′ g (⊥,>, s.c g s′′.c), σ(App)

`; F ; Γ `G M : s, τ `; F ; Γ `G N : s′, σ s.t �F ∪G s′.w

`; F ; Γ `G M ; N : (⊥, s.w, s.t) g s′, σ(Seq)

`; F ; Γ `G M : s, θ s.r �F ∪G `′

`; F ; Γ `G (ref`′,θ M) : (⊥, s.w ∪ `′, s.t), θ ref`′

(Ref)`; F ; Γ `G M : s, θ ref`′ `′ �G `

`; F ; Γ `G (! M) : s g (`′,>,⊥), θ(Deref)

`; F ; Γ `G M : s, θ ref`′ s.t �F ∪G s′.w

`; F ; Γ `G N : s′, θ s.r g s′.r �F ∪G `′

`; F ; Γ `G (M := N) : (⊥, s.w ∪ s′.w ∪ `′, s.t g s′.t), unit(Assign)

` fG `′; F ; Γ `G M : s, τ

`; F ; Γ `G (`′ n M) : s, τ(Restric)

` gG `′; F ; Γ `G M : s, τ

`; F ; Γ `G (enable `′ in M) : s, τ(Enable)

`′; F ; Γ `G M : s, τ `; F ; Γ `G N : s′, τ

`; F ; Γ `G (test `′ then M else N) : s g s′, τ(Test)

`; F ; Γ, x : τ `G W : s, τ

`; F ; Γ `G %x.W : s, τ(Rec)

`; F ∪ F ′; Γ `G M : s, τ s.c �F ∪F ′ ∪G c s.t �F ∪F ′ ∪G t

`; F ; Γ `G (flow F ′ in M) : (c, s.w, t), τ(Flow)

Figure 3.3: The Type and Effect System

of confidentiality levels. The intuition is:

• ` is the current read access right that is in force when reducing M ;

• F is the current flow policy, while G is the given global flow policy;

• `0, also denoted by s.c, is the confidentiality level of M . This is an upper bound (up to the currentflow relation) of the confidentiality levels of the references the expression M reads that may influence

14 3.2 The type and effect system

its resulting value;

• `1, also denoted s.w, is the writing effect, that is a lower bound (w.r.t. the relation �) of the level ofreferences that the expression M may update;

• `2, also denoted s.t, is an upper bound (w.r.t. the current flow relation) of the levels of the referencesthe expression M reads that may influence its termination. We call this the termination effect of theexpression.

In the following we shall denote s.cgF ∪Gs.t by s.r, assuming that F and G are understood from the context.According to the intuition above, the security effects s = (c, w, t) are ordered componentwise, in a

covariant manner as regards the confidentiality level c and the termination effect t, and in a contravariantway as regard the writing effect w. Then we abusively denote by ⊥ and > the triples (⊥,>,⊥) and (>,⊥,>)respectively. In the typing rules for compound expressions, we will use the join operation on security effects:

s gF s′ =def (s.c gF s′.c, s.w ∪ s′.w, s.t gF s′.t)

as well as the following convention:Convention. In the type system, when the security effects occurring in the context of a judgement`;F ; Γ `G M : s, τ involve the join operation g, it is assumed that the join is taken w.r.t. F ∪ G, i.e. it isgF ∪G. We recall that by s.r we mean s.c gF ∪G s.t.

The typing system is given in Figure 3.3. Notice that this system is syntax-directed: there is exactly onerule per construction of the language. In particular, there is no subtyping rule. As an example, we infer thetypes for the expressions of Example 3.1.1 and Example 3.1.2.

Example 3.2.1 For the expression:

(test {p} then (flow p ≺ q in v{q} := ! u{p}) else ())

if F = G ∪ {p ≺ q}, the typing is as follows:

{p}; F ; Γ `G u{p},θ : ⊥, θref{p}

{p}; F ; Γ `G (! u{p},θ) : ({p},>,⊥), θRef {p}; F ; Γ `G v{q},θ : ⊥, θref{q} p �F q

{p}; F ; Γ `G v{q},θ := ! u{p},θ : (⊥, {q},⊥), unitAssign

{p}; G; Γ `G (flow p ≺ q in v{q},θ := ! u{p},θ) : (⊥, {q},⊥), unitFlow ı; G; Γ `G () : ⊥, unit

`; G; Γ `G (test {p} then (flow p ≺ q in v{q},θ := ! u{p},θ) else ()) : (⊥, {q},⊥), unitTest

Example 3.2.2 For space reasons we split the typing of the expression:

let x = λy(test ` then v` := ! u` else ()) in

if M then (enable ` in x()) else x()

and we put τ = unit(⊥,ı,⊥)−−−−−→

`,Gunit

ı; G; Γ, y : unit `G uı : ⊥, θrefı

ı; G; Γ, y : unit `G (! uı) : (ı,>,⊥), θ

Deref ı; G; Γ, y : unit `G vı : ⊥, θrefı

ı; G; Γ, y : unit `G vı := ! uı : (⊥, ı,⊥), unit

Assign ı; G; Γ, y : unit `G () : ⊥, unit

`; G; Γ, y : unit `G (test ı then vı := ! uı else ()) : (⊥, ı,⊥), unit

Test

`; G; Γ `G λy(test ı then vı := ! uı else ()) : ⊥, τ

Abs

15 3.3 Secure information flow

` gG ı; G; Γ, x : τ `G x : ⊥, τ ` gG ı; G; Γ `G () : ⊥, unit

` gG ı; G; Γ, x : τ `G: x() : (⊥, ı,⊥), unit

App

`; G; Γ, x : τ `G (enable ı in x()) : (⊥, ı,⊥), unit

Enable `; G; Γ, x : τ `G () : ⊥, unit

`; G; Γ, x : τ `G u′ı : ⊥, boolrefı

`; G; Γ, x : τ `G ! u′ı : (ı,>,⊥), bool

Deref

`; G; Γ, x : τ `G if ! u′` then (enable ı in x()) else x() : (ı, ı,⊥) : unit

Cond

`; G; Γ `G λx if ! u′` then (enable ı in x()) else x() : ⊥, τ(ı,ı,⊥)−−−−−−→

`,Gunit

Abs

Finally, we type the application:

`; G; Γ `G λx if ! u′` then (enable ı in x()) else x() : ⊥, τ(ı,ı,⊥)−−−−−→

`,Gunit `; G; Γ `G λy(test ı then vı := ! uı else ()) : ⊥, τ

`; G; Γ `G (λx if ! u′` then (enable ı in x()) else x())(λy(test ı then vı := ! uı else ())) : (ı, ı,⊥), unitApp

Compared to the system of [3], which does not involve constructs for managing access control, the maindifference is in the (Deref) rule, where we have the constraint that the level of the reference that is readshould be less than the access level granted by the context. Notice that this constraint only involves theglobal flow policy G, not the local one F . This is the way to ensure that declassification does not modify theaccess rights. There is a similar constraint in the rule for typing application, where the access level requiredby the (body of the) function should indeed be granted by the context. It is easy to see that typing enjoys a“weakening” property, asserting that if an expression is typable in the context of some access right `, then itis also typable in the context of a more permissive reading clearance. Similarly, one could show that relaxing(that is, extending) the global or local flow policy does not affect typability.

Lemma 3.2.1

• If `;F ; Γ `G M : s, τ and ` �G `′, then `′;F ; Γ `G M : s, τ .

• If `;F ; Γ `G M : s, τ , then `;F ; Γ `G∪G′ M : s, τ .

• If `;F ; Γ `G M : s, τ , then `;F ∪ F ′; Γ `G M : s, τ .

Proof: By induction on the inference of the typing judgemnent.

3.3 Secure information flowIn [3], the authors have proposed a generalization of the usual non-interference property that allows one todeal with declassification. The idea is to define a program as secure if it satisfies a “local non-interference”property, called the non-disclosure policy, which roughly states that the program is, at each step of itsexecution, non-interfering with respect to the current flow policy, that is the global flow policy extended bythe one granted by the evaluation context. Technically, a program will be considered as secure if it is bisimilarto itself. As usual, this property relies on preserving the “low equality” of memory. Roughly speaking, twomemories are equal up to level ` if they assign the same value to every location with security level lower than`, with respect to a given flow policy. In order to deal with reference creation, we only compare memorieson the domain of references they share – then the “low equality” of memory is actually not an equivalence(it is not transitive). Nevertheless, we keep the standard terminology. The “low equality” of memories, withrespect to a current flow policy F , and to a security level ` regarded as “low,” is thus defined:

µ lF,` ν ⇔def ∀u`′,θ ∈ dom(µ) ∩ dom(ν). `′ �F ` ⇒ µ(u`′,θ) = ν(u`′,θ)

From an information flow point of view, the notion of a secure program actually depends on the currentaccess right. For instance, the assignment v`′ := ! u` where ` 6�G `′, which is usually taken as a typical

16 3.4 Type System Properties

example of an unsecure program, is indeed secure (in the sense of [14]) in the context of a current accesslevel `′′ such that ` 6�G `′′ (but in that case this program attempts a confidentiality violation, as regardsaccess control).

Our definition of secure programs is parameterized by a global flow policy.

Definition 3.3.1 (Bisimulation) A (G, `)-bisimulation is a symmetric relation R on expressions suchthat if M RN and κ `G (M,µ) → (M ′, µ′) with M = E[R] where R is a redex, and if ν is such thatµ lG∪ dEe,` ν and u`′,θ ∈dom(µ′)−dom(µ) implies that u is fresh for ν, then there exist N ′ and ν′ such thatκ `G (N, ν) ∗→ (N ′, ν′) with M ′RN ′ and µ′ lG,` ν′.

Remark 3.3.2 (Remarks and Notation)(i) For any `, G there exists a (G, `)-bisimulation, like for instance the set Val × Val of pairs of values.(ii) The union of a family of (G, `)-bisimulations is a (G, `)-bisimulation. Consequently, there is a largest(G, `)-bisimulation, which we denote ◊G,`. This is the union of all such bisimulations.

One should observe that the relation ◊G,` is not reflexive. An example of a expression that is not bisimilarto itself would be v` := ! u`′ in the context granting access right κ where `′ 6�G ` and `, `′ �G κ, which isnot secure.

Our definition states that a program is secure, with respect to a default access level and a given globalflow policy, if it is bisimilar to itself (as in [35]):

Definition 3.3.3 (The Non-Disclosure Policy) A process P satisfies the non-disclosure policy (or issecure from the confidentiality point of view) with respect to the global flow policy G if it satisfies P ◊G,` Pfor all `. We then write P ∈ND(G).

We will now define a class of expressions, denoted as “high” due to their property of not performing anychanges to the low part of the memory.

Definition 3.3.4 (Operationally High Expressions) An expression M is said to be operationally (F, `)-high if the following holds:

κ `G (M,µ) → (M ′, µ′) implies µ lF,` µ′ and M ′ is also operationally (F, `)-high.

All “pure expressions”, i.e. the processes that make no changes to the memory, (values, for example) are(F, `)-high for any F and `.

Notation 3.3.5 The set of all operationally (F, `)-high expressions is denoted by HF,low .

3.4 Type System PropertiesThe following lemma establishes some properties of effects of the typable expressions that are easy to showlooking at the typing rules and that will be used later in the proofs.

Lemma 3.4.1 (Update of Effects)

1. If κ;F ; Γ `G E[(! u`,θ)] : s, τ , then ` �F s.r.

2. If κ;F ; Γ `G E[(u`,θ ::= V )] : s, τ , then s.w �F `.

3. If κ;F ; Γ `G E[(ref`,θV )] : s, τ , then s.w �F `.

17 3.4 Type System Properties

Subject Reduction

In order to establish the soundness of the type system of Figure 3.3 we need a Subject Reduction result,stating that types that are given to expressions are preserved by computation. To prove it we follow theusual steps [40] in detail.

We start by remarking that a value has no effect, and that this is properly reflected in the type system.Moreover, the typing of a value does not depend on the current flow policy:

Remark 3.4.2 If W ∈ Val and `;F ; Γ `G W : s, τ , then for all levels `′ and flow policies F ′, we have that`′;F ′; Γ `G W : (⊥,>,⊥), τ .

The following lemma establishes some standard weakening and strengthening properties:

Lemma 3.4.3

1. If `;F ; Γ `G M : s, τ and x /∈ dom(Γ), then `;F ; Γ, x : σ `F M : s, τ .

2. If `;F ; Γ, x : σ `G M : s, τ and x /∈ fv(M), then `;F ; Γ `G M : s, τ .

Proof: By induction on the inference of the type judgment.

We now prove two last preliminary lemmas, stating that substitutions and replacements in contextspreserve types.

Lemma 3.4.4 (Substitution)If `;F ; Γ, x : σ `G M : s, τ and `;F ; Γ `G W : s, σ, then `;F ; Γ `G {x 7→ W}M : s, τ .

Proof: By induction on the inference of `;F ; Γ, x : τ `G M : s, σ, and by case analysis on the last ruleused in this typing proof, using the previous lemma.

Nil. Here {x 7→ W}M = M , and since x /∈ fv(M), then by Lemma 3.4.3 we have `;F ; Γ `G M : s, τ .

Var. If M = x, then s = (⊥,>,⊥), σ = τ and {x 7→ W}M = W . By Remark 3.4.2, we have `;F ; Γ `G

W : (⊥,>,⊥), τ . If M 6= x, then {x 7→ W}M = M , where x /∈ fv(M). Therefore, by Lemma 3.4.3, wehave `;F ; Γ `G M : s, τ .

Abs. Here M = (λy.M), and `; F ; Γ, x : σ, y : τ `G M : s, σ where τ = τs−−→

¯,Fσ. We can assume that y /∈

dom(Γ, x : σ) (otherwise rename y). Therefore {x 7→ W}(λy.M) = (λy.{x 7→ W}M). By assumptionand Lemma 3.4.3 we can write `;F ; Γ, y : τ `G W : σ. By induction hypothesis, `; F ; Γ, y : τ `G

{x 7→ W}M : s, σ. Then, by Abs, `;F ; Γ `G (λy.{x 7→ W}M) : τ , and in particular `;F ; Γ `G

(λy.{x 7→ W}M) : s, τ .

Rec. Here M = (%y.W ), and `; F ; Γ, x : σ, y : τ `G W : s, τ . We can assume that y /∈ dom(Γ, x : σ) (oth-erwise rename y). Therefore {x 7→ W}(%y.W ) = (%y.{x 7→ W}W ). By assumption and Lemma 3.4.3we have `;F ; Γ, y : τ `G W : σ. By induction hypothesis, `; F ; Γ, y : τ `G {x 7→ W}W : s, τ . Then, byRec, `;F ; Γ `G (%y.{x 7→ W}W ) : τ , and in particular we have `;F ; Γ `G (%y.{x 7→ W})W : s, τ .

Cond. Here M = if M then Nt else Nf and we have `;F ; Γ, x : σ `G M : s, bool, `;F ; Γ, x : σ `G

Nt : st, τ1 and `;F ; Γ, x : σ `G Nf : sf , τ2 with s.r, s.t �F st.w, sf .w and s = s g st g sf g(⊥,>, s.r), τ . By induction hypothesis, `;F ; Γ, x : σ `G {x 7→ W}M : s, bool, `;F ; Γ, x : σ `G

{x 7→ W}Nt : st, τ1 and `;F ; Γ, x : σ `G {x 7→ W}Nf : sf , τ2. Therefore, `;F ; Γ, x : σ `G

if {x 7→ W}M then {x 7→ W}Nt else {x 7→ W}Nf : s, τ by rule Cond.

18 3.4 Type System Properties

Flow. Here M = (flow F in M) and `;F ; Γ, x : σ `F∪F M : s, τ . By induction hypothesis, `;F ; Γ `F∪F

{x 7→ W}M : s, τ . Then, by Flow, `;F ; Γ `F (flow F in {x 7→ W}M) : s, τ .

The proofs for the cases Ref, BoolT and BoolF are analogous to the one for Nil, while the proofs forApp, Seq, Ref, Deref, Enable, Test and Assign are analogous to the one for Cond.

Lemma 3.4.5 (Replacement)If `;F ; Γ `G E[M ] : s, τ is a valid judgment, then the proof gives M a typing bEc`;F ∪dEe; Γ `G M : s, τ forsome s and τ such that s.r � s.r, s.w � s.w and s.t � s.t. In this case, if bEc`;F ∪ dEe; Γ `G N : s′, τ withs′.r � s.r, s.w � s′.w and s′.t � s.t, then `;F ; Γ `G E[N ] : s′, τ , for some s′ such that s′.r � s.r, s.w � s′.wand s′.t � s.t.

Proof: By induction on the structure of E.

E[M ] = if E[M ] then Nt else Nf . By Cond, we have `;F ; Γ `G E[M ] : s, bool, and `;F ; Γ `G Nt : st, τ ,`;F ; Γ `G Nf : sf , τ with s.r, s.t �F st.w, sf .w and s = s g st g sf g (⊥,>, s.r). By inductionhypothesis, the proof gives M a typing l; F ; Γ `G M : s, τ , for F , s, τ with ˆ= bEc`, F = F ∪ dEe ands.r � s.r, s.w � s.w and s.t � s.t. Therefore, s.r � s.r, s.w � s.w and s.t � s.t.

Also by induction hypothesis, ˆ; F ; Γ `G E[M ] : s′, τ , for some s′ such that s′.r � s.r, s.w �s′.w and s′.t � s.t. Since s′.r, s′.t �F st.w, sf .w, then, again by Cond, we have `;F ; Γ `G

if E[M ] then Nt else Nf : s′ g st g sf g (⊥,>, s′.r), τ . We conclude by noting that s′.r � s.r,s.w � s′.w, and s′.t g s′.r � s.t.

E[M ] = (flow F ′ in E[M ]). By Flow, we have bEc`;F ∪ F ′; Γ `G E[M ] : s, τ . By induction hypothesis,the proof gives M a typing ˆ; F ; Γ `G M : s, τ , for F , s, τ with ˆ = bEc`, F = F ∪ F ′ ∪ dEe ands.r � s.r, s.w � s.w and s.t � s.t.

Also by induction hypothesis, ˆ; F ; Γ `G E[M ] : s′, τ , for some s′ such that s′.r � s.r, s.w � s′.w ands′.t � s.t. Then, again by Flow, we have `;F ; Γ `G (flow F ′ in E[M ]) : s′, τ .

We will now prove Subject Reduction, the property of type preservation by the computation, and thatas the effects of an expression are performed, the security effects of the expression “weaken”. The conditionu`,θ ∈dom(µ) ⇒ `;F ; Γ `G µ(u`,θ) : ⊥, θ simply says by Remark 3.4.2 that the values stored in the memoryare well typed.

Theorem 3.4.6 (Subject Reduction) If `;F ; Γ `G M : s, τ and ` `G (M,µ) → (M ′, µ′) with u`,θ ∈dom(µ) ⇒ `;F ; Γ `G µ(u`,θ) : ⊥, θ, then `;F ; Γ `G M ′ : s′, τ for some s′ such that s′ �G s.

Proof: We have M = E[R] and M ′ = E[N ] with ` `G (R,µ) → (N,µ′), where R is a redex. We proceed byinduction on the context E. In the case where E = [ ], the proof is as usual for the functional and imperativepart of the language. Let us just examine the cases where a security construct is involved. In the cases of

` `G ((`′ n V ), µ) → (V, µ)

` `G ((enable `′ in V ), µ) → (V, µ)

` `G ((flow F in V ), µ) → (V, µ)

19 3.4 Type System Properties

we use the Lemma 3.4.2 above. The cases

` `G ((test `′ then M ′ else M ′′), µ) → (M ′, µ) with `′ �G `

` `G ((test `′ then M ′′ else M ′), µ) → (M ′, µ) with `′ 6�G `

are immediate (in the first case we use Lemma 3.2.1). Now if E = E′[F] we use the Lemma 3.4.5 above.

Now we show that the faulty expressions, as defined in Lemma 3.1.1, are not typable.

Lemma 3.4.7 The (`,G)-faulty expressions are not typable in the context of access right ` and global flowpolicy G.

Proof: Let M = E[(! u`′,θ)] with `′ 6�G bEc`, and assume that `;F,Γ `G M : s, τ . Then by Lemma 3.4.5one would have bEc`;F ∪ dEe; Γ `G (! u`′,θ) : s′, σ for some s′ and σ, but this is only possible, by the(Deref) rule, if `′ �G bEc`, a contradiction. The other cases are standard.

An immediate consequence of these results and Lemma 3.1.1 is:

Theorem 3.4.8 (Type Safety) Let M be a typable closed expression, with `;F ; Γ `G M : s, τ , and let µbe such that u`,θ ∈ dom(µ) ⇒ `;F ; Γ `G µ(u`,θ) : ⊥, θ. Then either the reduction of (M,µ) with respect to(`,G) does not terminate, or there exist a value V ∈ Val and a memory µ′ such that ` `G (M,µ) ∗→ (V, µ′)with `;F ; Γ `G V : ⊥, τ .

In particular, this shows that the dynamic checking of the reading clearance (by means of a “stack inspection”mechanism) is actually not needed regarding a typable program, which never attempts to access a referencefor which it would not have the appropriate access right.

Syntactically High Expressions

We define syntactically high expressions as expressions that cannot perform changes to the low part of thememory (with respect to the current flow policy).

Definition 3.4.9 (Syntactically “High” Expressions) An expression M is syntactically (F, `)-high ifthere exist κ, Γ, s, τ such that κ;F ; Γ `G M : s, τ with s.w 6�F `. The expression M is a syntactically (F, `)-high function if there exist `′, F ′,Γ, s, τ such that `′;F ′; Γ ` M : τ

s−−→`,F

σ with s.w 6�F `.

It is easy to check that syntactically high expressions have an operationally high behavior.

Lemma 3.4.10 (High Expressions) If M is a syntactically (F, `)-high expression, then M is an opera-tionally (F, `)-high expression.

3.4.1 SoundnessIn this section we present and explain the proof of soundness of the type system of Figure 3.3 with respectto the notion of security of Definition 3.3.3. Proofs for each intermediate result are preceded by their “proofsketch”, an abridged version clarifying the intuition behind the proof.

We set to prove that, under any global flow policy G, all sets of expressions M that are typable using thetype system of Figure 3.3 satisfy the Non-Disclosure policy, given by Definition 3.3.3. Informally, this meansthat, whatever the security level that is chosen to be “low” (here that security level will be denoted by ‘low ’),the expression M always presents the same behavior according to a weak bisimulation on low-equal states.We will start with an analysis of the class of expressions that are typable with a low termination effect, forwhich we can state a stronger soundness result.

20 3.4 Type System Properties

Behavior of “Low”-Terminating Expressions

Recall that, according to the intended meaning of the termination effect, the termination or non-terminationof expressions with low termination effect should only depend on the low part of the state. In other words,two computations of a same expressions running under two “low”-equal states should either both terminateor both diverge. In particular, this implies that termination-behavior of these expressions cannot be used toleak “high” information when composed with other expressions (via termination leaks). This can be formallystated as follows:

Lemma 3.4.11 (Guaranteed Transitions) Suppose that M is typable for `, F , Γ. If ` `G (M,µ1) −→F ′

(M ′1, µ

′1) such that a reference a is fresh for µ2 if a,θ ∈ dom(µ′1) − dom(µ1) and we have µ1 lF∪F ′,low µ2,

then there exist M ′2 and µ′2 such that ` `G (M,µ2) −→

F ′(M ′

2, µ′2) with µ′1 lF,low µ′2.

We aim at proving that any typable expression M that has a low-termination effect always presents thesame behavior according to a strong bisimulation on low-equal states: if two continuations M1 and M1 of Mare related, and if M1 can perform an execution step over a certain state, then M2 can perform the same lowchanges to any low-equal state in precisely one step, while the two resulting continuations are still related.This implies that any two computations of M under low-equal states should be both finite or both infinite.To this end, we design a reflexive binary relation on expressions with low-termination effects that is closedunder the transitions of Guaranteed Transitions (Lemma 3.4.11).

The definition of TG∪F,low , abbreviated TF,low when the global flow policy is G, is given in Figure 3.4.The flow policy F is assumed to contain G. Notice that it is a symmetric relation. In order to ensure thatexpressions that are related by TF,low perform the same changes to the low memory, its definition requiresthat the references that are created or written using (potentially) different values are high.

Remark 3.4.13 If for some F we have that M1 TF,low M2 and M1 ∈ Val , then M2 ∈ Val .

We have seen in Splitting Computations (Lemma 3.1.2) that two computations of the same expressioncan split only if the expression is about to read a reference that is given different values by the memories ineach of the configurations. Since we will be only interested in the case where the two memories are low-equal,this situation coincides with the case where the reference that is read is high. From the following lemmaone can conclude that the relation TF,low relates the possible outcomes of expressions that are typable witha low termination effect, and that perform a high read over low-equal memories.

Lemma 3.4.14 If there exist κ, Γ, s, τ such that κ;F ; Γ `G E[(! a,θ)] : s, τ with s.t �F low and 6�F∪dEelow , then for any values V0, V1 ∈ Val such that κ;F ; Γ `G Vi : θ we have E[V0] TF,low E[V1].

Proof sketch. If a typable expression is about to use a value that results from a high dereference in such away that it could influence its termination behavior, then its termination effect cannot be low (contradictingthe assumption). The type system enforces this by updating the termination effect of the expression withthe reading effect of the dereferencing operation, in the cases where the value is used: in the predicate of aconditional (s.r in the termination effect of Cond); to determine the function of an application (s.r in thetermination effect of App); to determine the argument of an application (s′′.r in the termination effect ofApp) of an application.The relation T requires that the references that are (respectively) created or written using the high derefer-enced value are high (see Clauses 4 and 6). This is guaranteed by conditions of the form ‘s.r �F ’, where sis the security effect of the program that is performing the access, and is the security level of the referencethat is created or written. More precisely, conditions are imposed when the dereferenced value is used: tocreate a reference (s.r �F ` in rule Ref); to determine a reference that is being assigned to (s.r �F ` in ruleAssign); to determine a value that is being assigned (s′.r �F ` in rule Assign).

21 3.4 Type System Properties

Definition 3.4.12 (TF,low)We have that M1 TF,low M2 if κ;F ; Γ `G M1 : s1, τ and κ;F ; Γ `G M2 : s2, τ for some κ, F , Γ, s1, s2 andτ with s1.t �F low and s2.t �F low and one of the following holds:

Clause 1. M1 and M2 are both values, or

Clause 2. M1 = M2, or

Clause 3. M1 = (M1; N) and M2 = (M2; N) with M1 TF,low M2, or

Clause 4. M1 = (ref,θ M1) and M2 = (ref,θ M2) with M1 TF,low M2, and 6�F low , or

Clause 5. M1 = (! M1) and M2 = (! M2) with M1 TF,low M2, or

Clause 6. M1 = (M1 := N1) and M2 = (M2 := N2) with M1 TF,low M2, and N1 TF,low N2, and M1, M2

both have type θ ref for some θ and l such that 6�F low , or

Clause 7. M1 = (flow F ′ in M1) and M2 = (flow F ′ in M2) with M1 TF∪F ′,low M2

Clause 8. M1 = (ı n M1) and M2 = (ı n M2) with M1 TF,low M2.

Clause 9. M1 = (enable ı in M1) and M2 = (enable ı in M2) with M1 TF,low M2.

Figure 3.4: The relation TF,low

Proof: By induction on the structure of E.

E[(! a,θ)] = (! a,θ). We have V0 TF,low V1 by Clause 1.

E[(! a,θ)] = (E1[(! a,θ)] M). By App we have κ;F ; Γ `G E1[(! a,θ)] : s, τs′−−→

ı,Fσ with s.r �F s.t. By

Lemma 3.4.1, we have �F s.r. Therefore �F s.t, which contradicts the assumption that boths.t �F low and 6�F∪dEe low hold.

E[(! a,θ)] = (V E1[(! a,θ)]). By rule App we have κ;F ; Γ `G E1[(! a,θ)] : s′′, τ with s′′.r �F s.t. ByLemma 3.4.1, we have �F s′′.r. Therefore �F s.t, which contradicts the assumption that boths.t �F low and 6�F∪dEe low hold.

E[(! a,θ)] = if E1[(! a,θ)] then Mt else Mf . By Cond we have that κ;F ; Γ `G E1[(! a,θ)] : s, boolwith s.r �F s.t. By Lemma 3.4.1, we have �F s.r. Therefore �F s.t, which contradicts theassumption that both s.t �F low and 6�F∪dEe low hold.

E[(! a,θ)] = (E1[(! a,θ)]; M). By Seq we have κ;F ; Γ `G E1[(! a,θ)] : s, τ with s.t �F s.t. Therefores.t �F low , and since l 6�F∪dEe low implies l 6�F∪dE1e low , then by induction hypothesis we haveE1[V0] TF,low E1[V1]. By Lemma 3.4.5 and Clause 3 we can conclude.

E[(! a,θ)] = (ref′,θ′ E1[(! a,θ)]). By rule Ref we have that κ;F ; Γ `G E1[(! a,θ)] : s, τ with s.r =s.r �F l′ and s.t = s.t. Therefore s.t �F low , and since l 6�F∪dEe low implies 6�F∪dE1e low , then byinduction hypothesis we have E1[V0] TF,low E1[V1]. By Lemma 3.4.1 we have �F s.r, so s.r 6�F low .Therefore, l′ 6�F low , and we conclude by Lemma 3.4.5 and Clause 4.

22 3.4 Type System Properties

E[(! a,θ)] = (! E1[(! a,θ)]). By rule Deref we have κ;F ; Γ `G E1[(! a,θ)] : s, τ with s.t �F s.t.Therefore s.t �F low , and since 6�F∪dEe low implies l 6�F∪dE1e low , then by induction hypothe-sis E1[V0] TF,low E1[V1]. We conclude by Lemma 3.4.5 and Clause 5.

E[(! a,θ)] = (E1[(! a,θ)] := M). By rule Assign we have that κ;F ; Γ `G E1[a,θ] : s, θ ref with s.t �F

s.t and s.r �F¯. Therefore s.t �F low , and since 6�F∪dEe low implies 6�F∪dE1e low , then by

induction hypothesis E1[V0] TF,low E1[V1]. On the other hand, by Clause 2 we have M TF,low M . ByLemma 3.4.1 we have �F s.r, so l �F

¯. Then, we must have ¯ 6�F low , since otherwise �F∪dEe low .Therefore, we conclude by Lemma 3.4.5 and Clause 6.

E[(! a,θ)] = (V := E1[(! a,θ)]). By rule Assign we have that κ;F ; Γ `G V : s, θ ref ¯, and `;F ; Γ `G

E1[a,θ] : s′, θ with s′.t �F s.t and s′.r �F¯. Therefore s′.t �F low , and since 6�F∪dEe low implies

6�F∪dE1e low , then by induction hypothesis E1[V0] TF,low E1[V1]. On the other hand, by Clause 2 wehave V TF,low V . By Lemma 3.4.1 we have l �F s′.r, so �F

¯. Then, we must have ¯ 6�F low , sinceotherwise �F∪dEe low . We then conclude by Lemma 3.4.5 and Clause 6.

E[(! a,θ)] = (flow F ′ in E1[(! a,θ)]). By rule Flow we have κ;F ∪ F ′; Γ `G V : s, τ . By inductionhypothesis E1[V0] TF∪F ′,low E1[V1], so we conclude by Lemma 3.4.5 and Clause 7.

E[(! a,θ)] = (ı n E1[(! a,θ)]). By rule Restric we have κfG ı;F ; Γ `G V : s, τ . By induction hypothesisE1[V0] TF,low E1[V1], so we conclude by Lemma 3.4.5 and Clause 8.

E[(! a,θ)] = (enable ı in E1[(! a,θ)]). By rule Enable we have κ gG ı;F ; Γ `G V : s, τ . By inductionhypothesis E1[V0] TF∪F ′,low E1[V1], so we conclude by Lemma 3.4.5 and Clause 9.

We can now prove that TF,low behaves as a kind of “strong bisimulation”:

Theorem 3.4.15 (Strong Bisimulation for Low-Terminating Expressions)If we have M1 TF,low M2 and ` `G (M1, µ1) −→

F ′(M ′

1, µ′1), with µ1 lF∪F ′,low µ2 such that a is fresh for

µ2 if a,θ ∈ dom(µ′1) − dom(µ1), then there exist M ′2 and µ′2 such that ` `G (M2, µ2) −→

F ′(M ′

2, µ′2) with

M ′1 TF,low M ′

2 and µ′1 lF,low µ′2.

Proof sketch. If M1 and M2 are equal (related by T using Clause 2), then since they have a low terminationeffect we can use Guaranteed Transitions (Lemma 3.4.11) to conclude that M2 can also make a step andperform the same changes to low-equal memories. If the result of performing the two steps is different –therefore not falling again in Clause 2 – by Splitting Computations (Lemma 3.1.2) we conclude they haveperformed a high dereference. In Lemma 3.4.14 we have seen that this implies that the resulting expressionsare still in the T relation.The remaining cases use the fact that M1 is a value if and only if M2 is a value, to show that if M1 canperform a computation step, so can M2.

Proof: By induction on the definition of TF,low . In the following, we use Subject Reduction (Theo-rem 3.4.6) to guarantee that the termination effect of the expressions resulting from M1 and M2 is still lowwith respect to low and F . This, as well as typability (with the same type) for low and F , is a requirementfor being in the TF,low relation.

Clause 1. This case is not possible.

23 3.4 Type System Properties

Clause 2. Here M1 = M2. By Guaranteed Transitions (Lemma 3.4.11) there exist M ′2 and µ′2 such that

` `G (M2, µ1) → (M ′2, µ

′2) with µ′1 lF,low µ′2.

M ′2 = M ′

1. Then we have M ′1 TF,low M ′

2, by Clause 2 and Subject Reduction (Theorem 3.4.6).M ′

2 6= M ′1. Then by Splitting Computations (Lemma 3.1.2) we have that there exists E and a,θ such

that F ′ = dEe, M ′1 = E[µ1(a,θ)], M ′

2 = E[µ2(a,θ)], µ′1 = µ1 and µ′2 = µ2. Since µ1(a,θ) 6=µ2(a,θ), we have 6�F∪F ′ low . Therefore, M ′

1 TF,low M ′2, by Lemma 3.4.14 above.

Clause 3. Here M1 = (M1; N) and M2 = (M2; N) where M1 TF,low M2. Then either:

M1 can compute. In this case M ′1 = (M ′

1; N) with ` `G (M1, µ1) −→F ′

(M1, µ′1). We use the induction

hypothesis, Clause 3 and Subject Reduction (Theorem 3.4.6) to conclude.M1 is a value. In this case M ′

1 = N and F ′ = ∅ and µ′1 = µ1. We have M2 ∈ Val by Remark 3.4.13,hence ` `G (M2, µ2)−→

F ′(N , µ2), and we conclude using Clause 2 and Subject Reduction (Theorem

3.4.6).

Clause 4. Here M1 = (ref,θ M1) and M2 = (ref,θ M2) where M1 TF,low M2, and 6�F low . There are twocases.

M1 can compute. In this case M ′1 = (ref,θ M1) with ` `G (M1, µ1) −→

F ′(M ′

1, µ′1). We use the

induction hypothesis, Subject Reduction (Theorem 3.4.6) and Clause 4 to conclude.M1 is a value. In this case M ′

1 = a,θ, with a fresh for µ1, F ′ = ∅ and µ′1 = µ1 ∪ {a,θ 7→ M1} (andtherefore a is also fresh for µ2). Then M2 ∈ Val by Remark 3.4.13, and therefore ` `G (M2, µ2)−→F ′

(al,θ, µ2 ∪ {al,θ 7→ M2}). Being µ′2 = µ2 ∪ {a,θ 7→ M2} we get µ′1 lF,low µ′2 since 6�F low .

We conclude using Clause 1 and Subject Reduction (Theorem 3.4.6).

Clause 5. Here M1 = (! M1) and M2 = (! M2) where M1 TF,low M2. We distinguish two sub-cases.

M1 can compute. In this case ` `G (M1, µ1) −→F ′

(M ′1, µ

′1). We use the induction hypothesis, Subject

Reduction (Theorem 3.4.6) and Clause 5 to conclude.M1 is a value. Then M1 = u,θ and M ′

1 ∈ Val , and µ′1 = µ1, F ′ = ∅. By Remark 3.4.13, M2 ∈ Val ,and since M1 and M2 have the same type, it must be a reference v′,θ, and so ` `G (M2, µ2) −→

F ′

(v′,θ, µ2). We then conclude using Clause 1 and Subject Reduction (Theorem 3.4.6).

Clause 6. Here we have M1 = (M1 := N1) and M2 = (M2 := N2) where M1 TF,low M2, N1 TF,low N2, andM1, M2 both have type θ ref for some θ and such that 6�F low . We distinguish three sub-cases.

M1 can compute. In this case ` `G (M1, µ1) −→F ′

(M ′1, µ

′1). We use the induction hypothesis, Subject

Reduction (Theorem 3.4.6) and Clause 6 to conclude.M1 is value, but N1 can compute. In this case we have ` `G (N1, µ1) −→

F ′(N ′

1, µ′1). By Re-

mark 3.4.13 also M2 ∈ Val . We use the induction hypothesis, Subject Reduction (Theorem3.4.6) and Clause 6 to conclude.

M1 and N1 are values. Then M1 = u,θ and M ′1 = (), µ′1 = {N1 7→ M1}µ1, F ′ = ∅. By

Remark 3.4.13, also M2, N2 ∈ Val , and since M1 and M2 have the same type, M2 mustbe a reference v′,θ′ , and so ` `G (M2, µ2) −→

F ′((), {N2 7→ M2}µ2). Since 6�F low , then

{N1 7→ M1}µ1 lF,low {N2 7→ M2}µ2. We then conclude using Clause 1 and Subject Reduction(Theorem 3.4.6).

24 3.4 Type System Properties

Clause 7. Here we have M1 = (flow F in M1) and M2 = (flow F in M2) and M1 TF∪F ,low M2. There aretwo cases.

M1 can compute. In this case ` `G (M1, µ1) −−→F ′′

(M ′1, µ

′1) with F ′ = F ∪F ′′. By induction hypoth-

esis, we have ` `G (M2, µ2) −−→F ′′

(M ′2, µ

′2), and M ′

1 TF∪F ,low M ′2 and µ′1 lF∪F ,low µ′2. Notice that

this implies µ′1 lF,low µ′2. We use Subject Reduction (Theorem 3.4.6) and Clause 7 to conclude.

M1 is a value. In this case M ′1 = M1, F ′ = ∅ and µ′1 = µ1. Then M2 ∈ Val by Remark 3.4.13, and

so ` `G (M2, µ2) −→F ′

(M2, µ2). We conclude using Clause 1 and Subject Reduction (Theorem

3.4.6).

Clause 8. Here we have M1 = (¯n M1) and M2 = (¯n M2) and M1 TF,low M2. There are two cases.

M1 can compute. In this case ` `G (M1, µ1) −→F ′

(M ′1, µ

′1). We use the induction hypothesis, Subject

Reduction (Theorem 3.4.6) and Clause 8 to conclude.

M1 is a value. In this case M ′1 = M1, F ′ = ∅ and µ′1 = µ1. Then M2 ∈ Val by Remark 3.4.13, and

so ` `G (M2, µ2) −→F ′

(M2, µ2). We conclude using Clause 1 and Subject Reduction (Theorem

3.4.6).

Clause 9. Here we have M1 = (enable ¯ in M1) and M2 = (enable ¯ in M2) and M1 TF,low M2. There aretwo cases.

M1 can compute. In this case ` `G (M1, µ1) −→F ′

(M ′1, µ

′1). We use the induction hypothesis, Subject

Reduction (Theorem 3.4.6) and Clause 9 to conclude.

M1 is a value. In this case M ′1 = M1, F ′ = ∅ and µ′1 = µ1. Then M2 ∈ Val by Remark 3.4.13, and

so ` `G (M2, µ2) −→F ′

(M2, µ2). We conclude using Clause 1 and Subject Reduction (Theorem

3.4.6).

We have seen in Remark 3.4.13 that when two expressions are related by TF,low and one of them is a value,then the other one is also a value. From a semantical point of view, when an expression has reached a valueit means that it has successfully completed its computation. We will now see that when two expressions arerelated by TF,low and one of them is unable to resolve into a value, in any sequence of unrelated computationsteps, then the other one is also unable to do so.

Definition 3.4.16 (Non-resolvable Expressions) We say that an expression M is non-resolvable, de-noted M†, if there is no derivative M ′ of M such that M ′ ∈ Val .

Lemma 3.4.17 If for some F we have that M TF,low N and M†, then N†.

Proof sketch. We prove that if M and N are related by T , and there is a sequence of memories thatdefines a path of execution steps from N into a value, then the sequence of memories can be used to“bring” M into a value as well. This can be seen using Strong Bisimulation for Low-Terminating Expressions(Proposition 3.4.15), since for each step between two derivatives of N it guarantees a step between thecorresponding two derivatives of M , in such a way that the relation T is maintained.

25 3.4 Type System Properties

Proof: Let us suppose that ¬N†. That means that there exists a finite number of states µ1, . . . , µn andµ′1, . . . , µ′n and of expressions N1, . . . , Nn such that

` `G (N,µ1) −→ (N1, µ′1) and

` `G (N1, µ2) −→ (N2, µ′2) and

...` `G (Nn−1, µn) −→ (Nn, µ′n)

and such that Nn ∈ Val . By Strong Bisimulation for Low-Terminating Threads (Proposition 3.4.15), wehave that there exists a finite number of states µ′1, . . . , µ′n and of expressions M1, . . . , Mn such that

` `G (M,µ1) −→ (M1, µ′1) and` `G (M1, µ2) −→ (M2, µ′2) and

...` `G (Mn−1, µn) −→ (Mn, µ′n)

such that:M1 TF,low N1, and . . . , and Mn TF,low Nn

By Remark 3.4.13, we then have that Mn ∈ Val . Since Mn is a derivative of M , we conclude that ¬M†.

The following lemma deduces operational “highness” of expressions from that of its subexpressions.

Lemma 3.4.18 (Composition of High Expressions) Suppose that M is typable in κ and F . Then:

1. If M = (M1 M2) and M1 is a syntactically (F, low)-high function and either

• M1† and M1 ∈ HF,low , or

• M1,M2 ∈ HF,low ,

then M ∈ HF,low .

2. If M = if M1 then Mt else Mf and M1,Mt,Mf ∈ HF,low , then M ∈ HF,low .

3. If M = (ref,θ M1) and 6�F low and M1 ∈ HF,low , then M ∈ HF,low .

4. If M = (M1;M2) and either

• M1† and M1 ∈ HF,low , or

• M1,M2 ∈ HF,low ,

then M ∈ HF,low .

5. If M = (M1 := M2) and M1 has type θ ref with 6�F low and either

• M1† and M1 ∈ HF,low , or

• M1,M2 ∈ HF,low ,

then M ∈ HF,low .

6. If M = (flow F ′ in M1) and M1 ∈ HF∪F ′,low , then M ∈ HF,low .

26 3.4 Type System Properties

7. If M = (ı n M1) and M1 ∈ HF,low , then M ∈ HF,low .

8. If M = (enable ı in M1) and M1 ∈ HF,low , then M ∈ HF,low .

Proof sketch. A construct that does not introduce low effects and that is only composed of operationallyhigh expressions can be easily seen to be operationally high: for all the computation steps that can beperformed by any of its derivatives, there is a corresponding one that can be performed by a derivativeof one of its components. Since the components are operationally high, then the step does not make lowchanges to the state.Syntactical highness of a function guarantees that its body, which can be seen as a subexpression of anapplication, is operationally high. A reference creation or assignment that is only composed of operationallyhigh expressions is operationally high for the same reasons, provided that the created or written reference ishigh.When a non-resolvable expression M1 is composed with an expression M2, as in (M1 M2), (M1;M2) or(M1 := M2), it is enough to require that M1 is operationally high. In fact, for all the computation stepsthat can be performed by any of these expressions’ derivatives, there is a corresponding one that can beperformed by a derivative of M1 – that is, the expression M2 never gets to be evaluated.

Proof: We give the proof for the case where M = (M1 M2) and M1 is a syntactically (F, low)-highfunction. The other cases are analogous or simpler.

M1† and M1 ∈ HF,low . Let F be a set of expressions that includes HF,low , and that contains the expres-sions (M1 M2) provided that they are typable in F , and satisfy M1 /∈ Val and M1 ∈ F and M1 is a(F, low)-high function. Assume that an application M = (M1 M2) such that M1† and M1 ∈ HF,low

performs the transition ` `G (M,µ) −→F ′

(M ′, µ′). We show that this implies M ′ ∈ F and µ lF,low µ′.

Since M1 is non-resolvable, M1 cannot be a value, and since M can compute, then also M1 cancompute. We then have M ′ = (M ′

1 M2) with ` `G (M1, µ) −→F ′

(M ′1, µ

′). Since M1 ∈ HF,low , then

also M ′1 ∈ HF,low , thus M ′

1 ∈ F , and µ lF,low µ′. By Subject Reduction (Theorem 3.4.6), M ′1 is a

(F, low)-high function, and since M1† then M ′1 /∈ Val . Hence M ′ ∈ F .

M1, M2 ∈ HF,low . Let F be a set of expressions that includes HF,low , and that contains expressions(M1 M2) provided they are typable in F and satisfy M1,M2 ∈ F and M1 is a (F, low)-high function.Assume that such an application M = (M1 M2) performs the transition ` `G (M,µ) −→

F ′(M ′, µ′). We

show that this implies M ′ ∈ F and µ lF,low µ′.

M1 and M2 are values. Then M1 = (λx.M1), M ′ = {x 7→ M2}M1 and µ = µ′. Since M1

is a (F, low)-high function, then by Abs M1 is syntactically (F, low)-high, and by Substitu-tion (Lemma 3.4.4), also M ′ is syntactically (F, low)-high. Therefore, by High Expressions(Lemma 3.4.10), M ′ ∈ HF,low .

M1 can compute. Then we have M ′ = (M ′1 M2) with ` `G (M1, µ) −→

F ′(M ′

1, µ′). Since M1 ∈ HF,low ,

then also M ′1 ∈ F and µ lF,low µ′. By Subject Reduction (Theorem 3.4.6) M ′

1 is a (F, low)-highfunction. Hence M ′ ∈ F .

M1 is a value but M2 can compute. Then we have M ′ = (M1 M ′2) with ` `G (M2, µ) −→

F ′

(M ′2, µ

′). Since M2 ∈ HF,low , then also M ′2 ∈ F and µ lF,low µ′. Hence M ′ ∈ F .

Lemma 3.4.19 If for some F we have that M1 TF,low M2 and M1 ∈ HF,low , then M2 ∈ HF,low .

27 3.4 Type System Properties

Proof sketch. The proof relies on the fact that if an expression M1 of the form (M1; N1) or (M1 := N1)is operationally high, in spite of N1 not being operationally high, then M1 is non-resolvable. To see this,note that if M1 were not non-resolvable, we would have, for some value V , that (V ; N1) or (V := N1) wouldbe derivatives of M1. We can then see that, for all the computation steps that can be performed by any ofN1’s derivatives, there is a corresponding one that can be performed by a derivative of M1. Since N1 is notoperationally high, then also M would not be operationally high.From the fact that an expression is operationally high, we can easily conclude that the first subexpressionto be evaluated is also operationally high. Clauses 3 and 6 do not require their second subexpression N1

to be operationally high. However, by the above observation and by Lemma 3.4.17 this implies that M2 isnon-resolvable. We can then argue that the expressions in the T relation have the same “composition”, andconclude that they are operationally high using Composition of High Expressions (Lemma 3.4.18).

Proof: By induction on the definition of M1 TF,low M2.

Clause 1. Direct.

Clause 2. Direct.

Clause 3. Here M1 = (M1; N) and M2 = (M2; N) with M1 TF,low M2. Clearly we have that M1 ∈ HF,low ,so by induction hypothesis, also M2 ∈ HF,low . We distinguish two sub-cases:

N ∈ HF,low . Then, M2, N ∈ HF,low . Therefore, by Composition of High Expressions (Lemma 3.4.18)we have that M2 ∈ HF,low .

N /∈ HF,low . Then M1†, and by Lemma 3.4.17 also M2†. Therefore, by Composition of High Expres-sions (Lemma 3.4.18) we have that M2 ∈ HF,low .

Clause 4. Here M1 = (ref,θ M1) and M2 = (ref,θ M2) where M1 TF,low M2, and 6�F low . Clearly wehave that M1 ∈ HF,low , so by induction hypothesis also M2 ∈ HF,low . Therefore, by Composition ofHigh Expressions (Lemma 3.4.18) we have that M2 ∈ HF,low .

Clause 5. Here M1 = (! M1) and M2 = (! M2) where M1 TF,low M2. Clearly we have that M1 ∈ HF,low ,so by induction hypothesis also M2 ∈ HF,low . This implies that M2 ∈ HF,low .

Clause 6. Here we have M1 = (M1 := N1) and M2 = (M2 := N2) where M1 TF,low M2, and M1, M2 bothhave type θ ref for some θ and such that 6�F low , and N1 TF,low N2. Clearly we have thatM1 ∈ HF,low , so by induction hypothesis also M2 ∈ HF,low . We distinguish two sub-cases:

N2 ∈ HF,low . Then, M2, N2 ∈ HF,low where M2 has type θ ref for some θ and such that 6�F low .Therefore, by Composition of High Expressions (Lemma 3.4.18) we have that M2 ∈ HF,low .

N2 /∈ HF,low . Then M1†, and by Lemma 3.4.17 also M2†. Therefore, since M2 has type θ ref forsome θ and such that 6�F low , by Composition of High Expressions (Lemma 3.4.18) we havethat M2 ∈ HF,low .

Clause 7. Here we have M1 = (flow F ′ in M1) and M2 = (flow F ′ in M2) with M1 TF∪F ′,low M2. Clearlywe have that M1 ∈ HF,low , so by induction hypothesis also M2 ∈ HF,low . Therefore, by Compositionof High Expressions (Lemma 3.4.18) we have that M2 ∈ HF,low .

Clause 8. Here we have M1 = (κ n M1) and M2 = (κ n M2) with M1 TF,low M2. Clearly we have thatM1 ∈ HF,low , so by induction hypothesis also M2 ∈ HF,low . Therefore, by Composition of HighExpressions (Lemma 3.4.18) we have that M2 ∈ HF,low .

28 3.4 Type System Properties

Clause 8. Here we have M1 = (enable κ in M1) and M2 = (enable κ in M2) with M1 TF,low M2. Clearlywe have that M1 ∈ HF,low , so by induction hypothesis also M2 ∈ HF,low . Therefore, by Compositionof High Expressions (Lemma 3.4.18) we have that M2 ∈ HF,low .

Behavior of Typable Low Expressions

In this second phase of the proof, we consider the general case of expressions that are typable with anytermination level. As in the previous subsection, we show that a typable expression behaves as a strongbisimulation, provided that it is operationally low. For this purpose, we make use of the properties identifiedfor the class of low-terminating expressions by allowing only these to be followed by low-writes. Conversely,high-terminating expressions can only be followed by high-expressions (see Definitions 3.3.4 and 3.4.9).

We now design a binary relation on expressions that uses TF,low to ensure that high-terminating expres-sions are always followed by operationally high ones. The definition of RG,F,low , abbreviated RF,low whenthe global flow policy is G, is given in Figure 3.5. The flow policy F is assumed to contain G. Noticethat it is a symmetric relation. In order to ensure that expressions that are related by RF,low perform thesame changes to the low memory, its definition requires that the references that are created or written using(potentially) different values are high, and that the body of the functions that are applied are syntacticallyhigh.

Remark 3.4.21 If M1 TF,low M2, then M1 RF,low M2.

The above remark is used to prove the following lemma.

Lemma 3.4.22 If for some F we have that M1 RF,low M2 and M1 ∈ HF,low , then M2 ∈ HF,low .

Proof sketch. Similarly to Lemma 3.4.19, the proof rests on the fact that if an expression M1 of the form(M1 N1), (M1; N1) or (M1 := N1) is operationally high, in spite of N1 not being operationally high, thenM1 is non-resolvable.Clauses 5’, 7’ and 11’ do not require N1 to be operationally high. However, by the above observation andby Lemma 3.4.17 this implies that M2 is non-resolvable. Therefore, it is sufficient to conclude that M2 isoperationally high.

Proof: By induction on the definition of M1 RF,low M2.

Clause 1’. Direct.

Clause 2’. Direct.

Clause 3’. Here we have that M1 = if M1 then Mt else Mf and that M2 = if M2 then Mt else Mf withM1 RF,low M2 and Mt, Mf ∈ HF,low . Clearly we have that M1 ∈ HF,low , so by induction hypothesisalso M2 ∈ HF,low . Therefore, by Composition of High Expressions (Lemma 3.4.18) we have thatM2 ∈ HF,low .

Clause 4’. Here M1 = (M1 N1) and M2 = (M2 N2) with M1 RF,low M2, M1 and M2 are syntactically(F, low)-high functions, and N1, N2 ∈ HF,low . Clearly we have that M1 ∈ HF,low , so by inductionhypothesis also M2 ∈ HF,low . Therefore, by Composition of High Expressions (Lemma 3.4.18) we havethat M2 ∈ HF,low .

29 3.4 Type System Properties

Definition 3.4.20 (RF,low) We have that M1 RF,low M2 if `;F ; Γ `G M1 : s1, τ and `;F ; Γ `G M2 : s2, τfor some `, Γ, s1, s2 and τ and one of the following holds:

Clause 1’. M1,M2 ∈ HF,low , or

Clause 2’. M1 = M2, or

Clause 3’. M1 = if M1 then Nt else Nf and M2 = if M2 then Nt else Nf with M1 RF,low M2, andNt, Nf ∈ HF,low , or

Clause 4’. M1 = (M1 N1) and M2 = (M2 N2) with M1 RF,low M2, and N1, N2 ∈ HF,low , and M1, M2 aresyntactically (F, low)-high functions, or

Clause 5’. M1 = (M1 N1) and M2 = (M2 N2) with M1 TF,low M2, and N1 RF,low N2, and M1, M2 aresyntactically (F, low)-high functions, or

Clause 6’. M1 = (M1; N) and M2 = (M2; N) with M1 RF,low M2, and N ∈ HF,low , or

Clause 7’. M1 = (M1; N) and M2 = (M2; N) with M1 TF,low M2, or

Clause 8’. M1 = (ref,θ M1) and M2 = (ref,θ M2) with M1 RF,low M2, and l 6�F low , or

Clause 9’. M1 = (! M1) and M2 = (! M2) with M1 RF,low M2, or

Clause 10’. M1 = (M1 := N1) and M2 = (M2 := N2) with M1 RF,low M2, and N1, N2 ∈ HF,low , andM1, M2 both have type θ ref for some θ and such that 6�F low , or

Clause 11’. M1 = (M1 := N1) and M2 = (M2 := N2) with M1 TF,low M2, and N1 RF,low N2, and M1, M2

both have type θ ref for some θ and such that 6�F low , or

Clause 12’. M1 = (flow F ′ in M1) and M2 = (flow F ′ in M2) with M1 RF∪F ′,low M2.

Clause 13’. M1 = (ı n M1) and M2 = (ı n M2) with M1 RF,low M2.

Clause 14’. M1 = (enable ı in M1) and M2 = (enable ı in M2) with M1 RF,low M2.

Figure 3.5: The relation RF,low

Clause 5’. Here M1 = (M1 N1) and M2 = (M2 N2) with M1 TF,low M2, M1 and M2 are syntactically(F, low)-high functions, and N1 RF,low N2. Clearly we have that M1 ∈ HF,low , so by Lemma 3.4.19also M2 ∈ HF,low . We distinguish two sub-cases:

N1 ∈ HF,low . Then, by induction hypothesis, also N2 ∈ HF,low . Therefore, by Composition of HighExpressions (Lemma 3.4.18) we have that M2 ∈ HF,low .

N1 /∈ HF,low . Then M1†, and by Lemma 3.4.17 also M2†. Therefore, by Composition of High Ex-pressions (Lemma 3.4.18) we have that M2 ∈ HF,low .

Clause 6’. Here M1 = (M1; N) and M2 = (M2; N) where M1 RF,low M2 and N ∈ HF,low . Clearly we havethat M1 ∈ HF,low , so by induction hypothesis also M2 ∈ HF,low . Therefore, by Composition of HighExpressions (Lemma 3.4.18) we have that M2 ∈ HF,low .

30 3.4 Type System Properties

Clause 7’. Here M1 = (M1; N) and M2 = (M2; N) with M1 TF,low M2. Clearly we have that M1 ∈ HF,low ,so by Lemma 3.4.19 also M2 ∈ HF,low . We distinguish two sub-cases:

N ∈ HF,low . Then, M2, N ∈ HF,low . Therefore, by Composition of High Expressions (Lemma 3.4.18)we have that M2 ∈ HF,low .

N /∈ HF,low . Then M1†, and by Lemma 3.4.17 also M2†. Therefore, by Composition of High Expres-sions (Lemma 3.4.18) we have that M2 ∈ HF,low .

Clause 8’. Here M1 = (ref,θ M1) and M2 = (ref,θ M2) where M1 RF,low M2, and 6�F low . Clearly wehave that M1 ∈ HF,low , so by induction hypothesis also M2 ∈ HF,low . Therefore, by Composition ofHigh Expressions (Lemma 3.4.18) we have that M2 ∈ HF,low .

Clause 9’. Here M1 = (! M1) and M2 = (! M2) where M1 RF,low M2. Clearly we have that M1 ∈ HF,low ,so by induction hypothesis also M2 ∈ HF,low . This implies that M2 ∈ HF,low .

Clause 10’. Here we have M1 = (M1 := N1) and M2 = (M2 := N2) where M1 RF,low M2, and N1, N2 ∈HF,low , and M1, M2 both have type θ ref for some θ and such that 6�F low . Clearly we havethat M1 ∈ HF,low , so by induction hypothesis also M2 ∈ HF,low . Therefore, by Composition of HighExpressions (Lemma 3.4.18) we have that M2 ∈ HF,low .

Clause 11’. Here we have M1 = (M1 := N1) and M2 = (M2 := N2) where M1 TF,low M2, and M1, M2

both have type θ ref for some θ and such that 6�F low , and N1 RF,low N2. Clearly we have thatM1 ∈ HF,low , so by Lemma 3.4.19 also M2 ∈ HF,low . We distinguish two sub-cases:

N ∈ HF,low . Then, M2, N ∈ HF,low . Therefore, by Composition of High Expressions (Lemma 3.4.18)we have that M2 ∈ HF,low .

N /∈ HF,low . Then M1†, and by Lemma 3.4.17 also M2†. Therefore, by Composition of High Expres-sions (Lemma 3.4.18) we have that M2 ∈ HF,low .

Clause 12’. Here M1 = (flow F ′ in M1) and M2 = (flow F ′ in M2) with M1 RF∪F ′,low M2. Clearly wehave that M1 ∈ HF,low , so by induction hypothesis also M2 ∈ HF,low . Therefore, by Composition ofHigh Expressions (Lemma 3.4.18) we have that M2 ∈ HF,low .

Clause 13’. Here M1 = (ı n M1) and M2 = (ı n M2) with M1 RF,low M2. Clearly we have that M1 ∈HF,low , so by induction hypothesis also M2 ∈ HF,low . Therefore, by Composition of High Expressions(Lemma 3.4.18) we have that M2 ∈ HF,low .

Clause 14’. Here M1 = (enable ı in M1) and M2 = (enable ı in M2) with M1 RF,low M2. Clearly we havethat M1 ∈ HF,low , so by induction hypothesis also M2 ∈ HF,low . Therefore, by Composition of HighExpressions (Lemma 3.4.18) we have that M2 ∈ HF,low .

We have seen in Splitting Computations (Lemma 3.1.2) that two computations of the same expressioncan split only if the expression is about to read a reference that is given different values by the memoriesin which they compute. Finally, from the following lemma one can conclude that the above relation RF,low

relates the possible outcomes of typable expressions in general.

Lemma 3.4.23 If there exist `,Γ, s, τ such that `;F ; Γ `G E[(! a,θ)] : s, τ with 6�F∪dEe low , then for anyvalues V0, V1 ∈ Val such that `;F ; Γ `G Vi : θ we have E[V0] RF,low E[V1].

31 3.4 Type System Properties

Proof sketch. If a typable expression is about to use a value that results from a high dereference, then thefollowing situations can occur:If the termination effect is low, i.e. if the value cannot influence the termination behavior of the dereference,then by Lemma 3.4.14 any two possible outcomes are in the relation T (see Clauses 5’, 7’ and 11’).Otherwise, if the terminating effect is not low, then the type system must ensure that no low writes fol-low the high dereference (see Clauses 4’, 6’ and 10’). This is partly guaranteed by conditions of the form‘s.t �F s′.w’, where s is the security effect of a subprogram that is performed before another subprogramwhose security effect is s′. More precisely, conditions are imposed when the dereferenced value is used: todetermine a reference that is being assigned to (s.t �F s′.w in rule Assign); to determine a function thatis being applied (s.t �F s′′.w in rule App); to evaluate the first component of a sequential composition(s.t �F s′.w in rule Seq).The relation R requires that the references that are created or written using the high dereferenced value arehigh (see Clauses 8’, 10’ and 11’), and that function applications that use the high dereferenced value aresyntactically high. This is partly guaranteed by conditions of the form ‘s.t �F ’, where s is the securityeffect of a subprogram that performs the high dereference, and is the security level of the reference thatis created or written. More precisely, conditions are imposed when the dereferenced value is used: to createa reference (s.r �F in rule Ref); to determine a reference that is being assigned to (s.r �F in ruleAssign); to determine a value that is being assigned (s′.r �F in rule Assign); to determine a functionthat is being applied (s.r �F s′.w in rule App); to determine an argument to which a function is beingapplied (s′′.r �F s′.w in rule App).When the high dereferenced value is used in the predicate of a conditional, the branches should be opera-tionally high (see Clause 3’). This is guaranteed by the type system with the condition s.r �F st.w, sf .w inrule Cond.

Proof: By induction on the structure of E.

E[(! a,θ)] = (! a,θ). We have V0 RF,low V1 by Clause 1’.

E[(! a,θ)] = (E1[(! a,θ)] M). By rule App we have `;F ; Γ `G E1[(! al,θ)] : s, τs′−−→

κ,Fσ and `;F ; Γ `G

M : s′′, τ with s.r �F s′.w and s.t �F s′′.w. By Lemma 3.4.1, we have �F s.r. Therefore �F s′.w.Since by hypothesis 6�F∪dE1e low (therefore ` 6�F low), then s′.w 6�F low , that is E1[(! al,θ)] isa syntactically (F, low)-high function. By Lemma 3.4.5, the same holds for E1[V0] and E1[V1]. Byinduction hypothesis we conclude that E1[V0] RF,low E1[V1].

s.t 6�F low . Then s′′.w 6�F low (and also s′′.w 6�F low) so by High Expressions (Lemma 3.4.10) wehave M ∈ HF,low . Therefore, we conclude E[V0] RF,low E[V1] by Clause 4’ and Lemma 3.4.5.

s.t �F low . Then by Lemma 3.4.14 we have E1[V0] TF,low E1[V1]. Therefore, since M RF,low M byClause 2’, we conclude that E[V0] RF,low E[V1] by Clause 5’ and Lemma 3.4.5.

E[(! a,θ)] = (V E1[(! a,θ)]). By rule App we have that `;F ; Γ `G V : s, τs′−−→

κ,Fσ and `;F ; Γ `G

E1[(! a,θ)] : s′′, τ with s′′.r �F s′.w. By Lemma 3.4.1, we have �F s′′.r, and so �F s′.w.Since by hypothesis 6�F∪dE1e low (therefore 6�F low), then s′.w 6�F low , that is V is a syntactically(F, low)-high function. By Clause 1 we have V TF,low V . By induction hypothesis E1[V0] RF,low

E1[V1]. Therefore we conclude that E[V0] RF,low E[V1] by Clause 5’ and Lemma 3.4.5.

E[(! a,θ)] = if E1[(! a,θ)] then Mt else Mf . By Cond we have that `;F ; Γ `G E1[(! a,θ)] : s, bool,and `;F ; Γ `G Mt : st, τ and `;F ; Γ `G Mf : sf , τ with s.r �F st.w, sf .w. By Lemma 3.4.1, wehave �F s.r and so �F st.w, sf .w. Since by hypothesis 6�F∪dE1e low (therefore l 6�F low), then

32 3.4 Type System Properties

st.w 6�F low and sf .w 6�F low . This implies that Mt,Mf ∈ HF,low . By induction hypothesis E1[V0]RF,low E1[V1]. Therefore we conclude that E[V0] RF,low E[V1] by Clause 3’ and Lemma 3.4.5.

E[(! a,θ)] = (E1[(! a,θ)]; M). By Seq we have `;F ; Γ `G E1[(! a,θ)] : s, τ and `;F ; Γ `G M : s′, τ ′ withs.t �F s′.w.

s.t 6�F low . Then s′.w 6�F low so by High Expressions (Lemma 3.4.10) we have M ∈ HF,low . Byinduction hypothesis E1[V0] RF,low E1[V1]. We then conclude that E[V0] RF,low E[V1] by Clause6’ and Lemma 3.4.5.

s.t �F low . Then by Lemma 3.4.14 we have E1[V0] TF,low E1[V1]. Therefore, we conclude usingClause 7’ and Lemma 3.4.5.

E[(! a,θ)] = (ref ¯,θ E1[(! a,θ)]). By Ref we have `;F ; Γ `G E1[(! a,θ)] : s, τ with s.r = s.r �F¯ and

s.t = s.t. Therefore, since 6�F∪dEe low implies 6�F∪dE1e low , then by induction hypothesis we haveE1[V0] RF,low E1[V1]. By Lemma 3.4.1 we have �F s.r, so s.r 6�F low . Therefore, ¯ 6�F low , and weconclude by Lemma 3.4.5 and Clause 8’.

E[(! a,θ)] = (! E1[(! a,θ)]). By rule Deref we have `;F ; Γ `G E1[(! a,θ)] : s, τ . By induction hypothesisE1[V0] TF,low E1[V1]. We conclude by Lemma 3.4.5 and Clause 9’.

E[(! a,θ)] = (E1[(! a,θ)] := M). By rule Assign we have that `;F ; Γ `G E1[a,θ] : s, θ ref ¯ with s.r �F¯

and s.t �F s′.w. By Lemma 3.4.1 we have �F s.r, so s.r 6�F low and so ¯ 6�F low .

s.t 6�F low . Then s′.w 6�F low so by High Expressions (Lemma 3.4.10) we have M ∈ HF,low . Byinduction hypothesis E1[V0] RF,low E1[V1]. We then conclude that E[V0] RF,low E[V1] by Clause10’ and Lemma 3.4.5.

s.t �F low . Then by Lemma 3.4.14 we have E1[V0] TF,low E1[V1]. Therefore, we conclude usingLemma 3.4.5, Clause 11’ and Clause 2’ (regarding M).

E[(! a,θ)] = (V := E1[(! a,θ)]). By rule Assign we have that `;F ; Γ `F V : s, θ ref ¯, `;F ; Γ `G

E1[a,θ] : s′, θ with s′.r �F¯. By Lemma 3.4.1 we have �F s′.r, so �F

¯. Then, we musthave ¯ 6�F low , since otherwise �F∪dEe low . By Clause 1 we have that V TF,low V , and by inductionhypothesis E1[V0] RF,low E1[V1]. We then conclude by Lemma 3.4.5 and Clause 11’.

E[(! a,θ)] = (flow F ′ in E1[(! a,θ)]). By rule Flow we have `;F ∪ F ′; Γ `G V : s, τ . By inductionhypothesis E1[V0] TF∪F ′,low E1[V1], so we conclude by Lemma 3.4.5 and Clause 12’.

E[(! a,θ)] = (ı n E1[(! a,θ)]). By rule Restric we have `fG ı;F ; Γ `G V : s, τ . By induction hypothesisE1[V0] TF,low E1[V1], so we conclude by Lemma 3.4.5 and Clause 13’.

E[(! a,θ)] = (enable ı in E1[(! a,θ)]). By rule Enable we have ` gG ı;F ; Γ `G V : s, τ . By inductionhypothesis E1[V0] TF,low E1[V1], so we conclude by Lemma 3.4.5 and Clause 14’.

We now prove a crucial result of this chapter: the relation RF,low is a sort of “strong bisimulation”.

Theorem 3.4.24 (Strong Bisimulation for Typable Low Expressions)If M1 RF,low M2 and M1 /∈ HF,low and ` `G M1, µ1 −→

F ′(M ′

1, µ′1), with µ1 lF∪F ′,low µ2 such that a is fresh

for µ2 if a,θ ∈ dom(µ′1) − dom(µ1), then there exist M ′2 and µ′2 such that ` `G (M2, µ2) −→

F ′(M ′

2, µ′2) with

M ′1 RF,low M ′

2 and µ′1 lF,low µ′2.

33 3.4 Type System Properties

Proof sketch. Assuming that M1 (and M2) are not operationally high allows us to conclude in many casesthat a certain subexpression can compute, using Composition of High Expressions (Lemma 3.4.18). We canthen proceed as in Strong Bisimulation for Low-Terminating Expressions (3.4.15).

Proof:By induction on the definition of RF,low . We use Subject Reduction (Theorem 3.4.6) to guarantee

typability (with the same type) for low and F , which is a requirement for being in the RF,low relation. Wealso use the Strong Bisimulation for Low Terminating Expressions Theorem (Theorem 3.4.15).

Behavior of Typable Expressions

To conclude the proof of the Soundness Theorem, it remains to exhibit an appropriate bisimulation onexpressions.

We now give the definition of R?G,low .

Definition 3.4.25 (R?G,low) The relation R?

G,low is inductively defined as follows:

a)M RG,low N

M R?G,low N

b)M, N ∈ HG,low N R?

G,low L

M R?G,low L

c)M R?

G,low N N, L ∈ HG,low

M R?G,low L

Proposition 3.4.26 The relation R?G,low is a (G, low)-bisimulation.

Proof: By induction on the structure on the relation R?G,low , we can assert the symmetry of this relation.

We further show, by induction on the structure of this relation, that if M R?G,low N , and ` `G (M,µ) −→

F ′

(M ′, µ′), with µ lG∪F ′ν and u,θ ∈ dom(µ′)− dom(µ) implies that u is fresh for ν, there exists a matching

transition from (N, ν).By induction on the inference of MR?

G,lowN . We examine some cases.

• MRG,lowN . If M ∈ HG,low , then M ′ ∈ HG,low , and we have M ′R?G,lowN . The matching transition

for N is ` `G (N, ν) ∗−→ (N, ν), since dom(µ′) ∩ dom(ν) = dom(µ) ∩ dom(ν).

• MR?G,lowL, and L, N ∈ HG,low . By induction hypothesis, there exist L′, such that ` `G (L, µ) ∗−→

(L′, µ′′), where M ′R?G,lowL′, µ′ lG,low µ′′. L′ ∈ HG,low , therefore, M ′R?

G,lowL′, and L′, N ∈ HG,low .From this we get M ′R?

G,lowN , and the matching transition for N is ` `G (N, ν) ∗−→ (N, ν), sincedom(µ′) ∩ dom(ν) = dom(µ) ∩ dom(ν).

We now state the main result of this chapter:

Theorem 3.4.27 (Soundness) If M is typable in the context of the access level `, a global flow policyG and a local policy F , that is if for some Γ, s and τ we have `;F ; Γ `G M : s, τ , then M satisfies thenon-disclosure policy with respect to F ∪G, that is M ∈ND(F ∪G), for all `′.

Proof: By Clause 2’ of Definition 3.4.20, for all choice of security level low , we have MRG,lowM . By rule a)of Definition 3.4.25, we have MR?

G,lowM . The soundness result is an immediate consequence of Proposition3.4.26.

Chapter 4

Security Types for Sessions and Pipelines

4.1 Service Oriented CalculiThe development of the applications distributed over the web (web services) has triggered interest in develop-ment of a new computational paradigm called Service Oriented Computing (SOC). Services are heterogeneouscomputational entities, independently developed, with a high level of autonomy and varying reliability. Whendealing with services, one would have to take into account handling the possible denial of service, verificationof adequacy of the service, or deal with an abandonment of an active interaction. The SOC tends to developlanguages for description and modeling of services and their behaviour, that would have to take all of thisinto account, providing mechanisms for programming decisions and handling consequences.

Therefore, a language for SOC would be expected to provide means of programming safe and secure,possibly complex interactions between clients and services. In that respect, an interaction is defined as aunit of activity in a service-oriented application, which is essentially a conversation between a client andan instance of a service. A conversation consists of exchange of messages, and invocation of subsidiaryservices. Another issue that has to be taken into account is combining of services in order to performa computation, or into a new, more complex service. Such process is called orchestration, consisting oforganizing an synchronizing data flow between different activities.

As a result of a joint research within the project SENSORIA, the Service Centered Calculus (SCC) [8] hasemerged as an interesting proposal. In [21], the authors have proposed the session as a language construct forcommunication based programming. The SCC takes advantage of the session paradigm to model the client– service interaction. In order to ensure the adequacy of service invocation, the bodies of the client and theservice are required to be mutually complementary, i.e. to follow certain predefined protocols, described bysession types.

The Calculus of Services with Pipelines and Sessions (CaSPiS) [9] is a dataflow–oriented successor of theService Centered Calculus (SCC) [8], in which communications can either follow fixed protocols (session) orbe disciplined into data flows (pipelines), using the pipeline constructor inspired by Orc [22].

4.1.1 Services and Security IssuesBesides adequacy fulfillment, when dealing with web services, assurance needs be given that private data willnot become visible to unauthorized bodies. One of the approaches to provide such guarantees is to introduceinto the language mechanisms for controlling access rights [39, 4, 38, 33, 19, 10].

Consider, for example, a service which keeps track of grades of a University course. The name of theservice is UnivRec, and it offers two possibilities of record manipulation. A student (code guarded withlevel student) is allowed to access his grade for a given course by sending the service his file–number (the

34

35 4.2 The Language

StudentId) and the number of the course (the CourseId), to which the service responds by outputting hisgrade as a result of a function grade. Only a teacher (code guarded with level teacher) can be allowed toupdate the grades by calling a service update, which changes the grade records for the given student andcourse ID.

Example 4.1.1

UnivRec. (studentn ((check).(StudentId).(CourseId).〈grade(CourseId)〉+(update).(StudentId).(CourseId).(grade).〈fail〉)]

teachern ((check).(StudentId).(CourseId).〈grade(CourseId)〉+(update).(StudentId).(CourseId).(grade).〈success〉.

update.〈CourseId〉.〈grade〉))

Assuming that the privileges of a student are less than those of a teacher, this service should provide both theinterface for a student and a teacher, rejecting student’s attempt to update the grades (and in this example,informing him of the failure), while when activated by the teacher, the update operation is allowed, and theupdate service is activated on teacher’s behalf.

4.2 The Language

4.2.1 SyntaxThe present calculus is essentially the calculus of [12] enriched with security levels. To this aim we haveconsidered session types decorated by security levels and designed a type system that guarantees both safecommunications and data security. As usual [6, 15] we assume a lattice of security levels: we use `, ı, κ torange over security levels and v,t,u to denote partial order, join and meet, respectively.The syntactical constructs are listed in Figure 4.1, where syntax occurring only at runtime appears shaded ,in order of non-increasing precedence. More precisely the prefixes in lines 2-7 have the precedence over theconstructors on lines 8-11 and the remaining constructors have decreasing precedence, but for the restrictionswhich have the same precedence.Values (ranged over by u, v, w) can be either basic values, variables, function calls, services or session names.In well-typed processes only the first two kinds of values can be exchanged, while all kinds of values canappear in the conditions of pattern matching.

• the nil process 0, as usual, denotes inactivity;

• the input construct (x).P , inherited from process calculi, such as π–calculus, receives a value x and con-tinues as P . Input construct binds the name of the value, which acts as a placeholder until replacementby the actual value when communication occurs;

• the output process 〈x〉P , dual of input, emits the value x and then continues as P ;

• the label sum, or the label branching∑n

i=1(li).Pi, offers multiple choice of continuation processes,guarded by different labels, for external choice;

• the label choice 〈l〉.P , or internal choice, is a dual of label selection, and selects one of the labels fromthe label sum when the synchronization occurs;

• the return construct return v.P emits the value v to the parent session, and continues as P ;

36 4.2 The Language

Processes P, Q, R ::= 0 nil| (x).P input| 〈v〉.P output| return v.P value return| 〈l〉.P label choice| s.P service definition| v.P service invocation|

Pni=1(li).Pi label–guarded sum

|Un

i=1 `i n Pi level–guarded sum| ` J P framed process| rp . P session| P > x > Q pipe| P | Q parallel composition| if u = v then P else Q matching| (ν s) P service restriction| (ν r) P session restriction

Values u, v, w ::= b base value| x variable| f(v) function call| s service| r session

Polarities p ::= +,−

Figure 4.1: Syntax.

• the pipe constructor P > x > Q is inspired by [22]: each time the process P produces an output value,a new copy of Q is freshly spawned variable in parallel, with the variable x replaced by the actual valueoutputted by P ;

• the level-guarded sum⊎n

i=1 `i n Pi is similar to the test constructs from the access control domain: itoffers continuations with different security clearance, depending on the dynamic reduction context;

• the framed process ` J P grants the process with body P security clearance not exceeding `;

• the service invocation s.P invokes a service s and continues as P ;

• the service definition s.P publishes a service with name s and with body P ;

• the session construct rp . P denotes an active session with body P and polarity p.

Service definitions are permanent: a new occurrence of the session body is created and put in parallelwhen the service is called.

Characteristic of our approach to security are framed processes [33, 19, 10]: in ` J P the process P canexercise rights of security level not exceeding `. So a service invocation ` J s.P is well typed only if thesecurity level ` is not lower than the security level of s. Framed processes are also necessary in order toreduce level-guarded sums: an arbitrary branch whose level is less than or equal to that of the current framecan be chosen.

Service calls can be nested and the value return prefix allows to send a value to the upper nesting level.

37 4.2 The Language

(Inv) D[[` J s.P , s.Q]] → (ν r) D[[r− . ` J P , r+ . ` J Q | s.Q]]r 6∈ fn(D[[s.P , s.Q]])

(Com) Dr[[(x).P , 〈v〉.Q]] → Dr[[P [v/x], Q]](Lcom) Dr[[

∑ni=1(li).Pi, 〈lk〉.Q]] → Dr[[Pk, Q]]

(Ret) Dr1 [[(x).P , Crp [[return v.Q]]]] → Dr1 [[P [v/x], Crp [[Q]]]](Pipe) C[[〈v〉.P > x > Q]] → C[[P > x > Q | Q[v/x]]](PipeRet) C[[Crp [[return v.P ]] > x > Q]] → C[[Crp [[P ]] > x > Q | Q[v/x]]](IfT) C[[if u = v then P else Q]] → C[[P ]] (u = v) ↓ true(IfF) C[[if u = v then P else Q]] → C[[Q]] (u = v) ↓ false(LevSel) C[[` J

⊎ni=1 `i n Pi]] → C[[` J Pi]] if `i v `

(End) C[[` J 0]] → C[[0]](Scop) P → P ′ ⇒ (ν m)P → (ν m) P ′

(Str) P ≡ P ′ ∧ P ′ → Q′ ∧ Q′ ≡ Q ⇒ P → Q

Figure 4.2: Reduction Rules

P | 0 ≡ P P | Q ≡ Q | P (P | Q) | R ≡ P | (Q | R) (ν m)0 ≡ 0(ν m) (ν m′) P ≡ (ν m′) (ν m) P ((ν m) P ) | Q ≡ (ν m) (P | Q) if m 6∈ fn(Q)

((ν m) P ) > x > Q ≡ (ν m) (P > x > Q) if m 6∈ fn(Q)rp . (ν m) P ≡ (ν m) (rp . P ) if r 6= m ` J (ν m)P ≡ (ν m) (` J P )

(P | R) > x > Q ≡ (P > x > Q) | (R > x > Q) ` J (P | Q) ≡ ` J P | ` J Q0 > x > Q ≡ 0 (rp . 0) > x > Q ≡ rp . 0

(ν r) (r+ . 0 | r− . 0) ≡ 0 rp . (P | rq1 . 0) ≡ rp . P | rq

1 . 0

Figure 4.3: Structural Equivalence

A session name has two polarized session ends, the client side − and the service side +, one being dualto the other. At runtime fresh session names with opposite polarities are generated and restricted. Allcommunications of values and labels are executed inside the scopes of the same session names with oppositepolarities.

4.2.2 Operational SemanticsThe operational semantics by means of reduction rules is given in Figure 4.2, as proposed in the appendix ofthe technical report of the original paper [12], instead of a labeled transition system as in the final versionof [12]. We let m range over service and session names.We use evaluation contexts with either one or two holes. The evaluation contexts with two holes are necessaryin order to model the interaction between two processes. Moreover we express through contexts the conditionthat a process is in the scope of some session name with a given polarity. More precisely we define thefollowing four kinds of evaluation contexts:

C ::= [[ · ]] | C | P | rp . C | C > x > P | ` J [[ · ]]Crp ::= rp . ` J [[ · ]] | PD ::= C[[C′ | C′′]]Dr ::= D[[C′

rp , C′′rp ]] r 6∈ fn(D)

The Figure 4.3 contains rules for the structural equivalence of processes. Rules in the first line are

38 4.2 The Language

standard rules for commutativity and associativity and neutrality of 0 w.r.t. parallel composition andgarbage collection of restrictions for the exhausted processes. Rules in the second and the third line enablecommutation of restrictions and scope extrusion w.r.t. parallel composition and pipe, session and securityframing construct. The rules in the fourth line enable splitting the pipe and security framing betweenparallelly composed processes. The last but one line contains garbage collection rules for pipes of exhaustedprocesses and sessions. The rules in the last line are, respectively, garbage collection of exhausted sessionsand un-nesting of exhauted session. In rule (Inv) a client of level ` calls a service: the body of the clientand a copy of the body of the service are framed by the client level ` and prefixed by two occurrences of thefreshly generated and private session name r with opposite polarities.

In rules (Com) and (Lcom) two processes in the scopes of the same session name with opposite polaritiesexchange values and labels, respectively. When a label is received, the execution of the label-guarded sumcontinues with the corresponding process.

Rule (Ret) allows the inner session (named r) to communicate the value v to the outer session (namedr1).

In rules (Pipe) and (PipeRet) a new parallel copy of Q is created: in this copy the value v replaces thevariable x. The difference between these rules is that in the first one the value v is sent by an output prefix,while in the second one the value v is sent by a return prefix that occurs in an inner session (named r).

The rule (LevSel) non deterministically chooses a process whose security level is less than or equal tothe level of the current frame.

Finally, rule (End) discards the security framing of an exhausted process. It has not been formulated asa rule of structural equivalence in order to preserve the invariance of typability under structural equivalenceof subjects.

The remaining rules are standard. The structural equivalence is as usual, but for the rules dealing withsecurity levels and sessions. The last three rules are, respectively, garbage collection of pipes of exhaustedcode, garbage collection of exhausted sessions and pushing the exhausted nested session outside of the scopeof the parent session. We also consider structurally equivalent processes which can be obtained by α-renamingbound and restricted variables.

It is interesting to notice that CaSPiS mixes linear communication inside and between sessions withnon–linear communication due to the pipe construct.

We end this section with an example to illustrate process reduction.

Example 4.2.1 We can define a service sqr that computes the square of a given number by calling a servicemul, which in turn returns the product of two given numbers. More precisely if we define the processes:

C = sqr.(x).N

N = mul.〈x〉.〈x〉.(y). return y. 0

M = mul.(x)(y).〈x ∗ y〉. 0

P = ⊥ J sqr.〈5〉.(y). 0

then the reduction is as follows, omitting the restrictions:

(1) C | M | P(Inv)−−−−→

(2) r− . ⊥ J 〈5〉.(x).0 | r+ . ⊥ J (x).N | C | M(Com)−−−−−→

(3) r− . ⊥ J (x).0 | r+ . ⊥ J mul.〈5〉.〈5〉.(y). return y. 0 | C | mul.(x)(y).〈x ∗ y〉. 0(Inv)−−−−→

(4) r− . ⊥ J (x).0 | r+ . r−1 . ⊥ J 〈5〉.〈5〉.(y). return y. 0 | r

+1 . ⊥ J (x)(y).〈x ∗ y〉. 0 | C | M

(Com)−−−−−→

(Com)−−−−−→

(5) r− . ⊥ J (x).0 | r+ . r−1 . ⊥ J (y). return y. 0 | r

+1 . ⊥ J 〈10〉. end | C | M

(Com)−−−−−→

(6) r− . ⊥ J (x).0 | r+ . r−1 . ⊥ J return 10. 0 | r

+1 . ⊥ J end | C | M

(Ret)−−−−−→

(7) r− . ⊥ J 0 | r+ . r−1 . ⊥ J 0 | r

+1 . ⊥ J end | C | M

(End)−−−−−→

(End)−−−−−→

(End)−−−−−→

(8) r− . 0 | r+ . r−1 . 0 | r

+1 . 0 | C | M≡

(9) C | M

39 4.3 Type System

T, U ::= end (no action)| ?(S`).T (input of a value)| !(S`).T (output of a value)| &{l1 : T1, . . . , ln : Tn} (external choice)| ⊕{l1 : T1, . . . , ln : Tn} (internal choice)| ]{`1, . . . , `n} ∝ T (level choice)

S` ::= [T ]` (session type)| B` (basic type)

Figure 4.4: Syntax of Types

end = end

?(S`).T = !(S`).T

!(S`).T ′ = ?(S`).T ′

⊕{l1 : T1, . . . , ln : Tn} = &{l1 : T 1, . . . , ln : T n}&{l1 : T1, . . . , ln : Tn} = ⊕{l1 : T 1, . . . , ln : T n}

]{`1, . . . , `n} ∝ T = ]{`1, . . . , `n} ∝ T

Figure 4.5: Duality Mapping

4.3 Type SystemThe type system is a security annotated variant of the type system in [12], consisting of sorts and sessiontypes.Each session type T describes a communication protocol, which may consist of:

• no communication, if T = end;

• the input of a value of type S` followed by the protocol described by T ′, if T =?(S`).T ′;

&{l1 : T1, . . . , ln : Tn} ≤ &{li : Ti}i∈I

⊕{li : Ti}i∈I ≤ ⊕{l1 : T1, . . . , ln : Tn}]{`1, . . . , `n} ∝ T ≤ ]{`i}i∈I ∝ T if ∃j ∈ I.`j =

di∈I `i

(1 ≤ i ≤ n) Ti ≤ T ′i ⇒

&{l1 : T1, . . . , ln : Tn} ≤ &{l1 : T ′

1, . . . , ln : T ′n}

⊕{l1 : T1, . . . , ln : Tn} ≤ ⊕{l1 : T ′1, . . . , ln : T ′

n}

T ≤ T ′ ⇒

8<:!(S`).T ≤!(S`).T

?(S`).T ≤?(S`).T′

]{`1, . . . , `n} ∝ T ≤ ]{`1, . . . , `n} ∝ T ′

where I ⊆ {1, . . . , n}.

Figure 4.6: Subtyping Relation ≤

40 4.3 Type System

Γ, s : S` ` s : S` (Service) Γ, x : S` ` x : S` (Var)τ b ∈ B`

Γ ` b : τ b`

(BasVal)

Γ ` v(1) : S(1)`1

. . . , Γ ` v(n) : S(n)`n

τ bı ∈ B `1 t . . . t `n v ı

Γ, f : S(1)`1

× · · · × S(n)`n

→ τ bı ` f(v(1), . . . , v(n)) : τ b

ı

(Fun)

Γ ` 0 : end ∴⊥[end]⊥ (Nil)Γ ` P : U ∴ ı[T ]κ Γ ` v : [T ′]` T ′ ≤ T

Γ ` v.P : end ∴⊥[U ]κt`tı

(Inv)

Γ, x : S` ` P : U ∴ ı[T ]κ

Γ ` (x).P : U ∴ ı[?(S`).T ]κt`

(Inp)Γ ` P : U ∴ ı[T ]κ Γ ` v : S`

Γ ` 〈v〉.P : U ∴ ı[!(S`).T ]κt`

(Out)

Γ ` P : U ∴ ı[T ]κ Γ ` v : S`

Γ ` return v.P :!(S`).U ∴ ıt`[T ]κ

(Ret)

Γ ` Pi : U ∴ ı[Ti]κi (1 ≤ i ≤ n)

Γ `Pn

i=1(li).Pi : U ∴ ı[&{l1 : T1, . . . , ln : Tn}]κ1t...tκn

(Branch)

l = li i ∈ {1, . . . , n} Γ ` Pi : U ∴ ı[Ti]κi

Γ ` 〈l〉.P : U ∴ ı[⊕{l1 : T1, . . . , ln : Tn}]κ1t...tκn

(Choice)

Γ ` P : U ∴ ı[T ]κ Γ, x : S` ` Q : U ′ ∴ ı′ [T ′]κ′

pipe(U ∴ ı[T ]κ, U ′ ∴ ı′ [T ′]κ′ , S`) = U ′′ ∴ ı′′ [T ′′]κ′′

Γ ` P > x > Q : U ′′ ∴ ı′′ [T ′′]κ′′

(Pipe)

Γ ` vi : S`i Γ ` P : U ∴ ı[T ] Γ ` Q : U ∴ ı[T ]κ `i v u κ i = 1, 2

Γ ` if v1 = v2 then P else Q : U ∴ ı[T ]tκ

(If)

Γ ` Pi : U ∴ ı[T ]κi κi v `i (1 ≤ i ≤ n) ∃j(1 ≤ j ≤ n).`1 u . . . u `n = `j

Γ `Un

i=1 `i n Pi : U ∴ ı[]{`1, . . . , `n} ∝ T ]`j

(LevSel)

Γ ` P : U ∴ ı1 [T1]κ1 Γ ` Q : U ′ ∴ ı2 [T2]κ2

Γ ` P | Q : U ◦ U ′ ∴ ı1tı2 [T1 ./ T2]κ1tκ2

(Par)

Figure 4.7: Typing Rules for Inner Processes

41 4.3 Type System

pipe(U ∴ ı[end]κ, U ′ ∴ ı′ [T ′]κ′ , S`) = U ∴ ı[end]κ

pipe(U ∴ ı[!(S`).end]κ, U ′ ∴ ı′ [T ]κ′ , S`) = U ◦ U ′ ∴ ıtı′ [T ]κtκ′

pipe(U ∴ ı[!(S`)h.end]κ, U ′ ∴ ı′ [end]κ′ , S`) = U ◦ U ′h ∴ ıtı′ [end]κtκ′ h > 1

Figure 4.8: Function pipe

Γ `∅ 0 : end ∴⊥[end]⊥ (NilI)

Γ ` P : end ∴⊥[T ]κ Γ ` s : [T ]` κ v `

Γ `{s} s.P : end ∴⊥[end]κ

(ServDef)

Γ `S1 P : end ∴⊥[end]κ1 Γ `S2 Q : end ∴⊥[end]κ2

Γ `S1∪S2 P | Q : end ∴⊥[end]κ1tκ2

(TopPar)

Γ ` P : end ∴⊥[end]κ κ v `

Γ `∅ ` J P : end ∴⊥[end]`

(LevSign)

Γ, s : S `S,s P : end ∴⊥[end]κ

Γ `S (ν s) P : end ∴⊥[end]κ

(ServRestr)

Figure 4.9: Typing Rules for Top Level Processes

Γ ` P : end ∴⊥[end]κ

Γ `∅ P : end ∴⊥[end]κ

(ToTop)Γ ` P : U ∴ ı[T ]κ ı t κ v `

Γ ` ` J P : U ∴ ı[T ]`(LevSignRT)

Γ ` P : U ∴ ı[T ]κ

Γ, r : [T ]κ ` r+ . P : end ∴⊥[U ]ıtκ

(Sess)Γ ` P : U ∴ ı[T ]κ T ′ ≤ T

Γ, r : [T ′]κ ` r− . P : end ∴⊥[U ]ıtκ

(SessI)

Γ, r : S` ` P : U ∴ ı[T ]κ

Γ ` (ν r) P : U ∴ ı[T ]κ(SessRestr)

Γ, r : S` `S P : end ∴⊥[end]κ

Γ `S (ν r) P : end ∴⊥[end]κ

(SessRestrTop)

Figure 4.10: Typing Rules for Runtime Processes

42 4.3 Type System

• the output of a value of type S` followed by the protocol described by T ′, if T =!(S`).T ′;

• the reception of a label li chosen in the set {l1, . . . , ln} followed by the protocol described by Ti, ifT = &{l1 : T1, . . . , ln : Tn};

• the transmission of a label li chosen in the set {l1, . . . , ln} followed by the protocol described by Ti, ifT = ⊕{l1 : T1, . . . , ln : Tn};

• the choice of a process with security level `i ∈ {`1, . . . , `n}, with `i less than or equal to the currentsecurity level, followed by the protocol described by T ′, if T = ]{`1, . . . , `n} ∝ T ′.

Basic data types are decorated with their security levels (cf. [41]), and the security levels appearing in annota-tion of session types represent the join of the levels of data manipulated inside the session by communicationand activation.

A typing environment Γ is a finite partial mapping from variables, services and sessions to sorts (i.e.session types and basic types) and function types. The empty environment is denoted by ∅, and if u is avariable, a service or a session name, then Γ, u : S` is the extension with the binding of u to S`, if u 6∈ dom(Γ).The extension for a function name with a function type is defined similarly.The typing judgments have the form Γ ` v : S` for the values, and Γ ` P : U ∴ ı[T ]κ for processes, where Uis the output (sequence of outputs) of the process P to the parent session with the level ı, and T is the typeof P ’s activities in the current session, and κ is the level of values communicated in the current session andin all of the nested sessions.

Rules (Service), (Var), (BasVal) and (Fun) are standard typing rules for values. Rule (Fun) inserts anexternal function in the typing environment while ensuring that the level of the function output is not lessthan the level of its arguments.

The type end ∴⊥[end]⊥ of 0 (rule (Nil)) means that no action is performed neither in the current nor inthe parent session.

Rules for input and output of a value ((Inp), (Out)) add the performed action to the current session type,and increase the level assigned to the current session by the level of the communicated value.Rule (Ret) adds the output of a value to the return sequence U , updating its level in a similar way.

Rules (Branch) and (Choice) for internal and external choice take the join of levels of all the branches asthe current session level.Rule (If) is the standard conditional branching on the result of the comparison of two values, which does notallow low–level branches to depend on high–level values in the choice.Rule (Par)is used to type the parallel composition of two processes. The composition is possible if at leastone of them does not have any action in the current session. Therefore, the operator ./ is defined only whenone of the types is end:

T ./ T ′ =

T ′, if T = endT, if T ′ = endundefined otherwise

Two parallel processes can both offer outputs to the parent session when there is no way of distinguishingthe outputs at the type system level. The composition of outputs used in rule rule (Par) is defined asU ◦ U ′ =!(S`)h+k.end if U =!(S`)h.end and U ′ =!(S`)k.end, i.e. U and U ′ are sequences of the same output,and undefined otherwise.

Rule (Pipe) derives the type of pipe using the function pipe, given in Figure 4.8. If P outputs a singlevalue (and has no other action in the current session), the pipe Q consumes the value, and may have otheractions in the current session. If the current session activity of P consists of a sequence of h outputs whereh > 1, h instances of Q will be activated to consume the outputs and put in parallel with P , but Q will onlybe allowed to produce values upwards to the parent session. If Q will be activated, the outputs of P and Qwill be composed as in parallel composition.

43 4.3 Type System

The innovation with respect to the type system in [12] is rule (LevSel). It is similar to the test–rule inaccess control typing systems [33, 19, 10]. Each branch of the choice is guarded with a security level greaterthan or equal to the one necessary for its activation. The level of the session type is increased to take intoaccount only the least of the branch–levels. Since all the branches have the same type, differing only inthe security annotation, the process is required to have at least the privilege to activate the lowest one,but depending on the process privileges, one of the higher branches may be selected. This rule permits abetter modularity of service definitions, allowing the same service to offer both high and low–level response,depending on the clearance of the client who activated it.

Rule (Inv) for session invocation allows a process to invoke a session if its body matches the definedsession w.r.t the duality mapping, defined in Figure 4.5. The type of the defined session is required to bea subtype of the client’s dual (in the sense of the relation inspired by [20], defined in Figure 4.6). This isjustified by reasoning that the service can offer more choices than required by the client (with label and levelbranching), and that different clients may make different choices. After the process has been prefixed withservice invocation, the return sequence U becomes the current session usage, and its level, together with thelevel of the invoked session is added to the level of the current session.

A top level process is a process of type end ∴⊥[end]κ, which means that it has no activity in the currentsession, and produces no value upwards. The typing of the top level processes is given in Figure 4.9. Thetyping judgments of the top level processes have the form Γ `S P : end ∴ ⊥[end]κ, where S is the set ofdefined services.

An initial configuration consists of parallel compositions of service definitions and framed top level clientprocesses.

Rule (ServDef) defines a service with as body the process P . Each time a service is defined, the turnstileis decorated with its name, and when processes are parallelly composed (rule (TopPar)), the sets of definedservices are joined. When we want to restrict a service name (rule (ServRestr)), it is required that this nameis already defined (i.e. present in S), and after restricting it, we remove it from the set S. In this way weprevent calls of nonexistent services.

Rule (LevSign) promotes an inner process P to the top level process ` J P by assignment of a securityclearance ` only if the intended activity of P (reflected in the level κ) agrees with `.

By requiring that the initial configuration consists only of top level processes, we avoid stuck configura-tions of dangling communications outside of sessions waiting for synchronization.

The typing of the processes that appear only at runtime is given in Figure 4.10.Rule (ToTop) promotes an inner process to become a top level process. Since this rule is only applied at

runtime it can avoid to check the absence of dangling communications.At runtime also inner processes can be framed, ad therefore rule (LevSignRT) is needed in order to type

them.Rules (Sess) and (SessI), similarly to the rules for service invocation and definition, require a session

matching the type of the session body process P in the typing environment. The difference between thesepairs of rules is that the assumptions for sessions are added in the conclusions of the typing rules, while theassumptions for the services must be always present in the premises of the typing rules. The reason is thatwe want to allow nested calls of the same service name, but not nested usages of the same session name.

Rules (SessRestr) and (SessRestrTop) restrict the session name and remove it from the environment. Tworules are needed since both inner and top level processes can be restricted.

Example 4.3.1 We put your type assignment system at work to type some of the processes shown in Example4.2.1, assuming the level of all integers and services being ⊥.

Let T = [?(Int⊥).?(Int⊥).!(Int⊥).end]⊥, T ′ = [?(Int⊥).!(Int⊥).end]⊥, and Γ = {mul : [T ]⊥, sqr : [T ′]⊥}.

44 4.3 Type System

We can type N, C, M and P as follows:

Γ, x : Int⊥, y : Int⊥ ` 0 : end ∴⊥[end]⊥

Γ, x : Int⊥, y : Int⊥ ` return y. 0 :!(Int⊥).end ∴⊥[end]⊥

(Ret)

Γ, x : Int⊥ ` (y).return y. 0 :!(Int⊥).end ∴⊥[?(Int⊥).end]⊥

(Inp) Γ, x : Int⊥ ` x : Int⊥

Γ, x : Int⊥ ` 〈x〉.(y). return y. 0 :!(Int⊥).end ∴⊥[!(Int⊥).?(Int⊥).end]⊥

(Out) Γ, x : Int⊥ ` x : Int⊥

Γ, x : Int⊥ ` 〈x〉.〈x〉.(y). return y. 0 :!(Int⊥).end ∴⊥[T ]⊥

(Out) Γ, x : Int⊥ ` mul : [T ]⊥

Γ, x : Int⊥ ` N : end ∴⊥[!(Int⊥).end]⊥

(Inv)

Γ, x : Int⊥ ` N : end ∴⊥[!(Int⊥).end]⊥

Γ ` (x).N : end ∴⊥[?(Int⊥).!(Int⊥).end]⊥(Inp) Γ ` sqr : [T ′]⊥

Γ `{sqr} C : end ∴⊥[end]⊥(ServDef)

Γ, x : Int⊥, y : Int⊥ ` 0 : end ∴⊥[end]⊥ Γ, x : Int⊥, y : Int⊥ ` x ∗ y : Int⊥

Γ, x : Int⊥, y : Int⊥ ` 〈x ∗ y〉. 0 : end ∴⊥[!(Int⊥).]⊥

(Out)

Γ, x : Int⊥ ` (y).〈x ∗ y〉. 0 : end ∴⊥[?(Int⊥).!(Int⊥).end]⊥

(Inp)

Γ ` (x).(y).〈x ∗ y〉. 0 : end ∴⊥[T ]⊥

(Inp) Γ ` mul : [T ]⊥

Γ `{mul} M : end ∴⊥[end]⊥

(ServDef)

Γ, x : Int⊥ ` 0 : end ∴⊥[end]⊥

Γ ` (x).0 : end ∴⊥[?(Int⊥).end]⊥(Inp) Γ ` 5 : Int⊥

Γ ` 〈5〉.(x).0 : end ∴⊥[!(Int⊥).?(Int⊥).end]⊥(Out) Γ ` sqr : [T ′]⊥

Γ ` sqr.〈5〉.(x).0 : end ∴⊥[end]⊥(Inv)

Γ ` P : end ∴⊥[end]⊥(LevSign)

By applying the rules for service restriction and parallel composition, we can conclude:

∅ `∅: (ν mul) (ν sqr) (C | M | P) : end ∴⊥[end]⊥

We give now the typing for the process in line (3) of Example 4.2.1. We define N∗ =mul.〈5〉.〈5〉.(y). return y. 0: it is easy to verify that we can derive Γ ` N∗ : end ∴ ⊥[!(Int⊥).end]⊥ with aderivation similar to that one for N.

45 4.4 Example

Γ ` N∗ : end ∴⊥[!(Int⊥).end]⊥

Γ ` ⊥ J N∗ : end ∴⊥[!(Int⊥).end]⊥

(LevSignRT)

Γ, r : [T ′]⊥ ` r− . ` J N∗ : end ∴⊥[end]⊥

(SessI)

Γ, x : S⊥ ` 0 : end ∴⊥[end]⊥

Γ ` (x).0 : end ∴⊥[?(Int⊥).end]⊥

(Inp)

Γ ` ` J (x).0 : end ∴⊥[?(Int⊥).end]⊥

(LevSignRT)

Γ, r : [T ′]⊥ ` r+ . ` J (x).0 : end ∴⊥[end]⊥

(Sess)

Γ, r : [T ′]⊥ ` r− . ` J N∗ | r+ . ` J (x).0 : end ∴⊥[end]⊥

(Par)

Γ ` (ν r) r− . ` J N∗ | r+ . ` J (x).0 : end ∴⊥[end]⊥

(SessRestr)

Note that the types of the processes constituting the two bodies of the same session name with oppositepolarities are each other’s dual.

With applications of rules (ToTop), (TopPar), and (ServRestr) the type of the entire configuration is:

∅ `∅ (ν mul) (ν sqr) ((ν r) r− . ` J N∗ | r+ . ` J (x).0) | M | C : end ∴⊥[end]⊥

We end the example inferring types for some interesting subrprocesses of the process in line (4) of Example4.2.1.

Γ, y : Int⊥ ` 0 : end ∴⊥[end]⊥ Γ ` y : Int⊥

Γ, y : Int⊥ ` return y. 0 :!(Int⊥).end ∴⊥[end]⊥

(Ret)

Γ ` (y).return y. 0 :!(Int⊥).end ∴⊥[?(Int⊥).end]⊥ Γ ` 5 : Int⊥

(Inp)

Γ ` 〈5〉.(y). return y. 0 :!(Int⊥).end ∴⊥[!(Int⊥).?(Int⊥).end]⊥ Γ ` 5 : Int⊥

(Out)

Γ ` 〈5〉.〈5〉.(y). return y. 0 :!(Int⊥).end ∴⊥[!(Int⊥).!(Int⊥).?(Int⊥).end]⊥

(Out)

Γ ` ⊥ J 〈5〉.〈5〉.(y). return y. 0 :!(Int⊥).end ∴⊥[!(Int⊥).!(Int⊥).?(Int⊥).end]⊥

(LevSignRT)

Γ, r1 : [T ]⊥ ` r−1 . ⊥ J 〈5〉.〈5〉.(y). return y. 0 : end ∴⊥[!(Int⊥).end]⊥

(SessI)

Γ, r : [T ′]⊥, r1 : [T ]⊥ ` r+ . r−1 . ⊥ J 〈5〉.〈5〉.(y). return y. 0 : end ∴⊥[end]⊥

(Sess)

Γ, x : Int⊥, y : Int⊥ ` 0 : end ∴⊥[end]⊥ Γ, x : Int⊥, y : Int⊥ ` x ∗ y : Int⊥

Γ, x : Int⊥, y : Int⊥ ` 〈x ∗ y〉. 0 : end ∴⊥[!(Int⊥).end]⊥

(Out)

Γ, x : Int⊥ ` (y).〈x ∗ y〉. 0 : end ∴⊥[?(Int⊥).!(Int⊥).end]⊥

(Inp)

Γ ` (x).(y).〈x ∗ y〉. 0 : end ∴⊥[T ]⊥

(Inp)

Γ ` ⊥ J (x).(y).〈x ∗ y〉. 0 : end ∴⊥[T ]⊥

(LevSignRT)

Γ, r1 : [T ]⊥ ` r+1 . ⊥ J (x).(y)〈x ∗ y〉. 0 : end ∴⊥[end]⊥

(Sess)

4.4 ExampleWe give an example of an e–commerce service, such as e–bay. Three levels of users are assumed – guests,with level 1, which do not have an account with the service, and who are allowed only to browse through theitems in the catalogue. The registered users have a level 2, and they are additionally allowed to bid for anitem, or buy an item that is for direct sale, but are allowed to pay for it only by sending a personal cheque.The VIP–users with the level 3 can also pay with credit card or PayPal account. We assume that 1 v 2 v 3.

46 4.5 Properties

Example 4.4.1P = 〈catalogue1〉(itemNo1)〈price1(itemNo1)〉 Q = pay.〈bid1〉.〈cheque〉.〈personalId1〉,R = pay.〈bid1〉.if (payMeth3(personalId1) = 1) then 〈cheque〉.〈personalId1〉else if (payMeth3(personalId1) = 2) then 〈card〉.〈cardNb3(PersonalId2)〉 else〈paypal〉.〈accPars3(PersonalId2)〉we can define the services ebay, pay, card and paypal as follows:ebay1. (1 n ((browse).P + (bid).(itemNo1).(bid1).(personalId1)

+(buy).(itemNo1).(personalId1))] 2 n ((browse).P + (bid).(itemNo1).(bid1).(personalId1).

if highestBid1(itemNo1) = bid1 then Q else 0+(buy).(itemNo1).Q)

] 3 n ((browse).P + (bid).(itemNo1).(bid1).(personalId1).if highestBid1(itemNo1) = bid1 then R else 0

+(buy).(itemNo1).(personalId1).R))

pay2.(amount1). (2 n ((cheque).(personalId1)+(card)(cardPar2) + (paypal)(accountPar2))

] 3 n ((cheque).(personalId1)+(card).(cardNo3).card.〈amount1〉.〈cardNo2〉+(paypal).(accountPars2).

paypal.〈amount1〉.〈accountPars2〉))

card3.(amount1).(cardNo2)

paypal3.(amount1).(accountPars2)

The service ebay offers essentially three kinds of services: browsing through the item catalogue, bidingfor an item (with obligatory purchase of the customer who won the bid) and buying an item that is put fordirect sale. Options for bidding and buying are different for users and VIP–users, since the VIP–users areallowed different payment methods based on their preference (retrieved by the function payMeth), while theordinary users automatically have to pay by sending a personal cheque.

The payment is done by activating a service pay, which for a received amount triggers a payment methodbranch, which, in turn, might activate services that handle card and PayPal payments (services card andpaypal, respectively).

The more interesting assumptions in the environment for typing ebay are (we omit the end terminators):paypal : [?(int1).?(string2)]3, card : [?(int1).?(int2)]3,pay : [?(int1). ] {2, 3} ∝ &{(cheque) :?(string1), (card) :?(int2)}, (paypal) :?(string2)]2,ebay : []{1, 2, 3} ∝ &{(browse) :?(string1).!(int1).?(int1),

(bid) :?(int1).?(int1).?(string1),(buy) :?(int1).?(string1)}]1.

Notice that although some options reserved for high users are formally (in name) present among the lowerlevel choices, the actual activation of high–level services and communication of high–level data is reservedfor high users.

4.5 Properties

4.5.1 Subject ReductionFirstly, we will discuss the Subject Reduction property, namely that typability of expressions is preserved bythe reduction relation. We start by showing standard auxiliary properties, such as strengthening, weakening,

47 4.5 Properties

end <: T T <: TT <: ?(S`).T T <: !(S`).TTi <: &{l1 : T1, . . . , ln : Tn} Ti <: ⊕{l1 : T1, . . . , ln : Tn}T <: ]{`1, . . . , `n} ∝

Figure 4.11: Consumption Relation <:

typing invariance under structural equivalence and substitution.

Lemma 4.5.1

1. If Γ, x : S` ` P : U ∴ ı[T ]κ and x 6∈ fv(P ), then Γ ` P : U ∴ ı[T ]κ

2. If Γ ` P : U ∴ ı[T ]κ, and x 6∈ dom(Γ) then Γ, x : S` ` P : U ∴ ı[T ]κ

Lemma 4.5.2 (Invariance of Typing under Structural Equivalence) If Γ ` P : U ∴ ı[T ]κ and P ≡Q then Γ ` Q : U ∴ ı[T ]κ.

Proof: by cases on the definition of structural equivalence. We give proofs only for interesting cases.Case (ν r) (r+ . 0 | r− . 0) ≡ 0The typing of the l.h.s. is:

Γ ` 0 : end ∴⊥[end]⊥

Γ, r : [end]⊥ ` r+ . 0 : end ∴⊥[end]⊥

(Sess)Γ ` 0 : end ∴⊥[end]⊥

Γ, r : [end]⊥ ` r− . 0 : end ∴⊥[end]⊥

(SessI)

Γ, r : [end]⊥ ` r+ . 0 | r− . 0 : end ∴⊥[end]⊥

(Par)

Γ ` (ν r) (r+ . 0 | r− . 0) : end ∴⊥[end]⊥

(SessRestr)

and the typing of the r.h.s. is:

Γ ` 0 : end ∴⊥[end]⊥ (Nil)

Case rp . (P | rq1 . 0) ≡ rp . P | rq

1 . 0 We assume p = q = +, the other cases being similar. Then thetyping of the l.h.s. is:

Γ, r1 : [end]⊥ ` P : U ∴ ı[T ]κΓ ` 0 : end ∴⊥[end]⊥

Γ, r1 : [end]⊥ ` r+1 . 0 : end ∴⊥[end]⊥

(Sess)

Γ, r1 : [end]⊥ ` P | r+1 . 0 : U ∴ ı[T ]κ

(Par)

Γ, r1 : [end]⊥, r : [T ]κ ` r+ . (P | r+1 . 0) : end ∴⊥[U ]ıtκ

(Sess)

and typing of the r.h.s. is:

Γ, r1 : [end]⊥ ` P : U ∴ ı[T ]κ

Γ, r1 : [end]⊥, r : [T ]κ ` r+ . P : end ∴⊥[U ]ıtκ

(Sess)Γ, r : [T ]κ ` 0 : end ∴⊥[end]⊥

Γ, r : [T ]κ, r1 : [end]⊥ ` r+1 . 0 : end ∴⊥[end]⊥

(Sess)

Γ, r1 : [end]⊥, r : [T ]κ ` r+ . P | r+1 . 0 : end ∴⊥[U ]ıtκ

(Par)

48 4.5 Properties

where we used weakening to add premises concerning r and r1.

Case ` J (P | Q) ≡ ` J P | ` J QFirstly, we consider the case in which the l.h.s is typed using rule (LevSign), where P | Q need to be of

type end ∴⊥[end]κ for some κ v `.

Γ ` P : end ∴⊥[end]κ1 Γ ` Q : end ∴⊥[end]κ2

Γ ` P | Q : end ∴⊥[end]κ1tκ2

(Par) κ1 t κ2 v `

Γ `∅ ` J P | Q : end ∴⊥[end]`(LevSign)

The typing of the r.h.s. is as follows:

Γ ` P : end ∴⊥[end]κ1 κ1 v `

Γ `∅ ` J P : end ∴⊥[end]`(LevSign)

Γ ` Q : end ∴⊥[end]κ2 κ2 v `

Γ `∅ ` J Q : end ∴⊥[end]`(LevSign)

Γ `∅ ` J P | ` J Q : end ∴⊥[end]`(TopPar)

Secondly, we consider the case in which the l.h.s is typed using rule (LevSignRT), where P and Q can beof arbitrary types, which agree with the security level `:

Γ ` P : U ∴ ı1 [T1]κ1 Γ ` Q : U ′ ∴ ı2 [T2]κ2

Γ ` P | Q : U ◦ U ′ ∴ ı1tı2 [T1 ./ T2]κ1tκ2

(Par) κ1 t κ2 t ı1 t ı2 v `

Γ ` ` J (P | Q) : U ◦ U ′ ∴ ı1tı2 [T1 ./ T2]`(LevSignRT)

The typing of the r.h.s. is as follows:

Γ ` P : U ∴ ı1 [T1]κ1 κ1 t ı1 v `

Γ ` ` J P : Γ ` P : U ∴ ı1 [T1]`(LevSignRT)

Γ ` Q : U ′ ∴ ı2 [T2]κ2 κ2 t ı2 v `

Γ ` ` J Q : U2 ∴ ı2 [T2]`(LevSignRT)

Γ ` ` J P | ` J Q : U ◦ U ′ ∴ ı1tı2 [T1 ./ T2]`(Par)

Lemma 4.5.3 (Substitution) Let Γ, x : S` ` P : U ∴ ı[T ]κ and Γ ` v : S`. Then Γ ` P [v/x] : U ∴ ı[T ]`tκ.

In Figure 4.11 we introduce the relation <: in order to express the consumption of the session types byreduction.

In the following lemma, we show that if a complex expression of C-context form is typable, then thesubexpression inside the hole is also typable. Furthermore, we establish that a subexpression inside a C-context hole can be be replaced with another subexpression of the same type with lower effects, whilepreserving the type of the entire expression, with a decrement of its effects.

Lemma 4.5.4 (Replacement C) If Γ ` C[[P ]] : U ∴ ı[T ]κ, then there exist some U1, ı1, T1, κ1 such thatΓ ` P : U1 ∴ ı1 [T1]κ1 , and if there exists Q such that Γ ` Q : U1 ∴ ı2 [T1]κ2 , ı2 v ı1, κ2 v κ1, thenΓ ` C[[Q]] : U ∴ ı′ [T ]κ′ for some ı′, κ′ such that ı′ v ı, κ′ v κ.

49 4.5 Properties

Proof: by induction on the structure of C and by compositionality of the type system.

We will now show that if a complex expression of D-context form is typable, then the two subexpressionsinside the holes are also typable. If the two subexpressions in the holes are replaced with expressions ofthe same types and with lower joint effects, the typability of the entire expression will be preserved, withdecrement of its effects.

Lemma 4.5.5 (Replacement D) If Γ ` D[[P,Q]] : U ∴ ı[T ]κ, then there exist some U1, ı1, T1, κ1 andU2, ı2, T2, κ2 such that Γ ` P : U1 ∴ ı1 [T1]κ1 and Γ ` Q : U2 ∴ ı2 [T2]κ2 and if there exist P ′, Q′ suchthat Γ ` P ′ : U1 ∴ ı3 [T1]κ3 , and Γ ` Q′ : U2 ∴ ı4 [T2]κ4 and ı3 t ı4 v ı1 t ı2, κ3 t κ4 v κ1 t κ2, thenΓ ` D[[P ′, Q′]] : U ∴ ı′ [T ]κ′ for some ı′, κ′ such that ı′ v ı, κ′ v κ.

Proof: by induction on the structure of D and by compositionality of the type system.

Finally, we show that if a complex expression of Dr-context form is typable, then the two subexpressionsinside the holes are also typable. Furthermore, we can establish that the types of the subexpressions inthe holes are complementary in the sense of the relations given in the Figures 4.5 and 4.6. If the twosubexpressions in the holes are replaced with expressions of “shorter”, in the sense of the relation given in theFigure 4.11, but still complementary types and with lower joint effects, the typability of the entire expressionwill be preserved, with decrement of its effects.

Lemma 4.5.6 (Replacement Dr) If Γ ` Dr[[P,Q]] : U ∴ ı[T ]κ, then there exist some U1, ı1, T1, κ1 andU2, ı2, T2, κ2 such that Γ ` P : U1 ∴ ı1 [T1]κ1 and Γ ` Q : U2 ∴ ı2 [T2]κ2 and, depending on the polarity, eitherT1 ≤ T2 or T2 ≤ T1 and if there exist P ′, Q′ such that Γ ` P ′ : U3 ∴ ı3 [T3]κ3 , and Γ ` Q′ : U4 ∴ ı4 [T4]κ4 andU3 <: U1, T3 <: T1, U4 <: U2, T4 <: T2, ı3 t ı4 v ı1 t ı2, κ3 t κ4 v κ1 t κ2 and T3 ≤ T4 (if T1 ≤ T2) orT4 ≤ T3 (if T2 ≤ T1), then Γ ` Dr[[P ′, Q′]] : U ′ ∴ ı′ [T ′]κ′ for some U ′ ∴ ı′ [T ′]κ′ such that U ′ <: U , T ′ <: T ,ı′ v ı, κ′ v κ.

Proof: By induction on the structure of Dr and by compositionality of the type system.

Theorem 4.5.7 (Subject Reduction) If Γ `S P : U ∴ ı[T ]κ, and P → P ′, then there exist U ′, ı′, T ′, κ′

such that U ′ <: U , T ′ <: T , ı′ v ı, κ′ v κ and Γ `S P ′ : U ′ ∴ ı′ [T ′]κ′ .

Proof: By case analysis of the reduction rules given in Figure 4.2. Thanks to Lemmas 4.5.4, 4.5.5 and4.5.6 it is enough to show that the processes in the contexts before and after the reduction are typeable asprescribed by these lemmas.

Case (End).Firstly, we consider the case in which the l.h.s. has been typed using rule (LevSign):

Γ ` 0 : end ∴⊥[end]⊥

Γ `∅ ` J 0 : end ∴⊥[end]`(LevSign)

for the typing of the r.h.s. we use the rule (NilI):

Γ `∅ 0 : end ∴⊥[end]⊥ (NilI)

50 4.5 Properties

Similarly, if the l.h.s. has been typed using rule (LevSignRT), we have:

Γ ` 0 : end ∴⊥[end]⊥

Γ ` ` J 0 : end ∴⊥[end]`(LevSignRT)

and the typing of the r.h.s. is:

Γ ` 0 : end ∴⊥[end]⊥ (Nil)

Case (Inv). Firstly, we consider the case in which the service invocation has been typed using rule(LevSign). In this case the processes building the redex in the l.h.s. are typed as follows:

Γ ` P : end ∴⊥[T ]κ Γ ` s : [T ′] T ′ ≤ T

Γ ` s.P : end ∴⊥[end]κt

(Inv) κ t v `

Γ `∅ ` J s.P : end ∴⊥[end]`(LevSign)

Γ ` Q : end ∴⊥[T ′]κ1 Γ ` s : [T ′] κ1 v

Γ `{s} s.Q : end ∴⊥[end]κ1

(ServDef)

Then, we can type the changed processes in the r.h.s. as follows:

Γ ` P : end ∴⊥[T ]κ κ v `

Γ ` ` J P : end ∴⊥[T ]` T ′ ≤ T(LevSignRT)

Γ, r : [T ′]` ` r− . ` J P : end ∴⊥[end]`(SessI)

Γ, r : [T ′]` `∅ r− . ` J P : end ∴⊥[end]`(ToTop)

andΓ ` Q : end ∴⊥[T ′]κ1 κ1 v `

Γ ` ` J Q : end ∴⊥[T ′]`(LevSignRT)

Γ, r : [T ′]` ` r+ . ` J Q : end ∴⊥[end]`(Sess)

Γ, r : [T ′]` `∅ r+ . ` J Q : end ∴⊥[end]`(ToTop)

so:Γ, r : [T ′]` `∅ r+ . ` J Q : end ∴⊥[end]` Γ, r : [T ′]` `{s} s.Q : end ∴⊥[end]κ1

Γ, r : [T ′]` `{s} r+ . ` J Q | s.Q : end ∴⊥[end]`(TopPar)

Notice that the typing of the restriction for r will discharge the premise r : [T ′]`.

We will now consider the case in which the service invocation has been typed using rule (LevSignRT).

Γ ` P : U ∴ ı[T ]κ Γ ` s : [T ′] T ′ ≤ T

Γ ` s.P : end ∴⊥[U ]κttı

(Inv) κ t t ı v `

Γ ` ` J s.P : end ∴⊥[U ]`(LevSignRT)

51 4.5 Properties

The typing of service definition is clearly as it was in the previous case, so we can derive Γ, r : [T ′]` `{s}r+ . ` J Q | s.Q : end ∴⊥[end]`. Moreover we can derive:

Γ ` P : U ∴ ı[T ]κ κ t ı v `

Γ ` ` J P : U ∴ ı[T ]` T ′ ≤ T(LevSignRT)

Γ, r : [T ′]` ` r− . ` J P : end ∴⊥[U ]`(SessI)

Case (Com). By Lemma 4.5.6 the processes which build the redex in the l.h.s. must be typed as follows:

Γ, x : S` ` P : U ∴ ı[T ]κ

Γ ` (x).P : U ∴ ı[?(S`).T ]κt`

(Inp)Γ ` Q : U ′ ∴ ı′ [T ′]κ′ Γ ` v : S`

Γ ` 〈v〉.Q : U ′ ∴ ı′ [!(S`).T ′]κ′t`

(Out)

with T ≤ T ′ or T ′ ≤ T according to the polarity. By Lemma 4.5.3 we can derive Γ ` P [v/x] : U ∴ ı[T ]κt`

and this concludes the proof.Case (Lcom). Similar to the previous case.Case (Pipe). The typing of the l.h.s. is:

Γ ` P : U ∴ ı[T ]κ Γ ` v : S`

Γ ` 〈v〉.P : U ∴ ı[!(S`).T ]κt`

(Out)

Γ, x : S` ` Q : U ′ ∴ ı′ [T ′]κ′pipe(U ∴ ı[!(S`).T ]κt`, U

′ ∴ ı′ [T ′]κ′ , S`) = U ′′ ∴ ı′′ [T ′′]κ′′

Γ ` 〈v〉.P > x > Q : U ′′ ∴ ı′′ [T ′′]κ′′(Pipe)

We distinguish two cases:

1. T = end. In this case the resulting type of 〈v〉.P > x > Q is U ◦ U ′ ∴ ıtı′ [T ′]κt`tκ′ , and the type ofP > x > Q is U ∴ ı[end]κ (the first case of the function pipe). Then by Lemma 4.5.3 we can type ther.h.s. as follows:

Γ ` P > x > Q : U ∴ ı[end]κ Γ ` Q[v/x] : U ′ ∴ ı′ [T ′]κ′

Γ ` P > x > Q | Q[v/x] : U ◦ U ′ ∴ ıtı′ [T ′]κtκ′

(Par)

2. T =!(S`)h.end, h ≥ 1. In this case `tκ, the resulting type of 〈v〉.P > x > Q is U ◦U ′h+1 ∴ ıtı′ [end]κtκ′ ,and the type of P > x > Q is U ◦ Uh ∴ ıtı′ [end]κtκ′ (the second case of the function pipe). Then byLemma 4.5.3 we can type the r.h.s. as follows:

Γ ` P > x > Q : U ◦ U ′h ∴ ıtı′ [end]κtκ′ Γ ` Q[v/x] : U ′ ∴ ı′ [T ′]κ′

Γ ` P > x > Q | Q[v/x] : (U ◦ U ′h) ◦ U ′ ∴ ıtı′ [end]κtκ′

(Par)

We conclude observing that (U ◦ U ′h) ◦ U ′ = U ◦ U ′h+1.Case (LevSel). We only consider the case in which the l.h.s. has been typed using rule (LevSignRT), thecase in which rule (LevSign) has been used being similar and simpler. From the typing of the l.h.s.:

Γ ` Pi : U ∴ ı[T ]κiκi v `i (1 ≤ i ≤ n) ∃j(1 ≤ j ≤ n).`1 u . . . u `n = `j

Γ `Un

i=1 `i n Pi : U ∴ ı[]{`1, . . . , `n} ∝ T ]`j

(LevSel) ı t `j v `

Γ ` ` JUn

i=1 `i n Pi : U ∴ ı[]{`1, . . . , `n} ∝ T ]`

(LevSignRT)

52 4.5 Properties

(Inv) D[[` J s`′ .P , s`′ .Q]] → (ν r`) D[[r−` . ` J P , r+` . ` J Q | s`′ .Q]] `′ v `

r` 6∈ fn(D[[s`′ .P , s`′ .Q]])(Com) Dr` [[` J (xı).P , ` J 〈vı〉.Q]] → Dr` [[` J P [vı/xı ], ` J Q]] ı v `(Lcom) Dr` [[` J

Pni=1(li).Pi, ` J 〈lk〉.Q]] → Dr` [[` J Pk, ` J Q]]

(Ret) Dr1`[[` J (xı).P , Cr

p`[[` J return vı.Q]]]] → Dr1`

[[` J P [vı/xı ], Crp`[[` J Q]]]] ı v ` u `′

(Pipe) C[[` J 〈vı〉.P > xı > Q]] → C[[` J P > xı > Q | ` J Q[vı/xı ]]] ı v `(PipeRet) C[[` J Cr

p`[[` J return vı.P ]] > xı > Q]]

→ C[[` J Crp`[[` J P ]] > xı > Q | ` J Q[vı/xı ]]] ı v ` u `′

(IfT) C[[` J if uı = v then P else Q]] → C[[` J P ]] (uı = v) ↓ true(IfF) C[[` J if uı = v then P else Q]] → C[[` J Q]] (uı = v) ↓ false(LevSel) C[[` J

Uni=1 `i n Pi]] → C[[` J Pi]] if `i v `

(End) C[[` J 0]] → C[[0]](Scop) P → P ′ ⇒ (ν m) P → (ν m) P ′

(Str) P ≡ P ′ ∧ P ′ → Q′ ∧ Q′ ≡ Q ⇒ P → Q

Figure 4.12: Labeled Operational Semantic Rules

(InvErr) D[[` J s`′ .P , s`′ .Q]]error−−−→ `′ 6v `

(ComErr) Dr` [[` J (xı).P , ` J 〈vı〉.Q]]error−−−→ ı 6v `

(RetErr) Dr`′ [[`′ J (xı).P , Cr

p`[[` J return vı.Q]]]]

error−−−→ ı 6v ` u `′

(PipeErr) C[[` J 〈vı〉.P > xı > Q]]error−−−→ ı 6v `

(PipeRetErr) C[[`′ J Crp`[[` J return vı.P ]] > xı > Q]]

error−−−→ ı 6v ` u `′

(IfErr) C[[` J if uı = v then P else Q]]error−−−→ ı t 6v `

(LevSelErr) C[[` JUn

i=1 `i n Pi]]error−−−→ ∀i(1 ≤ i ≤ n).`i 6v `

Figure 4.13: Security Errors

and the condition ı t `i v ` we get ı t κi v ` and then we can type the r.h.s. as follows:

Γ ` Pi : U ∴ ı[T ]κiı t κi v `

Γ ` ` J Pi : U ∴ ı[T ]`(LevSignRT)

4.5.2 Security PropertiesFrom an access control point of view, clients are regarded as “subjects”, and services and basic values as“objects”. Therefore, a client is required to possess an appropriate clearance to activate a service or tocommunicate a value. On the other hand, services are regarded as trusted entities, and they are allowed toact on behalf of the client who invoked them (this is reflected in the operational semantics, where the bodyprocess of the service definition “inherits” the clearance from the client after the activation).

A process can be active (or running) only in the scope of a security framing. In fact, the reduction rulesfrom Figure 4.2 can be redefined with explicit notion of reduction under the security frame, and decorating

53 4.5 Properties

the values with their security levels. This reduction relation is given in Figure 4.12.This allows a straightforward definition of security error, given in Figure 4.13. A process runs in a security

error in the following cases:

1. when it tries to activate a service with a level not below its clearance;

2. when it tries to communicate a value with a level not below its clearance in the current session;

3. when it tries to return a value with a level not below its clearance or the parent clearance toward theparent session;

4. when it tries to communicate a value with a level not below its clearance to a pipe or not below theparent clearance toward a pipe in the parent session;

5. when it uses values with a level not below its clearance in the control expression of conditional branch-ing;

6. when it enters into the level branching where all the levels are not below its clearance.

This allows us to express the main result of this chapter as a type safety property in the following theorem.

Theorem 4.5.8 Typable processes do not run into security errors.

Proof: by contradiction and case analysis of the reduction rules given in Figure 4.13. In each case weshow the subdeductions which assure the required order between security levels. We only consider processestyped using rule (LevSignRT), the case in which rule (LevSign) has been used being similar and simpler.

Case (InvErr):

Γ ` P : U ∴ ı[T ]κ Γ ` v`′ : [T ′]`′ T ′ ≤ T

Γ ` v.P : end ∴⊥[U ]κt`′tı

(Inv) κ t `′ t ı v `

Γ ` ` J v`′ .P : end ∴⊥[U ]`

(LevSignRT)

As it can be seen, the typing rule ensures that `′ v κ t `′ t ı v `.Case (ComErr):

Γ, xı : Sı ` P : U ∴ [T ]κ

Γ ` (xı).P : U ∴ [?(Sı).T ]κtı

(Inp) κ t t ı v `

Γ ` ` J (xı).P : U ∴ [?(Sı).T ]κtı

(LevSignRT)

Γ, r : [T ′]` ` rp . ` J (xı).P : end ∴⊥[U ]`

(Sess)

where T ′ ={

T, if p = +T ′, T ′ ≤ T, if p = − . We get ı v κ t t ı v `.

Case (RetErr): As in previous case the typing of rp1`′ . `′ J (xı).P assures ı v `′. Moreover we have:

Γ ` Q : U ∴ [T ]κ Γ ` vı : Sı

Γ ` return vi.Q :!(Sı).U ∴ ıt[T ]κ

(Ret) ı t t κ v `

Γ ` ` J return vi.Q :!(Sı).U ∴ ıt[T ]κ

(LevSignRT)

Γ, r : [T ′]` ` rp . ` J return vi.Q : end ∴⊥[!(Sı).U ]`

(Sess)

54 4.6 Progress

where T ′ ={

T, if p = +T ′, T ′ ≤ T, if p = − , which implies ı v ı t t κ v `.

Case (PipeErr):

Γ ` P : U ∴[!(Sı)n−1.end]κ Γ ` v : Sı

Γ ` 〈vı〉.P : U ∴[!(Sı)n.end]κtı

(Out) Γ, vı : Sı ` Q : U′ ∴′ [T ′]κ′

Γ ` 〈vı〉.P > x > Q : U′′ ∴t′ [T ′′]κtıtκ′

(Pipe) t ′ t κ t ı t κ′ v `

Γ ` ` J 〈vı〉.P > xı > Q : U′′ ∴t′ [T ′′]`

(LevSignRT)

where pipe(U ∴ [!(Sı)n−1.end]κtı, U′ ∴ ′ [T ′]κ′) = U ′′ ∴ t′ [T ′′]κtıtκ′ , which implies ı v t ′tκt ıtκ′ v `.

Case (PipeRetErr): The reasoning is similar to that of cases (RetErr) and (PipeErr).

Case (IfErr):

Γ ` vi : S`i Γ ` P : U ∴[T ]κ Γ ` Q : U ∴[T ]κ′ `i v κ u κ′ i = 1, 2

Γ ` if v1 = v2 then P else Q : U ∴[T ]κtκ′

(If) t κ t κ′ v `

Γ ` ` J if v1 = v2 then P else Q : U ∴[T ]`

(LevSignRT)

Note that `i v κ u κ′ v t κ t κ′ v `.Case (LevSelErr):

Γ ` Pi : U ∴[T ]κiκi v `i (1 ≤ i ≤ n) ∃j(1 ≤ j ≤ n).`1 u . . . u `n = `j

Γ `Un

i=1 `i n Pi : U ∴[]{`1, . . . , `n} ∝ T ]`j

(LevSel) t `j v `

Γ ` ` JUn

i=1 `i n Pi : U ∴[]{`1, . . . , `n} ∝ T ]`

(LevSignRT)

4.6 ProgressThis section discusses the progress property. The proof of this property is similar to the one given in [12],taking into account that the security constructs and annotations do not lead to stuck states by Theorem4.5.8. We start with some definitions.

We first define the initial and final processes (or normal forms) of the reductions we will consider. Westart reductions from top level closed processes which do not offer communications and do not have publicservices.

Definition 4.6.1 (Initial Processes) A process P is initial if ∅ `∅ P : end ∴ ⊥[end]κ without using theruntime typing rules.

Our final configurations are just parallels of service definitions.

Definition 4.6.2 (Normal Forms) A process P is in normal form if P ≡ (ν s1) . . . (ν sn)∏n

i=1(si.Qi).

It is also useful to name processes where session calls are not ready to reduce.

Definition 4.6.3 (Call-free Processes) A process P is call-free if P does not contain redexes which aresession calls.

55 4.6 Progress

We classify session names according to the processes they enclose and their relative positions. A mean-ingful session name enclose processes which can be reduced.

Definition 4.6.4 (Meaningful Session Names) A session name r is meaningful in a process P if Pcontains rp . Q with Q 6≡ 0.

An innermost session name is a meaningful session name which does not contain meaningful sessionnames.

Definition 4.6.5 (Innermost Session Names) A meaningful session name r is innermost in a processP if P ≡ Dr[[Q,R]] and Q,R do not contain meaningful session names.

Our definition of progress property is standard.

Definition 4.6.6 (Progress Property) A process P has the progress property if P →∗ Q implies thateither Q is reducible or Q is in normal form.

The following lemma says that session calls can always be satisfied in a well-typed process.

Lemma 4.6.7 If ∅ `∅ (ν s) C[[` J s.P ]] : end ∴⊥[end]κ, then C[[` J s.P ]] ≡−−−→(ν m) s.Q | R for some −→m,Q,R

with s 6∈ −→m.

Proof: Rule (Inv) is necessary to type s.P and it requires an assumption for the service name s, which canonly be discharged by rule (ServRestr). In turn rule (ServRestr) implies that the service name s decoratesthe turn-style, and so rule (ServDef) for the service name s needs to have been applied.

It is crucial to observe that starting from an initial process we always get processes where all sessionnames occur exactly twice with opposite polarities and at least one session name, if any, is innermost.

Lemma 4.6.8 If P is an initial process and P →∗ −−−→(ν m)Q, where Q does not contain restrictions, then

1. if rp occurs in Q, then it occurs once and also rp occurs once in Q, and

2. either no session name occurs in Q or there is at least one session name which is innermost in Q.

Proof: The proof is by cases on the reduction rules applied.Rule (Inv) is the only reduction rule which creates a meaningful session name, and it creates two

occurrences of an innermost session name, with opposite polarities, since the processes in the scope of thenew name cannot contain session names.

The last but one structural rule cancels both polarities of a session name, and so rule (Str) preservesthe property that each session name occurs twice with both polarities. The rules for structural equivalenceonly deal with non meaningful session names, so rule (Str) does not modify the innermost session namesin a process.

The last lemma says that under suitable conditions a process offering a communication inside the inner-most session has always a partner accepting the communication.

Lemma 4.6.9 Let P be an initial process and P →∗ −−−→(ν m) Dr[[Q,R]], where r is innermost in Dr[[Q,R]]and Dr[[Q,R]] does not contain restrictions, cannot be reduced by rules (Pipe), (PipeRet), (IfT), (IfF),(LevSel) and it is call-free. Then

56 4.6 Progress

1. Q ≡ (x).Q′ implies R ≡ 〈v〉.R′;

2. Q ≡ 〈v〉.Q′ implies R ≡ (x).R′;

3. Q ≡ return v.Q′ implies Dr[[Q,R]] ≡ Dr1 [[(x).P ′, Crp [[Q]]]];

4. Q ≡∑n

i=1(li).Qi implies R ≡ 〈lk〉.R′;

5. Q ≡ 〈lk〉.Q′ implies R ≡∑n

i=1(li).Ri.

Proof: The typability of Dr[[Q,R]] implies by Lemma 4.5.6 that Q, R are typed with session types suchthat one is a subtype of the dual of the other, and since they are irreducible by hypothesis R must have theshapes shown in cases 1, 2, 4 and 5. In case 3 since Dr[[Q,R]] is typed by end ∴⊥[end]κ the process Q mustbe enclosed in the body of another session, that we can call r1, getting Dr[[Q,R]] ≡ Dr1 [[P1, Crp [[Q]]]]. ByLemma 4.5.6 the processes P1, Crp [[Q]] are typed with session types such that one is a subtype of the dual ofthe other, and this gives P1 ≡ (x).P ′.

We are now able to prove the progress theorem.

Theorem 4.6.10 (Progress) If P is initial, then P has the progress property.

Proof: If P is not in normal form, then P must contain some process different from service definition. IfP ≡ C[[` J s.Q]], then P is reducible by Lemma 4.6.7. If P ≡ C[[R > x > Q]], then either R can be reducedor typability implies R ≡ 〈v〉.R′ or R ≡ Crp [[return v.R′]], so rule (Pipe) or (PipeRet) is applicable. IfP ≡ C[[if u = v then R else Q]], then either rule (IfT) or rule (IfF) is applicable. If P ≡ C[[` J

⊎ni=1 `i n Pi]],

then rule (LevSel) is applicable by Theorem 4.5.8.Otherwise P ≡ C[[Q]] where Q is an input, output, value return, label choice or label-guarded sum. Since

P is typed by end ∴⊥[end]κ and P is call-free, then the process Q must be enclosed in the body of a session.In this case we can choose an innermost session and apply Lemma 4.6.9 to conclude that P is reducible.

Chapter 5

Conclusion

In the first part of this thesis, we have shown a way of integrating access control and information flowcontrol in the setting of a high-level programming language, involving a declassification construct. Our“state-oriented” approach, that we share with [5], differs from the “value-oriented” approach (that one hasto adopt when dealing with purely functional languages) that is followed in [19, 33, 38] to deal with stackinspection, and [32, 37] as regards information flow control (see also [34] for further references).

We think that assuming that confidentiality levels are assigned to “information containers” is more inline with the usual way of dealing with confidentiality than assigning security levels to values, like booleantt and ff , integers or functions. In this way, the safety property guaranteed by access control is quite simpleand natural, and this also provides a natural restriction on the use of declassification, and, more generally,information flow.

The second part of this thesis addressed security issues in a calculus for services and pipelines (CaSPiS)by employing static analysis access control methodology, and by offering increased modularity of the serviceswith options of different behaviours of a service depending on the privileges of the client who activated it.The type system ensures at compile time that a service can be activated only by clients with appropriateclearance, while preserving the safety and progress properties of previous versions of CaSPiS.

The approach in this work was to consider mandatory access control, with no mechanisms of access rightelevation or demotion. A next step might be to consider discretionary access control with a possibility ofpermission passing among subjects.

57

Bibliography

[1] A. Almeida Matos. Typing secure information flow: Declassification and mobility. PhD thesis, EcoleNationale Superieure des Mines de Paris, 2006.

[2] L. Acciai and M. Boreale. A type system for client progress in a service-oriented calculus. In Concur-rency, Graphs and Models, volume 5065 of LNCS, pages 642–658. Springer, 2008.

[3] A. Almeida Matos and G. Boudol. On declassification and the non-disclosure policy. In Proceedings ofthe 18th IEEE CSFW’05, pages 226–240, Washington, DC, USA, 2005. IEEE Computer Society.

[4] A. Banerjee and D. A. Naumann. A simple semantics and static analysis for Java Security. TechnicalReport 2001-1, Stevens Institute of Technology, 2001.

[5] A. Banerjee and D. A. Naumann. Stack-based access control and secure information flow. J. Funct.Program., 15(2):131–177, 2005.

[6] D. E. Bell and L. J. LaPadula. Secure computer systems: Mathematical foundations. Technical ReportMTR-2547, Vol. 1, MITRE Corp., Bedford, MA, 1973.

[7] E. Bonelli, A. Compagnoni, and E. Gunter. Correspondence assertions for process synchronization inconcurrent communications. J. Funct. Program., 15(2):219–247, 2005.

[8] M. Boreale, R. Bruni, R. D. Nicola, I. Lanese, M. Loreti, U. Montanari, D. Sangiorgi, and G. Zavattaro.SCC: a service centered calculus. In WS-FM’06, volume 4186 of LNCS, pages 38–57. Springer, 2006.

[9] M. Boreale, R. Bruni, R. D. Nicola, and M. Loreti. Sessions and pipelines for structured serviceprogramming. In FMOODS’08, volume 5051 of LNCS, pages 19–38. Springer, 2008.

[10] G. Boudol and M. Kolundzija. Access control and declassification. In Computer Network Security,volume 1 of CCIS, pages 85–98. Springer, 2007.

[11] N. Broberg and D. S. Flow locks: Towards a core calculus for dynamic flow policies. In In Proc.European Symp. on Programming, volume 3924 of LNCS, pages 180–196. Springer-Verlag, 2006.

[12] R. Bruni and L. G. Mezzina. Types and deadlock freedom in a calculus of services, sessions and pipelines.In AMAST’08, volume 5140 of LNCS, pages 100–115. Springer, 2008.

[13] S. Chong and A. C. Myers. Security policies for downgrading. In CCS ’04: Proceedings of the 11thACM conference on Computer and communications security, pages 198–209, New York, NY, USA, 2004.ACM.

[14] E. S. Cohen. Information transmission in computational systems. ACM SIGOPS Operating SystemsReview, 11(5):133–139, 1977.

58

59 BIBLIOGRAPHY

[15] D. E. Denning. A lattice model of secure information flow. Comm. of the ACM, 19(5):236–243, 1976.

[16] D. E. Denning and P. J. Denning. Certification of programs for secure information flow. Comm. of theACM, 20(7):504–513, 1977.

[17] M. Dezani-Ciancaglini, U. de’ Liguoro, and N. Yoshida. On progress for structured communications. InTGC’07, volume 4912 of LNCS, pages 257–275. Springer, 2008.

[18] M. Dezani-Ciancaglini, D. Mostrous, N. Yoshida, and S. Drossopoulou. Session types for object-orientedlanguages. In ECOOP’06, volume 4067 of LNCS, pages 328–352. Springer, 2006.

[19] C. Fournet and A. D. Gordon. Stack inspection: Theory and variants. In POPL’02, pages 307–318,2002.

[20] S. Gay and M. Hole. Subtyping for session types in the pi calculus. Acta Inf., 42(2):191–225, 2005.

[21] K. Honda, V. T. Vasconcelos, and M. Kubo. Language primitives and type disciplines for structuredcommunication-based programming. In ESOP’98, volume 1381 of LNCS, pages 22–138. Springer, 1998.

[22] D. Kitchin, W. R. Cook, and J. Misra. A language for task orchestration and its semantic properties.In CONCUR’06, volume 4137 of LNCS, pages 477–491. Springer, 2006.

[23] M. Kolundzija. Security types for sessions and pipelines. In WS-FM 2008, LNCS. Springer, 2008. toappear.

[24] B. W. Lampson. A note on the confinement problem. Commun. ACM, 16(10):613–615, 1973.

[25] I. Lanese, V. T. Vasconcelos, F. Martins, and A. Ravara. Disciplining orchestration and conversationin service-oriented computing. In SEFM’07, pages 305–314. IEEE Computer Society Press, 2007.

[26] A. Lapadula, R. Pugliese, and F. Tiezzi. A calculus for orchestration of web services. In ESOP’07,volume 4421 of LNCS, pages 33–47. Springer, 2007.

[27] P. Li and S. Zdancewic. Downgrading policies and relaxed noninterference. SIGPLAN Not., 40(1):158–170, 2005.

[28] J. M. Lucassen and D. K. Gifford. Polymorphic effect systems. In POPL ’88: Proceedings of the 15thACM SIGPLAN-SIGACT symposium on Principles of programming languages, pages 47–57, New York,NY, USA, 1988. ACM.

[29] R. Milner, J. Parrow, and D. Walker. A calculus of mobile processes, Parts I and II. Info. & Comp.,100(1):1–40 and 41–77, 1992.

[30] A. C. Myers and B. Liskov. A decentralized model for information flow control. In Proc. ACM Symp.on Operating System Principles, pages 129–142, 1997.

[31] A. C. Myers, A. Sabelfeld, and S. Zdancewic. Enforcing robust declassification and qualified robustness.Journal of Computer Security, 2006:2006, 2006.

[32] F. Pottier and S. Conchon. Information flow inference for free. In In Proc. 5th ACM SIGPLANInternational Conference on Functional Programming (ICFP, pages 46–57, 2000.

[33] F. Pottier, C. Skalka, and S. Smith. A systematic approach to static access control. ACM TOPLAS,27(2), 2005.

60 BIBLIOGRAPHY

[34] A. Sabelfeld and A. C. Myers. Language-based information-flow security. IEEE J. Selected Areas inCommunications, 21(1):5–19, 2003.

[35] A. Sabelfeld and D. Sands. Probabilistic noninterference for multi-threaded programs. In In Proc. IEEECSFW, pages 200–214. IEEE Computer Society Press, 2000.

[36] A. Sabelfeld and D. Sands. Dimensions and principles of declassification. In In Proc. IEEE CSFW’05,pages 255–269, Washington, DC, USA, 2005. IEEE Computer Society.

[37] V. Simonet. The flow caml system: documentation and user’s manual. Technical report, INRIA, 2003.INRIA Tech. Rep. 0282.

[38] C. Skalka and S. Smith. Static enforcement of security with types. In In ICFP’00, pages 34–45. ACMPress, 2000.

[39] D. Volpano, G. Smith, and C. Irvine. A sound type system for secure flow analysis. J. ComputerSecurity, 4(3):167–187, 1996.

[40] A. K. Wright and M. Felleisen. A syntactic approach to type soundness. Information and Computation,115:38–94, 1994.

[41] S. Zdancewic. Programming languages for information security. PhD thesis, Cornell University, 2002.