HCAP: A History-Based Capability System for IoT Devices

03/30/2018
by   Lakshya Tandon, et al.
University of Calgary
0

Permissions are highly sensitive in Internet-of-Things (IoT) applications, as IoT devices collect our personal data and control the safety of our environment. Rather than simply granting permissions, further constraints shall be imposed on permission usage so as to realize the Principle of Least Privilege. Since IoT devices are physically embedded, they are often accessed in a particular sequence based on their relative physical positions. Monitoring if such sequencing constraints are honoured when IoT devices are accessed provides a means to fence off malicious accesses. This paper proposes a history-based capability system, HCAP, for enforcing permission sequencing constraints in a distributed authorization environment. We formally establish the security guarantees of HCAP, and empirically evaluate its performance.

READ FULL TEXT VIEW PDF

page 1

page 2

page 3

page 4

02/06/2018

A Survey on Sensor-based Threats to Internet-of-Things (IoT) Devices and Applications

The concept of Internet of Things (IoT) has become more popular in the m...
04/14/2020

Trusted Wireless Monitoring based on Distributed Ledgers over NB-IoT Connectivity

The data collected from Internet of Things (IoT) devices on various emis...
09/30/2021

Dataset: Analysis of IFTTT Recipes to Study How Humans Use Internet-of-Things (IoT) Devices

With the rapid development and usage of Internet-of-Things (IoT) and sma...
01/28/2022

Constellation: An Edge-Based Semantic Runtime System for Internet of Things Applications

With the global Internet of Things IoT market size predicted to grow to ...
08/03/2022

Abusing Commodity DRAMs in IoT Devices to Remotely Spy on Temperature

The ubiquity and pervasiveness of modern Internet of Things (IoT) device...
01/14/2022

Model-Based Framework for exploiting sensors of IoT devices using a Botnet: A case study with Android

Botnets have become a serious security threat not only to the Internet b...
09/17/2019

Machine Learning based IoT Edge Node Security Attack and Countermeasures

Advances in technology have enabled tremendous progress in the developme...

1 Introduction

Internet-of-Things (IoT) devices collect our personal data (e.g., wearables, sensors) and control the safety of our environment (e.g., thermostat, smart locks). Granting permissions to access IoT devices often comes with significant privacy, security and even safety implications. Yet, authority delegation is a common use case in IoT applications. For example, envision the wide deployment of smart locks on an organization campus. Permissions to unlock various entrances must now be properly granted to members of that organization. In this work, we are concerned with the potential misuse of permissions by users of IoT devices.

Rather than simply granting permissions, further usage constraints shall be imposed on permissions in order to rule out potentially malicious usage patterns. Simple examples of this would include contextual constraints such as not allowing entry after midnight. Such constraints are a way of realizing the Principle of Least Privilege [33]. But we can do even better than contextual constraints. Since IoT devices are physically embedded, they are often accessed in a particular sequence based on their relative physical positions. Monitoring if such sequencing constraints are honoured provides a means to fence off malicious accesses to devices.

Example 1 (Physical Embeddedness).

Alice often stays after office hour, when all the doors of her organization are locked. Special permissions are granted to her to unlock certain doors. When Alice leaves for the day, she passes through entrances , and (corresponding respectively to the lab door, the computer science building entrance, and the campus gate) in that physical order. Not only does Alice require the permissions to unlock the smart locks at , and , ordering constraints shall also be imposed so that, during off hours, (campus gate) is not unlocked before the authorization system registering her unlocking (lab door) and (building entrance). Directly unlocking (campus gate) without going through (lab door) and (building entrance) could very well mean her smartphone has been picked up by an unauthorized party trying to enter the campus from the outside.

Permission sequencing constraints are also important when device accesses must conform to a workflow specification. Kortuem et al. use the term process awareness to refer to the ability of smart objects to guide their users in following operational procedures [21]. Procedure guiding is envisioned to be a key feature of, say, smart construction objects [29].

Example 2 (Process Awareness).

Suppose an industrial process follows an explicitly articulated workflow, in which two conceptual steps, and , are sequentially ordered. Permissions to operate equipments are assigned to each step [40, 9]: e.g., permissions and can be exercised in step , and permissions and can be exercised in step . The permission assignment and the ordering of workflow steps jointly induce sequencing constraints on permission usage: Once is exercised, it is obvious that is being executed, and thus shall no longer be allowed (i.e., no after ). Violation of this sequencing constraint is a sign of equipment misuse.

