Modelling security aspects of a Message Handling ...

81

Modelling Security Aspects of a Message Handling System in LOTOS SBlack

C: Calvelli V Vatadharajan

Hewlett-Packard Laboratories, U.K.

Abstract This paper describes the formal specification of the security aspects of a Message Handling System (MHS). We choee the Intematiccpl Standard for-

mal description technique LOTOS to describe this system. The actual system being modelled, called LOCATOR,is a secure mobiie MHS, and was d e veloped within the U.K.’s Alvey programme. Here we outline the MHS,the security services, and dercribe the modelling of these services in LOTOS.

1

Introduction

The specificationof a system is the first step towards its implementation. Several formal specification languages have been developed in reeent years. These languages essentially differ in the emphaais they place on concepts such as abstractneua (how implementation independent they can be), concurrency (how suitable they are for specifying psrallel systems) and analysability (how readily specifications can be verified). The appropriateness of each of these languages depends on the application to which they are applied. The field of communicationsystems naturally presents technical chsllengeefor formal specification and analysis, due to the inherent concurrency and non-determiniem. It is eesential that specification languages for networked systems can easily model such concurrency and non-determinism. Many of the formal specification languagee developed recently are able to model these concepts. From the point of &ty, the use of formal specification techniques very significant as it provides a basis for determining whether a system is secure or not. Much of &e specification work done dongside the theoretical developnwnk hae been of fairly d l problems. The work preaeated here is of a aon-trivial system, and is representative of the growing importance and resour= spent on formal specification. It must be noted that many of the problems, and solutions, are generic to communications protocols, and are not specific to the MHS.

2

The LOCATOR System

The LOCATOR project is part of the Mobile Information Systems Project, which is a major demonstrator within the U.K. Government sponsored Alvey Programme. The partners within LOCATOR are Hewlett-Padcard Ltd., RacalMilgo Ltd., Racal- W c h Ltd., Racal Ims& Systems Ltd., and University College London. A primary goal of the LOCATOR project is the demonstration of a secure interpersonal messaging system with mobile access.

The LOCATOR system is based upon a Message Handling System (X.400[3]), with added security functionality. The distributed nature of the messaging system makea it eusceptible to a number of security threcrts. Typical threats include eavesdroppingand d i s c l m of information to unauthorised users, one user masquerading ’BI another user, modification of messages while being transferred, and a user denying sending or receiving of messages.

2.1

Message Handling System

A Message Handling System is a set of computer processes which cooperate to provide the users with a reliable means of store and forward capability for their message transfer. To clarify the different needs during the Message Transfer, the MHS system has been divided into the following parts: User Agent, Message Transfer System, Message Transfer Agent and Message Store. (a) User Agent (UA) : This is a p r o m which interfaces with the “User” on one side, and with the “MessageTransfer System” on the other side. The UA allows the user to create and submit messages to the Message Transfer System, and it collects messages from the Message Transfer System and presents them to the user.

(b) Message Transfer System (MTS) : This is used to physically move the messages between computers and it consists of a number of cooperating Message Transfer Agents. (c) Message Transfer Agent (MTA) : An MTA is a computer that routes and relays messages. An MTA cooperates with other MTAs to relay and deliver messagesto the appropriate

UA. (d) Message Store (MS) : The MS acts M an intermediary between the UAs and the MTAs and it provides reliable storage of delivered messages and thereby gives more control over the receipt of messages. Figure 1 shows the basic components of the MHS model. A message created by a user is submitted to the MTS via a UA. The MTA f o r w ~ d athis message towards the final delivery point within the MTS, which is the MTA attached to the UA whose address is given in the message.

A UA may either reside in the same computer as the MTA or it can be connected to an MTA by some network. In the first case,the UA accesses the MTS elements of service by interacting directly with the MTA. In the second case, the UA communicates with the MTA via the standard protocols. Several UAs may be attached to a single MTA. An MS can be co-located with the UA ,co-located with the MTA or stand alone. The protocols between these components are also shown in Figure 1. Protocol P1 is concerned with the transfer of messages between the MTAs and is called the Message

82

message requiring confidentiality. The symmetric key used to encrypt the message content is encrypted using the RSA asymmetric algorithm [ll], and this is sent to the receiver. The public key of the recipient is used in this process. The recipient of an encrypted message uses his secret RSA key to obtain the symmetric key, and then uses this to recover the message content. The authentication services are provided using digital signature and content-integrity check. The digital signature allows one to uniquely identify the origin of the message, and the content-integrity check is used to detect any modification of the message. For these mechanisms to work, it is necessary to provide a guarantee to the sending user that the public key of the receiver is the “correct” one. This involves communication with a trusted Certification Authority which maintains such information. The X.509 Authentication Framework [4] has been used in the authentication of public keys of the users. It is not in the scope of this paper to explain further the security functions, and how the system provides them. For a more detailed treatment refer to [lo] and [l].

3

Figure 1: Functional Model of the Message Handling System Transfer Protocol. Protocol P3 is the MTS access protocol between the MTS and the MS. Protocol P7 is the MS access protocol between the MTA and the UA. The P2 protocol is between the UAs in the system.

