Abstract. Distributed applications can be structured using sessions that specify flows of messages between roles. We design a small specific language to declare sessions. We then build a compiler, called s2ml, that transforms these declarations down to ML modules securely implementing the sessions. Every run of a well-typed program executing a session through its generated module is guaranteed to follow the session specification, despite any low-level attempt by coalitions of remote peers to deviate from their roles. We detail the inner workings of our compiler, along with our design choices, and illustrate the usage of s2ml with two examples: a simple remote procedure call session, and a complex session for a conference management system.
Sessions for distributed programmingProgramming networked, independent systems is complex: when systems communicate through an untrusted network, and do not trust each other, enforcing security properties is hard. As a first step to simplify this task, programming languages and system libraries offer abstractions for common communication patterns (such as private channels or RPCs). Beyond simple abstractions for communications, distributed applications can often be structured as parties that exchange messages according to some fixed, prearranged patterns, called sessions (also named contracts, or workflows, or protocols). Sessions simplify distributed programming by specifying the behaviour of each network entity, or role: the parties can then resolve most of the programming complexity upfront.Language-based support for sessions is the subject of active research [2,3,4,7,10,14,15]. Several of these works focus on developing type systems which statically ensure compliance to session specifications. There, type safety implies that user code that instantiates a session role always behaves as prescribed in the session. Thus, assuming that every distributed program participating in a session is well-typed, any run of the session follows its specification. There, being well-typed implies that every session participant is benign, and therefore complies with the session specification. Moreover, the network is also assumed to behave as expected, (e.g., delivering messages correctly).However, in an adversarial setting, remote parties may not be trusted to play their role. Moreover, they may collude to attack compliant participants, and may also control the network, being able to eavesdrop, intercept, and modify en route messages. Hence, defensive implementations also have to monitor one another, in order to prevent any confusion between parallel sessions, to ensure authentication, correlation, and causal dependencies between messages, and to detect any deviation from the assigned roles of a session. Left to the programmer, this task involves delicate low-level coding below session abstractions, which defeats their purpose.In order to keep sessions being useful and safe abstractions, we consider their secure implementation in terms of cryptographic communication protocols, by developing ...