Constraining the order in which permissions are exercised is in fact the spirit of History-Based Access Control (HBAC) [12, 35, 38, 39, 13, 22, 25], in which the authorization decision of an access request is a function of the access history. HBAC policies can be imposed to restrict permission usage once an access pattern has been detected (no after ). This feature can be leveraged for enforcing the following forms of permission usage control.

Example 3 (Permission Usage Control).

Suppose a campus visitor is only allowed to access a facility (e.g., a smart coffee dispenser) no more than four times during her visit. In other words, we want the authorization system to deny the usage of a permission after it has been exercised for a number of times. In short, permissions are seen as consumable resources. A second form of permission usage constraints is the cardinality constraint, which demands that no more than of the permissions in a set can be exercised [34]. In the special case of and , the constraint enforces permission-level mutual exclusion. Similarly, the Chinese Wall policy [8] can be seen as a third form of permission usage constraints: Once a resource has been accessed, access to resources in conflict with the former will be denied.

Enforcing HBAC policies requires support from the authorization system. The growing scale of smart devices and casual users makes it necessary for device administrators to be able to manage access control policies centrally, while enabling devices to enforce such policies in a decentralized manner (i.e., without the mediation of a centralized reference monitor). Typically, an unforgeable capability (aka security token) is issued by a centralized authorization server to a client, who in turn presents the capability to the resource custodian as a proof of authorization. Examples of such distributed capability systems include the Identity-based Capability System (ICAP) [16], CapaFS [32], O’Auth [18], OpenID [31], and Macaroons [5]. The dual requirements of centralized policy administration and decentralized policy enforcement are the main driver behind the recent push by access management solution providers [15, 30] to adopt the User-Managed Access standard [27] as the choice platform for access management in IoT applications. More generally, distributed capability systems have emerged as a popular choice for decentralized access control in the IoT literature [26, 17, 19]. Unfortunately, none of the distributed capability systems surveyed above offers adequate support for HBAC. The crux of the problem is that policy enforcement in HBAC is a stateful process. A traditional capability, however, captures a static set of authorized permissions. Such capabilities will have to be revoked and reissued by the centralized authorization server whenever the state of HBAC enforcement changes, causing the authorization server to be contacted frequently, thereby nullifying the benefit of decentralized access control promised by distributed capability systems.

This paper proposes a History-Based Capability System, HCAP, for regulating the order in which permissions are exercised in a distributed authorization environment. HCAP is an extension of ICAP [16]. HCAP capabilities carry sequencing constraints in the form of security automata (SA) [35]. Exercising a permission produces an SA state transition, invalidates the existing capability, and generates a new capability reflecting the new SA state. Since the proposed scheme minimizes communication with the central authorization server, and does not require the IoT devices to know about the access control policies, HCAP makes a good building block for UMA-style combination of centralized policy administration and decentralized policy enforcement. We claim four contributions:

  1. We describe the design of HCAP, a distributed capability system that can enforce history-based access control policies (see §3).

  2. We formally establish the security guarantees of HCAP in the form of a safety property and a liveness property (see §4).

  3. In the formulation of core HCAP, it is assumed that the permissions associated with an SA are all related to a single device. We propose an extension to HCAP that relaxes this restriction, thereby allowing an SA to regulate the permission usage of multiple devices (see §5).

  4. We empirically evaluate the performance of HCAP (see §6).

2 Related Work

There are two kinds of distributed authorization systems [37]. The first kind are the credentials-based authorization systems (F. Schneider’s terminology), in which the client presents a set of certificates to an authorization system as a proof of policy compliance [1, 2, 24, 3]. The certificates in the compliance proof are typically issued by different authorities, and each certificate corresponds to an assertion in a logical language used for specifying conditions of authorization. The authorization system is presumed to know the access control policy, which is specified in the aforementioned logical language. The second kind are the distributed capability systems, in which the authorization system, upon successful check of policy compliance, issues to the client an unforgeable capability (aka security token) [16, 32, 18, 31, 5]. The client then presents the capability to resource custodians to gain access without further mediation of the authorization system. The resource custodians are thus freed from needing to know and manage the access control policies. This work contributes to the literature of the second kind. To the best of our knowledge, HCAP is the first distributed capability system to support History-Based Access Control (HBAC). We advocate the employment of this feature for sequencing permission usage in IoT environments.