2.2

Security Aspects

The security architecture has been developed by the LOCATOR project team and a complete description of the security architecture is given in [lo]. The security architecture conforms to the CCITT Draft Recommendations. Here we outline the relevant features of the architecture which are required for our specification. The architecture supports a number of security services, most of which are ”end-to-end” in nature. These services are probably the most significant ones to the end users of a mail system. These end-to-end security services include: content confidentiality, message-origin authentication, content integrity, non-repudiation of origin, replay detection, and non-repudiation of delivery. There are also other services which are not end-to-end, such as access control on the User Agent/Message Store link. Jn our formal specification, we will only be concerned with the end-to-end security services. In order to provide the security services, the security mechanisms employ both symmetric and asymmetric cryptosystems. The UA uses the DES [5]symmetric algorithm to encrypt and decrypt the message contents. The DES has been used in the Cipher Block Chain (CBC) mode [SI. The key and the initialisation vector required for this mode are generated locally within the UA. A new key is generated for each

Formal Specification

In the software engineering research community there has been a considerable amount of effort in analysing languages for both specifying and reasoning about programmes. In the last ten years there has been an increasing interest in definingformal description techniques (FDTs) for describing distributed or concurrent systems. The use of FDTs is of particular interest in the area of standardisation of communication protocols. The three formal description techniques currently being used within the standardisation organisations are CCITT’s Specification and Description Language (SDL), and the languages Estelle and LOTOS developed within ISO. It was felt most appropriate to work with specification languages that have been developed for the purpose of formally specifying forthcoming standards, and which are standards in themselves. The language LOTOS [7] was considered to be the better of these techniques for a number of reasons which we cannot go into, as this is not the purpose of this paper. Briefly, though, the main advantages of LOTOS over the other techniques are its formal semantics, its well-developed theoretical background, and its amenability to mechanical manipulation, such as simulation. LOTOS can be used at varying levels of abstraction, and is a structural language. There is a growing user community of LOTOS, and also the development of a graphical syntax, G-LOTOS [SI. For a detailed introduction to LOTOS refer to [2].

*

4

The Specification Structure

The LOTOS specification actually consists of two specifications, namely the service specification and the protocol specification. Let us first briefly describe the essential difference between the service and protocol Specification.

A system provides a set of “seroices” which allow various interactions between the users in the system. The “protocols” are mechanisms which provide the services. Hence the user is concerned with the nature of the services but not with how the protocol manages to provide them.

83

Security aspects are modelled as part of both service and protocol specifications. That is, each specification is a combination of process definitions, and alm data type definitions.

4.1

Service Specification

A service description should not contain internal details of the system, but should only specify the behaviour of the system in terms of the behaviour at the system interface. All events in the service Specification must therefore take place at the interaction points visible to the user.

In o w description we have only used one interaction point, which is called “user”. There are a number of constraints needed on all events of the system, called global constraints. It is for this reason that only one event format is used (so that the global constraints have the correct event format for every event of the system). This approach is called the constraint oriented specification style. The event format is of the form: ‘user ? user-idName ? user-op:UserInteraction’ Thus every event occurs at gate “user”,has a user-identifier of sort “Name”, and a useraperation of sort “Userhteraction”. Constraints on the values for ‘user-id’ and ‘user-op’ restrict the values to only those values that are valid at that point. The user identifier identifies which user of the system the particular event is related to, and the user operation is the service primitive and associated parameters of the particular event. 4.1.1

constrains the decryption function to return the initial value of an encrypted data message D, provided the same key K has been used. This is a generic property of a symmetric encryption function.

4.2

Protocol Specification

The protocol specification describes the mechanism used by an entity to provide the services described in the service specification. We first give a brief description of the overall structure of the protocol specification and then illustrate how some of the security aspects are modelled within the protocol. 4.2.1

Structure

As in the case of the service specification, the interactions between the User Agents are modelled via a single gate “user”. In addition, to describe the protocol, we need to model the interactions between the User Agents and the Message Transfer System and the Directory. The interactions between a User Agent and the MTS occur via the gate “MTS” and the interactions between the User Agent and the Directory occur via the gate “dir”. A diagram r e p resenting the structure of the protocol specification is given in Figure 2. Each user has a corresponding User Agent process and each User Agent process is described BS an interleaved composition of the following four processes (see Figure 3) :

Modelling Security Service8

From the viewpoint of the service, the security services are primarily of the following form where a request is made for a specific transformation of message, and such an appropriate transformation of the message is then delivered. There is no need to define details of the algorithms used in the security services. However, we must define the properties of the security functions. Firstly, the security services are requested as part of the service primitives of the system. Thus it is necessary to model the security services as data types and values. When a certain service primitive is requested, the security services associated with such primitives can also be requested in the form of parameters of the service primitive (parameters of ‘user-op’). The security services are provided by some forms of manipulation of given data, and also by the addition of extra security parameters. For example, a request may be to send some data, D, encrypted using some given key, I