Introduction. The tuple-space model, also known as LINDA [5] is a ... nism suitable for open, heterogeneous systems. LINDA's ..... edition, Addison-Wesley, 2002.
Establishing Private Communications in Open Systems using Multicapabilities Nur Izura Udzir* and Alan Wood Department of Computer Science University of York, UK {izura, wood}@cs.york.ac.uk Abstract Private and secure communications can be vital for certain applications, for example secure bidding, ecommerce, and online bank transactions. However, it is impossible to carry out private conversations in the open tuple-space model, despite it being a popular coordination model for distributed, heterogeneous systems, where agents can communicate via a common data space without having to know each other’s identity, or having to arrange for a definite rendezvous. In this paper, we present an algorithm for establishing private communications in tuple-space systems using capabilities. In view of the fact that open systems need to be scalable, capabilities may provide a finer control to the loose control coordination of tuple-space systems whilst maintaining their flexibility. As capabilities can only refer to uniquely identifiable objects, we have introduced the concept of multicapabilities⎯capabilities for groups of unnamed objects⎯to be applied to nameless tuples.
1. Introduction The tuple-space model, also known as LINDA [5] is a popular paradigm for coordination in open distributed systems, where agents or active entities may join or leave the system at will. The main component of the model is the shared communication medium, called the tuple-space (TS) where data (tuples) are written into, and retrieved from. The retrieval operations, destructive and non-destructive read, block if no tuple matching the specified template is available. Tuples are sequences of actuals, e.g. 〈9,‘x’〉; while templates are sequences of formals, e.g. 〈?int,?char〉. The tuples are retrieved associatively and asynchronously in a non-deterministic fashion: the retrieval operation may return any matching tuple; and, if a number of agents are waiting for a tuple of the same template, a matching tuple, when available, may be given to any one of them. Interacting via the TS where there is no direct communication between them, the communicating agents are decoupled in name, space and time⎯they need not know each other’s identity, nor co-exist at the same time in order to communicate with each other⎯providing a flexible coordination mechanism suitable for open, heterogeneous systems. LINDA’s __________________ * The author’s other affiliation is the Faculty of Computer Science and Information Technology, Universiti Putra Malaysia.
popularity is shown in its commercial variants, such as Sun’s JavaSpaces [4] and IBM’s TSpaces [18]. Unfortunately, in spite of the above attractive properties, concerns have been raised with regard to LINDA’s loose control. Many solutions have been proposed, at the expense of LINDA’s principal advantages: it is difficult to obtain the optimum balance between flexibility and tighter control. Motivated by this, we extend work on capability-based systems [3, 17] to provide a finer control, without losing the flexibility of LINDA. One example of the loose control in LINDA is that it is impossible to have private communications in the system. The private channel protocol has been proposed by Wood [17] using access control lists- (ACL-) like attributes. As it has been established that capabilities offer more flexibility compared to ACLs [3, 12, 13], in this paper we demonstrate that a private channel can also be established using capabilities. Furthermore, with the help of the combination operations such as sum, explicit garbage collection of tuples can be performed.
1.1. Capability-based systems Examples of early attempts at improving LINDA using a capability-like mechanism is Pinakis’s Joyce-LINDA [11], and Law-Governed LINDA (LGL) [8]. Joyce-LINDA used public-key encryption to support capabilities. Regrettably, the capability values cannot be matched by formals in templates, thus preventing them being passed via TS. Introducing an additional special data type to enable the matching process only complicates things. The notion of capability-based control in LGL is somewhat restricted: capabilities are required in order to send a message to another agent, but none is necessary to receive one. This means that a message can only be sent if the sender has the capability for the target agent. Therefore, there is a possibility of indefinite waiting, since these agents might not be aware of the sender’s need to acquire the necessary capability. A capability-based system has been developed to provide security features in VLOS [3], a distributed operating system based on TSs. Capabilities are required to create new TSs, new field types, as well as type signatures, i.e. groupings of field types which are unique to a particular TS, to make up a tuple type (i.e. template). In VLOS, a TS is created with nothing associated with it, except some basic types, and capabilities. Whenever an agent wishes to perform a standard input/output operation, such as writing a tuple, the system requires it to register the tuple type before the operation can be
carried out. A capability for an object in VLOS consists of a unique identifier and the type of the object (i.e. whether it is a TS, a field type, a type signature, or other objects), the name of the TS (of which the object is a member), a set of rights, and a cryptographic hash function to minimise forgery. Like ours, a capability in VLOS acts as a ‘handle’ to the object it is associated with. Our multicapabilities, however, yield more flexibility in the sense that they are not associated with a TS⎯they can be used with any TS as long as the user possesses the capability for the target TS. Furthermore, the combination calculus (see Section 2.1) of capabilities gives an added advantage for our model to maintain control while being flexible. A μKLAIM [7] capability is a pair that represents the operation allowed on a pattern of the matching (target) tuple, whereas our multicapability is a triple that provides extra features of partitioning via tags, to limit and control agents’ accesses, as well as the combination calculus to further enrich the model. μKLAIM uses its type system to enforce access control. Unlike our capability model that uses dynamic checking, μKLAIM relies on both static and dynamic checking. In the systems mentioned above, capabilities are mainly discussed as an access control mechanism for security purposes, some with the assistance of cryptography, as in [11, 1, 2]. μKLAIM for instance, emphasises security policies: an agent may have ‘knowledge’ of a location name even though it does not have a capability to it. We are concentrating on the functional properties of capabilities as ‘visibility’ filters⎯agents can only know about objects for which they hold a capability, and the capability makes visible a subset of the operations available for that object’s type. This scheme enables a more refined control over agents’ actions (not limited to access control only) on objects in the system, and facilitates certain aspects of coordination, such as resource management [14].
[α,〈?int,?int〉,{d,r,w}], where d, r and w are permissions to perform destructive and non-destructive read, and write, respectively. Our capability model governs that: 1. Every TS and tuple operation requires two-level capabilities: − a uni-capability for the target TS, and − a multicapability for a specified template (a formal for a tuple pattern). 2. For bootstrap purposes, all agents are given: − a default capability (with full rights) for the universal TS (UTS), i.e. a default space that exists throughout the life-span of the system, and that is (publicly) accessible by all agents in the system; and − a universal multicapability for capability type (with the least rights), called cc [ℵ,〈?cap〉,{r,w}], to enable capabilities to be passed among agents. 3. Every request for a new capability from the kernel returns a unique capability with full rights. Based on rule 3, tuples of the same pattern may be referred to by different multicapabilities. For example, if an agent makes two separate requests for a multicapability for the template 〈?str,?int,?int〉, it will get two multicapabilities, each different from the other (i.e. identified by different tags), although they correspond to the same template. If one of the multicapabilties is given to another agent, the second agent can only ‘see’ tuples in the multicapability group it holds, but not those in the other group. Hence, multicapabilities can provide a partitioning of a TS⎯ enabling certain operations to be performed on a tuple of a specific group, but not on one of another group, even though both groups have the same template. The capability data (unique identifier, reference/ template, and permissions) are assumed to be securely encapsulated in the capability and only interpretable by the kernel when the capability is presented for verification.
2. Multicapabilities
2.1. Capability operations
A capability is a ‘ticket’ which specifies what action(s) an agent is allowed to invoke on a certain object [10]. However, unlike ACLs, capabilities can only be applied to named objects, such as TSs, but not the nameless tuples. To overcome this, we have introduced multicapabilities [15], i.e. capabilities for a class of objects: whereas a permission in a uni-capability allows an action on the object it refers to, a multicapability allows the action to be performed on an element of the class. Throughout this paper, we shall use the term ‘capability’ to refer to capabilities in general, and the terms ‘uni-capability’ or ‘multicapability’ accordingly when referring to a specific class. Extending uni-capabilities which are pairs of object identifier o, and rights ([o,{d,r,w}]), each multicapability is a triple of a unique (unforgeable) identifier, the template of tuples it refers to, and a set of rights, e.g. a multicapability for a template of two integers is
Agents may duplicate, or make restricted copies, or even combine capabilities (in sum or subtraction operations) in their possession. There are two types of operations: unary and binary. Unary operations involve a single capability, where a copy of a capability, while having the same unique identifier as the original, may have a restricted template and/or rights. However, it is not possible to add rights, nor to generalize the template in a multicapability. For example, a copy of multicapability [α,〈?int,3〉,{d,r,w}] may have one or more rights removed; and its template restricted to 〈56,3〉 ⎯or any integer value as its first element⎯but not generalized to 〈?int,?int〉 as the second element has been specialized to integer 3 and cannot be altered. Binary operations ‘combine’ two (or more) capabilities in an agent’s possession. We present in this paper two simple binary operations: sum and subtraction.
The sum operation (+) produces a multicapability referring to the template of either multicapability, and represents permissions if any one of the multicapabilities grants that permission. A tuple produced using the sum of two multicapabilities can be retrieved using either multicapability, provided the action is permitted by the multicapability used in the attempted retrieval. To further elaborate on this operation, let us consider the following multicapabilities: c1 = [α,〈?int,?char〉,{d,r,w}] c2 = [β,〈3,?char〉,{r,w}]
Writing a ‘sum’ tuple of these multicapabilities, e.g. ts1.write( (c1+c2)〈1,‘a’〉 );
produces (into tuple-space ts1) a tuple that can be accessed using either c1 or c2, or both multicapabilities. However, as the multicapabilities grant different rights, then any agent who has c1 (or both multicapabilities) can read or remove the tuple, while those with only c2 can only read it. Reading using the sum operation, ts1.read( (c1+c2)〈?int,‘a’〉 );
enables the reader to search both groups ‘simultaneously’. Without sum, the reader must perform two separate reads, e.g. ts1.read( c1〈?int,‘a’〉 ); ts1.read( c2〈?int,‘a’〉 );
with the risk of being blocked on the first group if no matching tuple is available, before it has the chance to search the second group (where the tuple might exist). Therefore, using sum in a read operation reduces the probability of being blocked by half. Indeed, what is more, possible deadlocks can be avoided⎯a sequence of two input operations may deadlock, whereas the sum (which is equivalent to a parallel combination of two input operations) will only block until a tuple becomes available in either group. The subtract operation (–) restricts a capability relative to another. For instance, if we have another multicapability, c3 = [γ,〈3,?char〉,{d}]
an output operation using (c1–c3) will write a tuple of template 〈?int,?char〉, excluding any tuple whose first element is integer 3. This tuple will be written into group c1, and can only be accessed by agents holding c1, but not accessible with c3. An input operation using (c1–c3) would yield a tuple matching the template of c1, except those matching the template of c3. Since the permission(s) in c3 is also subtracted from c1, non-destructive reading is disallowed. The combinatorial (binary) operations offer richer possibilities for capabilities to be manipulated to provide a finer control on objects visibility to agents in open systems.
3. Private channel LINDA is a powerful model for coordination in an open, heterogeneous environment. Its general broadcast communication scheme gives an advantage over many other models. It is unfortunate, however, that its very reliance on open and flexible communications leaves it vulnerable to manipulations, which gives rise to a lot of relevant security problems like, e.g. secrecy and integrity of data and program code. Some applications may require agents to interact privately, a basic communication scheme in many point-to-point communication models, but is not possible in standard LINDA. This leads to the proposals of a number of LINDA variants which provide this facility. Law Governed LINDA (LGL) [8], for example, enables private conversation between agents by means of some global law. Every communication between agents is checked against the law, and only those that do not violate the law are allowed to be completed. For private message passing, the tuple needs to have an additional field (a flag), and the law requires that all messages containing the flag to also specify the sender and the receiver’s identities: an agent can only send a message tuple with its own identification (thus guaranteeing no forgery), and only the agent named as the receiver in the message is allowed to retrieve it. However a global law scales badly, not to mention the cost in enforcement: a copy of the law needs to be executed every time a message is sent/received. SECOS’s rather complicated secure channels protocol [16] uses (symmetric and asymmetric) keys and object locks. This requires the initiator of the communication to have knowledge of the other agent’s public key. The initiating agent establishes the channel by specifying the channel identifier and its own public key, locked with the other agent’s public key, and whole object is then digitally signed using the initiator’s private key. If the other agent is willing to accept the connection, it will then send an acknowledgement message to the initiator containing the channel identifier and the agent’s public key, signed with its private key. Unfortunately, keyrelated control does not discriminate the type of access, e.g. for read-only, but not remove, operation. The original LINDA model consists of a single space to act as the coordination medium, which is quite unfortunate for some applications as there is no privacy in communicating via the public space. Having multiple TSs [6] at first seems to solve this problem, by providing a means to have a TS (other than the universal TS) known only to the two agents concerned. However, this does not solve the problem in open systems as the reference to this TS has to be passed (in a tuple) from one agent to another via a TS that can be globally accessed by both (and all) agents, e.g. the UTS, thus exposing the reference tuple to other agents as well⎯defeating the purpose of having a ‘private’ TS. Attaching access control attributes to objects (TSs and tuples) provides a finer control to overcome this problem
[17]. Forming the basis for the protocol presented (in Section 3.1) in this paper, the private channel protocol in [17] uses ACL-like attributes as the controlling mechanism. The attribute set of each object is composed of two groups: the former indicates the operations permitted to the object’s creator, while the latter controls those of other agents. Therefore, the object’s creator can restrict the attributes to prevent tuples from being removed, as well as preventing leaking TS references (by limiting access to write-only privilege, for instance). The initiator produces a read-only tuple containing the reference to a write-only TS, inviting other agents to engage in private conversations with it. The interested agents can then safely send the initiator their own private spaces via the write-only TS (using the previously supplied reference). We are looking at a more distributed mechanism in controlling objects’ visibility to agents, which is not a built-in mechanism akin to the laws in LGL. Capabilities are more suitable for open distributed systems compared to ACLs and global laws, as they themselves are distributed in the sense that the controlling attributes are held by the agents, rather than being attached to objects; they can be transferred from one agent to another; they accommodate user-defined rights, thus may be dynamically changed; and agents may join and leave the system simply by requesting (and possessing) appropriate capabilities. We therefore implemented the protocol in [17] using capabilities, rather than ACL-like attributes.
3.1.
Setting up capabilities
private
channels
depriving other interested agents of it), including A. In order to remove the tuple later, A must request, and acquire a multicapability for a capability type (uniquely identified with α, stored in c1) (line 3), which it then uses to write the tuple, along with cc in a sum operation (+). Consequently, any agent holding either multicapability may access it (subject to the rights granted by each multicapability). 〈 [contact, {w}] 〉
channel
A
B contact 〈 [channel, {d,r,w}] 〉
ℵ
(a) Establishing contact
〈 [contact, {w}] 〉
UTS ℵ+α
channel
using
To establish a private channel, the communicating agents need to have a reference (capability) to the private TS. Suppose that agent A wishes to invite other agents to engage in a private conversation. A may create a private TS for this purpose. As the newly created TS is known only to the creator, A needs to pass the capability for the private TS to the other agent, say B, via a TS which is accessible by B, i.e. the UTS. Even though the capability tuple is written using cc and is safe from unwanted removal, the UTS, unfortunately, is also accessible by all agents in the system, which means that the capability tuple’s ‘secrecy’ cannot be guaranteed: it cannot be removed, but it certainly can be read by all. This calls for an additional phase to complete the protocol (Figure 1). A needs another TS to act as a ‘letter box’ for the other agent(s) to put the capability for their private TS into, safely concealed from the others. A creates a letter-box TS, called contact (line 1 in Agent A’s code in Table 1), and automatically gets a capability for it with full rights, before restricting the permission on (a copy of the capability for) contact to allow write-only (line 2). It then passes the restricted capability for contact (in a tuple) via the UTS (line 4). Since the tuple is written using the universal cc (identified by ℵ), other agents, e.g. B can read it. As cc does not grant permission for destructive read, the tuple is safe from being removed by any agent (and consequently
UTS ℵ+α
A
B contact
(b) Channel created Figure 1. Creating a private channel in capability-based system. Upon retrieving the capability for contact (line 1-2 in Agent B’s code), agent B creates (and gets a capability for) a private TS, called channel (line 3) and passes the capability for it to A via contact (line 4). Since the (copy of the) capability for contact only allows write, this tuple (containing the capability for channel) is obscured from other agents who may also have (writeonly) access to contact. As the creator of contact, A (who has the original capability with full rights) can retrieve the capability for channel using cc, and may proceed to carry out private conversations with B via channel.
3.2. Example: Secure bidding In this section, we present an example to demonstrate how private channels can be useful for applications such
Table 1. Private channel protocol in capability-based system. Agent A: 1
2 3
//Create contact TS contact = newts(); // contact is [contact,{d,r,w}] //Restrict permission for contact contact’ = contact - {d,r}; //Request new capability for type cap c1 = newcap(