HCAP is an extension of ICAP [16] in order to enforce HBAC policies. While an ICAP capability carries the list of granted permissions, an HCAP capability carries a partial specification of an SA, which we call an SA fragment. In the degenerate case when the SA has only one state, an HCAP capability is structurally equivalent to an ICAP capability. Another point of comparison concerns the exceptions. Exceptions are created in ICAP when the authorization server informs the resource server of capability revocations. In HCAP, an exception is created when the resource server exercises a permission that leads to SA state transition, thereby invalidating an existing capability. In addition, HCAP exceptions are much more complex: each exception chronicles the history of SA state transition, rather than a single event of revocation.

ICAP has also been extended by Mahalle et al. for IoT applications [26]. Their extension does not support HBAC.

The State-Modifying Policy (SMP) language is an authorization logic that supports the specification of changes to the protection state as a result of authorization [4]. SMP is designed particularly for HBAC policies. Its enforcement model, however, assumes a centralized resource guard (aka PEP), and is therefore incapable of supporting decentralized access control in the manner of HCAP.

In history-based access control, the history of access is tracked by a reference monitor, and this access history forms the basis of making authorization decisions [12, 35, 38, 39, 13, 22, 25]. Schneider proved that only safety properties are enforceable using a reference monitor that tracks execution history, and proposed the Security Automata as an automata-theoretic representation of reference monitors [35]

. In this work, permission sequencing constraints are encoded as a Security Automaton and embedded in a capability. State transition occurs when the capability is presented to a resource custodian, who may not immediately relay this change back to the central authorization server. The representation of the current automaton state is therefore distributed across multiple participants. The technical challenge addressed by HCAP are (a) to ensure the coherence of this distributed representation, (b) to provably prevent replay attacks, and (c) to achieve the above while minimizing communications with the authorization server.

3 A History-Based Capability System

3.1 Overview

Protocol Participants.

We envision a distributed authorization system akin to UMA [27], consisting of resource servers, clients and an authorization server.

Resource servers.

Each resource server encapsulates a number of resources within a single device, and acts as their custodian. For example, a smart weather station tracks a number of weather readings, each considered a separate resource. Operations can be performed on the resources. In the smart weather station, an operation for a given weather reading (e.g., temperature) can be “retrieve” or “post reading to Facebook.” A permission is an operation-resource pair. An access request is a request for the resource server to exercise a permission: i.e., perform the operation on the resource.

Clients.

Clients are users who, mediated by software systems (e.g., smartphone apps), direct access requests to resource servers.

Authorization server.

The authorization server is responsible for access management. Administrators of resource servers and their resources may specify access control policies to indicate which permission is granted to which client. We assume that an Application Programming Interface (API) is in place for an administrator to specify resources and operations to be protected. What is unique in HCAP is that the access control policy not only grants a set of permissions to a client, but also prescribes constraints on the order in which the permissions are to be exercised. As we shall see below, such constraints will take the form of a security automaton [35].

The authorization server issues capabilities [10] to clients, who in turn present the capabilities to resource servers.

Trust Assumptions.

The following are assumed. (1) The authorization server and resource servers are trusted parties. (2) Clients are not trusted: they actively attempt to forge, share with others, or replay capabilities (and other tickets). They are also unreliable: they may lose capabilities (and other tickets) that have been issued to them. (3) A public key infrastructure (PKI) is in place, so that the authorization server and the resource servers can authenticate one another, as well as the identity claims of clients. It is assumed that the authorization server can verify membership of the resource servers and clients that belong to the organization. (4) Each resource server has established a shared secret with the authorization server. (5) Devices are equipped with a secure untamperable hardware that holds their secret values. (6) We assume a central clock that is used to synchronize all individual clocks in the system, and assume entities communicate over secure channel.

Design Objectives.

HCAP is designed with the following objectives in mind.

O1

Resource servers shall not maintain knowledge of client identities and sequencing constraints. The authorization server alone is responsible for access management. In other words, when access control policies evolve, the resource servers do not need to be reconfigured.

O2

Communication with the authorization server shall be minimized, because that server is a communication bottleneck. A protocol in which every access request is mediated by the authorization server is considered a non-solution.

O3

The computational demand for resource servers shall be minimized, as these servers are computationally constrained.

Solution Approach.

The sequencing constraints for permissions are essentially safety properties [23], encoded as security automata (an automata-theoretic representation of reference monitors) [35]. When a client initiates a protocol session, a security automaton is started to monitor the order in which permissions are exercised in that session. The authorization server tracks the current state of that automaton. Since the resource server does not know the security automaton (O1), and the authorization server shall not be involved in policy mediation (O2), part of or all of the security automaton is carried in the capability. When the client presents the capability to a resource server for gaining access, the resource server simulates the automaton’s state transition. State transition is not communicated immediately to the authorization server (O2). Instead, the resource server records the state transition, and issues a new capability to the client (while revoking the previous one). To conserve the computational resources of the resource server, the HCAP protocol has the resource server flushes its record of state transitions back to the authorization server from time to time, a process known as garbage collection (O3). For the same reason, the capability may not carry the full specification of the security automaton, thereby making capability processing lightweight (O3).

As the knowledge of the authorization server in the automaton state may lag behind the state transitions carried out remotely by resource servers, the current state of the security automaton is a datum distributed between the authorization server and the resource servers. The design of HCAP ensures the coherence of this distributed representation of the automaton state, and that outdated capabilities are not replayed by the client to gain access illegally.

Core HCAP

To facilitate presentation, this and the next section will present core HCAP, in which there is only one resource server. The extension of core HCAP to handle multiple resource servers is deferred to §5.

Preliminaries.

We write and respectively for the domain and range of function . A partial function is a function with domain and codomain . A finite partial function (i.e., finite domain) is also called a map.

3.2 Building Blocks

Security Automata.

A security automaton is an automata-theoretic encoding of a safety property [35]. Here, we adopt the finitary variant of deterministic security automaton as defined by Fong [13]. A Deterministic Finite Security Automaton (DFSA), or simply Security Automaton (SA) in this work, is a tuple , where is a finite set of permissions, is a finite set of automaton states, is an initial state, and is a partial transition function (i.e., may be undefined for some pair of state and permission ). An SA is essentially like a deterministic finite automaton in which every state is a final state. An SA accepts a sequence of permissions so long as the transition function defines a transition for every step. Policy violation is detected when there is no transition for a permission in the current state. For instance, the two SA below enforce the policies described in Example 1 (left) and Example 2 (right).

When the SA is in a state , the permissions that bring back to are stationary permissions, and the permissions that cause a transition to a different state are transitioning permissions. We define to be the set of stationary permissions in state . Similarly, we define to be the set of transitioning permissions in state .

Tickets.

The authorization server and resource server issue tickets to the client, who in turn uses them to justify requests. To ensure ticket authenticity and non-transferability, each ticket carries an authentication tag obtained from the shared secret and the client identity . In this work, we follow the lightweight tagging mechanism of ICAP [16]. Suppose is an assertion, the ticket signed by secret key for client is , where is a hash function and “” means the concatenation of and . Upon receiving a ticket from a client , one can check its authenticity by checking that the hash value in is equal to . The use of to compute the hash value also ensures that the ticket is non-transferrable.

There are two kinds of tickets, capabilities and update requests, which we introduce in turn.

Capabilities.

Capabilities are tickets issued by either the authorization server or the resource server to assert that certain permissions can be exercised by the client. A client may present an access request along with the capability to gain access. A capability issued to client for session has the form . Every capability asserts that the SA is in a certain state , and thus some corresponding permissions can be exercised for . The timestamp , also called the serial number of the capability, identifies indirectly by identifying the time when the SA entered into state . The component is an SA fragment, which identifies the permissions (stationary and transitioning) allowed in state , as well as the transitions emanating from . In some sense, an SA fragment is a partial specification of the SA, with current state (formal definition to be given below). The specification is partial, because the authorization server is not obligated to encode the entire SA in one capability. This may be because full encoding causes the capability to be bloated, or because the authorization server desires to be synchronized with the resource server more often, or because the underlying communication protocol limits the capability size.

SA Fragments.

An SA fragment is a representation of two things: (a) a (possibly incomplete) transition diagram, and (b) the current state of the transition diagram. States in the transition diagram are identified by symbolic names. We assume there is a countably infinite set of symbolic names as well as a distinct marker (pronounced ‘unknown’) such that . An SA fragment is a pair . The component is a finite partial function in which identifies the states of a transition diagram. For each name , specifies the transitions emanating from the state with name . More specifically, is a pair , so that is the set of stationary permissions of , and maps each transitioning permission of to either a next state or the marker . When , the transition diagram permits the transition but does not identify the next state of the transition (thus is a fragment rather than a complete SA). We further require that , and . Lastly, the second component of identifies the current state of the transition diagram, such that . It is easy to see that one can use an SA fragment to partially specify an SA (i.e., a subset of states plus a subset of transitions). An SA fragment can be encoded as a JSON (JavaScript Object Notation) object in a straightforward manner [11].

Transitions can be computed efficiently when SA fragments are encoded in JSON. Given an SA fragment for which , is defined to be (a) if , (b) the fragment if , and (c) if . Otherwise is undefined.

Our security guarantees depend on the condition that the SA fragments embedded in capabilities are “conservative” partial specification of the corresponding SA: i.e., the SA fragment does not allow transitions that are not supported by the corresponding SA, a notion that we formalize in the following. Let be an SA fragment, be an SA, and be an SA state. Then is safe for in state if and only if there exists a function such that (a) , and (b) for every , where , the three conditions below hold: (i) ; (ii) ; (iii) for every , either or .

Lemma 1.

Suppose is an SA, , and SA fragment is safe for in . Let . Then the following properties hold: 1. is defined only if is defined. 2. If , then is stationary for . If , then is transitioning for . 3. If is an SA fragment (rather than ), then is safe for in .

Update Requests.

A second kind of tickets is an update request, which has the form . An update request is issued by the resource server, asserting that since last synchronized with the authorization server, is the list of transitioning permissions that have been exercised by the resource server for the session . The construct is called an exception, for it describes how the knowledge of the authorization server has been out of sync.

Exceptions.

An exception records the history of the resource server having exercised certain permissions in the past. It is defined inductively as follows:

where and . Essentially, is a list of permission-timestamp pairs. Each pair contains a permission and the time at which was exercised. The permissions are listed in descending order of time (more recent ones are listed first). We write for the set of all timestamps appearing in , as well as and respectively for the minimum (least recent) and maximum (most recent) timestamps in .

We write to signify the SA state obtained by starting at state and exercising the permissions of in chronological order. That is, , and . is undefined if one of the recursive calls is undefined.

A similar notation, , can also be defined for SA fragments: , and . As expected, is not defined if the nested calls are not defined, or if they return .

Sometimes we want to apply only some of the transitions in an exception list to an SA fragment. Suppose for some . We then write to denote , and to denote . It is not hard to see that .

3.3 Protocol Description

Server Internal States.

The authorization server and the resource server maintain a shared secret . In addition, the authorization server maintains three maps for session administration: (a) is the SA for session , (b) is the state of last known by the authorization server, and (c) is the timestamp when is registered by the authorization server to have entered into state . The timestamp will be used as the serial number of the next capability issued by the authorization server for session . Lastly, the authorization server precomputes an SA fragment for every SA stored in and every state of . It is assumed that is safe for in .

The resource server maintains two pieces of information: (a) a timestamp , which marks the minimum serial number of capabilities that the server considers valid, and (b) a map , which records, for each known session ID , the exception that chronicles the transitioning permissions the resource server has exercised since the SA of has entered the state .

Session Initialization.

A client who intends to access a resource server shall first authenticate itself to the authorization server, and then request the initiation of a new protocol session for that resource server. The authorization server will consult an access control policy, and decide if access shall be granted.111The authorization decision can take into account identities, roles (RBAC) [34], attributes (ABAC) [20] and relationships (ReBAC) [14]. If the authorization decision is positive, a new session ID is created. The access control policy will grant a set of permissions to the session, and also prescribe an SA to regulate the order in which permissions are to be exercised within that session. The session is initialized as follows: ; ; ; The capability is then issued to client , where is the shared secret between the authorization and the resource server, , and .

Input: A client access request , where is the client’s authenticated identity, is the permission to be exercised, and is a capability for session , such that and .
Output: A set of tickets, or a failure response.
Data: The resource server maintains the following persistent data: (a) a secret it shares with the authorization server, (b) a timestamp , and (c) a map that assigns an exception to each known session ID.
1 if  is not signed by for , or  then
2       return failure
3if  is undefined, or  then
4      
5else if  then
6      return failure
7if  then
8       Exercise permission ;
9       return
10else if  then
11       Exercise permission ;
12       ;
13       ;
14       ;
15       if  then
16             return
17      else
18             return
19      
20else return failure ;
Algorithm 1 Authorization procedure of the resource server.

Authorization.

The client requests the resource server to exercise a permission by presenting a triple , where the capability is the justification for access. The identity of is first authenticated, and then the request is authorized according to Algorithm 1. The resource server first checks the authenticity of the capability (line 1). It also rejects capabilities with serial numbers earlier than . As we shall see below, is the time of the last garbage collection, whereby the authorization server and the resource server synchronize their knowledge of the SA’s current states. Such a synchronization invalidates all capabilities with serial numbers earlier than .

The serial number of the capability is then compared to in lines 11. The goal is to see how current the capability is in comparison to the knowledge of the resource server. Line 1 corresponds to the case when the capability is issued by the authorization server, and the latter’s knowledge of the SA state is more current than that of the resource server. Consequently, is reset. Line 1 corresponds to the case when the capability captures an SA state that is older than what the resource server knows. The capability is therefore rejected. The fall-through case of lines 11 is when equals , meaning that the capability is as current as the knowledge of the resource server, and nothing needs to be done in this case.

Lines 11 handle requests that involve the exercising of stationary permissions. No new ticket is issued.

Lines 11 specify the case when the request involves a transitioning permission. The permission is exercised, and the transition is recorded in (line 1). The provided SA fragment is then used for computing the next SA fragment (line 1). A new capability is issued for the new SA fragment (line 1). Line 1 will be discussed below under the heading Update Requests.

If the permission requested is neither stationary nor transitioning, then the request is denied (line 1).

Update Requests.

An update request is issued when the SA fragment embedded in the capability does not provide enough information for the resource server to construct the next capability (line 1). The client is expected to take the update request to the authorization server, so that the latter can update its record of the current SA state. The authorization server will only accept an update request if . The result is that is updated to the current time, and is updated to , where is the transition function of . Lastly, the authorization server will issue to the client a fresh capability, in which the SA fragment is .

Garbage Collection.

The resource server accumulates exception information in due to the creation of new sessions and exercising transitioning permissions. Tracking exception information strains the resource server, which is hosted on constrained hardware. That is why “garbage collection” needs to be performed from time to time. This involves the resource server (a) sending the contents of (e.g., encoded as a JSON object) to the authorization server, (b) resetting to an empty map, and (c) setting to the current time (i.e., time of garbage collection). Step (c) invalidates the tickets issued prior to garbage collection, forcing clients to obtain fresh capabilities from the authorization server.

Upon receiving , the authorization server updates the SA state on record for each defined in . More specifically, is updated to , and to the time of garbage collection.

Ticket Recovery.

Clients are unreliable, and may accidentally misplace tickets. As tickets contain crucial information for the proper execution of the protocol, two mechanisms of ticket recovery are in place.

First, a client may contact the authorization server, and have the capability with serial number reissued. The SA fragment of that capability is . This is the standard means for obtaining a working capability after garbage collection.

The method above may not be sufficient for recovering the latest tickets. In particular, if transitioning requests have already been made since , then the resource server has issued more recent tickets. So a second ticket recovery mechanism is in place, in which the client may present to the resource server a previously issued capability , such that , and then the resource server will use together with to reconstruct the latest ticket for (either an update request or a capability). Details of this mechanism are provided in the next section in transition rule T-Rcv. The latest ticket for a session can always be recovered by applying the first and second recovery mechanism in sequence.

3.4 Discussions

Authorization server.

The authorization server has freedom to construct any SA fragment as so long as the fragment is safe for in . The following are some possibilities:

  • If the SA contains a single state, then the HCAP protocol degenerates to ICAP, as all permissions are stationary.

  • Consider the case when every capability issued by the authorization contains an SA fragment such that , , and . That is, all transition targets are unknown. Such a capability describes only the stationary and transitioning permissions (via and respectively) of the current SA state. This results in highly lightweight capabilities, and the processing overhead for the resource server is minimized. An update request will be returned every time a transitioning permission is exercised, thereby forcing the client to communicate with the authorization server whenever a transition occurs.

  • Capabilities may be constructed to capture several levels of transition. For example, if it is known that the most frequent transitions will oscillate among a small number of states, then that region of the transition diagram can be embedded in the capability. Update requests will be returned infrequently.

  • If is small, then the entire specification can be captured in the capability. No update requests will ever be returned.

Resource server.

There are two approaches to decide when garbage collection should be triggered:

  1. Garbage collection can be invoked on regular intervals (e.g., every 8 hours). This ensures that sessions that are no longer active will not occupy resources indefinitely.

  2. Garbage collection can also be invoked when reaches a certain size threshold, or when one of the exception lists exceeds a certain length threshold. With this approach, is guaranteed to never grow beyond a predetermined capacity.

A combination of both approaches is recommended for a realistic implementation: perform garbage collection in regular intervals as well as when the capacity/length threshold is reached.

4 Security Guarantees

Replay attacks are the main security concern for HCAP: Is it possible for the client to gain illegal access by presenting a previously issued capability to a resource server after the SA has already transitioned to a state in which that capability is no longer representative of . In this section, we formulate a formal model for an HCAP protocol session, and demonstrate that replay attacks are impossible (Safety). We also demonstrate that the protocol is resilient to unreliable clients who misplace tickets (Liveness).

We model the HCAP protocol as a state transition system. Each protocol state captures the state of the entire distributed authorization system, including the internal states of the authorization server, the resource server and the client. A protocol state transition occurs when the protocol participants interact with one another. The main goal of verification is to establish a correspondence between the distributed authorization system and a reference monitor that runs in a centralized system (Theorem 1).

Our state transition model abstracts away the following aspects of HCAP: (1) Ticket forging is not modelled as we assume that it is adequately prevented by authentication tags. (2) As protocol sessions are independent from one another, the model specifies the behaviour of one protocol session only. (3) We omit the minor detail of becoming undefined after garbage collection.

Protocol States.

Throughout this section, we assume that is the SA for the protocol session being modelled. We further assume that the authorization server has pre-computed, for each state , an SA fragment that is safe for in .

Definition 1 (Protocol States).

A protocol state is a 4-tuple , where the four components are defined as follows.

  • The component is the global clock value.

  • The authorization server state is a pair , where is the state of last known by the authorization server, and is the time when the above knowledge is registered by the authorization server.

  • The resource server state is a pair , where is the minimum serial number for capabilities that the resource server considers valid, and exception records the transitioning permissions that have been exercised by the resource server since enters into state .

  • The client state is the set of tickets that have been issued to the client throughout the protocol session. A ticket is of one of two forms: (a) an update request , where is of the form , or (b) a capability .

Let be the set of all protocol states of the above form.

Initial State.

The protocol is intended to begin at the initial state where , .

State Transition.

A transition identifier identifies a protocol event that causes a change to the protocol state:

where is a permission, is a ticket, and is a set of tickets. Let be the set of all transition identifiers induced by .

We specify below a transition relation . The relation is specified in terms of transition rules, which identify the conditions under which , where , , , and . By default, , , and , unless the rules explicitly say otherwise.

T-Iss

The authorization server issues a capability to the client.

Precondition:

Effect:

.

T-ReqS

The client requests to exercise a stationary permission.

Precondition:

, , , , , , , .

Effect:

if .

T-ReqT

The client requests to exercise a transitioning permission.

Precondition:

, , , , , , , .

Effect:

First, , where if , or if . Second, , where if , or otherwise.

T-Fsh

Garbage collection.

Precondition:

.

Effect:

First, , , and . Second, if .

T-Upd

The client updates the internal state of the authorization server.

Precondition:

, , , and .

Effect:

, .

T-Rcv

The client asks the resource server to recover a lost ticket.

Precondition:

, , , and .

Effect:

Let . There are three cases. (1) If is undefined, then . (2) If , then . (3) Otherwise, .

T-Drp

The client accidentally drops some of its tickets.

Precondition:

, .

Effect:

.

Appendix A enumerates the state invariants that are satisfied by the initial state and perserved by the state transition relation.

Security Properties.

Consider protocol state , where and , such that satisfies the state invariants in Appendix A. The effective SA state of protocol state , denoted , is if , or otherwise. The internal states of the authorization and resource server is a distributed representation of the effective SA state. The main theorem below asserts that the distributed authorization system mimics the behaviour of the centralized reference monitor that represents.

Theorem 1 (Safety).

Suppose satisfies the state invariants in Appendix A, and . Then the following statements hold: 1. If then . 2. If is not of the form then .

A proof of the theorem above can be found in Appendix B.

The next theorem asserts that the client can eventually obtain a working capability (before garbage collection occurs), even if tickets are misplaced.

Theorem 2 (Liveness).

Suppose satisfies the state invariants in Appendix A. Then there exists a (possibly empty) sequence of transitions , such that each is neither nor , , and contains a capability for which and .

A proof of liveness is given in Appendix B.

5 Multiple Resource Servers

We have been assuming that, when the client requests the authorization server to grant access to a pool of resources, the entire pool is guarded by a single resource server. This section presents an extension to HCAP for accommodating resource pools guarded by multiple resource servers.

Every resource server has a unique identifier . We write to denote the shared secret established between the resource server and the authorization server. In §3.1, a permission is defined to be an operation-resource pair. We assume that the resource identifier within a permission also identifies the resource server that holds the named resource, and that it takes only time to reconstruct from . (This is true if the resource is identified by a URI, as in the implementation reported in §6.)

New Concepts.

Our design of the multiple resource servers extension aims to preserve the security guarantees of §4. To this end, the design is based on three concepts.

(1) Baton holding. A global invariant is that, at most one resource server tracks the exception list for a session . That resource server is said to be “holding the baton (i.e., ) for session .” This allows the security proofs in §4 to (mostly) transfer to this new setting, with one exception. Suppose a resource server does not hold the baton for . Then a malicious client may replay to an outdated capability for . The resource server would not be able to differentiate between the following two cases: Is it the case that (i) no resource server holds the baton (i.e., the baton is garbage collected), or (ii) another resource server holds the baton (a replay attack)? Therefore, in the extended HCAP scheme, the authorization server tracks an additional boolean flag for each session to differentiate between (i) and (ii).

(2) Remote capability validation. A capability for session is signed by a specific shared secret, say , so that only knows how to check the hash value of . Capability validation also involves consulting , and thus needs to hold the baton for as well. When is presented along an access request to a resource server different from , will now have to request to perform capability validation on its behalf (aka remote capability validation).

To facilitate remote capability validation, a capability now has the form . The new element explicitly identifies the resource server who knows the secret key . In other words, , and thus can validate the capability.

To preserve the efficiency of stationary transitions, we further assume the SA satisfies the property below:

(1)

Intuitively, transitions going into a state are triggered by permissions that can be exercised on the same resource server. Consequently, exercising a stationary permission never causes remote capability validation (and baton passing, see below). This ensures stationary transitions are always efficient. Property (1) also makes it natural to associate a resource server to every state : transitions into can always be conducted on resource server .

(3) Baton passing. When requests to perform remote capability validation, will pass to after validation succeeds. This step is known as baton passing. The intention is that stationary transitions performed on after that point will be efficient (i.e., not involving remote capability validation).

Server States and Session Initialization.

In addition to , , and , the authorization server maintains a boolean flag for each session . The invariant is that is true if and only if at least one of the resource servers has the baton for (i.e., is defined on that resource server). When a new session starts, the authorization server sets to false, since is not yet defined on any resource server.

Authorization.

When a request is presented to a resource server , authorization is performed via Algorithm 2, which is composed of three sections.

(1) The first section, consisting of line 2 only, has no counterpart in Algorithm 1. That line checks whether the resource server can actually exercise the permission . This check is necessary because can only be exercised by .

(2) The second section, made up of lines 22, has the same role as lines 11 in Algorithm 1. The section validates the integrity of the capability, and initializes if necessary.

If is specified as the validator, then Algorithm 3 is invoked locally on to perform the validation logic. Algorithm 3 is mostly equivalent to lines 11 in Algorithm 1, with one exception. When does not hold the baton (i.e., is not defined), it is because either (i) no resource server holds the baton, or (ii) another resource server holds the baton. Case (ii) corresponds to a replay attack. This is prevented by lines 33 of Algorithm 3, which contact the authorization server to confirm case (i).

If the validator is a resource server other than , then requests to run Algorithm 3 remotely (line 2). (During remote capability validation, the identifier in Algorithm 3 refers to the validator .) If validation succeeds, then the baton is passed to (lines 22).

(3) The third section is composed of lines 22. This last section of Algorithm 2 plays the same role as lines 11 in Algorithm 1. Two points are worth noting. First, the capabilities and update requests issued by are signed by the instead of (lines 2 & 2). Second, when is stationary, assumption (1) guarantees that , and thus no new capabilities need to issued (line 2).

Input: A client access request , where is the client’s authenticated identity, is the permission to be exercised, and is a capability for session and validator , such that and .
Output: A set of tickets, or a failure response.
Data: The resource server maintains the following persistent data: (a) its identity , (b) a secret it shares with the authorization server, and (c) a map that assigns exceptions to session IDs.
1 if  then return failure;
2 if   then
3       Invoke Algorithm 3 locally on to validate ;
4       if Algorithm 3 fails then return failure;
5      
6else
7       Request to run Algorithm 3 to validate ;
8       if Algorithm 3 succeeds then
9             sends the contents of ;
10             deletes its copy of ;
11             stores the received contents locally in ;
12            
13      else return failure;
14      
15if  then
16       Exercise permission ;
17       return ;
18      
19else if  then
20       Exercise permission ;
21       ;
22       ;
23       ;
24       if  then
25             return ;
26            
27      else
28             return ;
29            
30      
31else return failure;
Algorithm 2 Authorize access request (mult. res. servers)
Input: An authenticated client identifier and a capability of the form .
Output: Success or failure.
Data: The resource server maintains the following persistent data: (a) its identity , (b) a secret it shares with the authorization server, and (c) a map that assigns exceptions to session IDs.
1 if  is not