Capability Accounting for Decentralized Systems using the COAST Architectural Style

A decentralized system is a distributed system for which there is no central administrative authority to dictate how the distributed subsystems must be developed, operated, or maintained.  In decentralized systems service providers and service clients can each operate under different authority and evolve independently.  Designing and implementing these systems is a substantial challenge.  ISR Director Richard Taylor’s research group addresses these questions from a fresh perspective, COmputationAl State Transfer (COAST), an architectural style for secure and adaptive decentralized systems.  COAST constructions permit and encourage continuous accounting and systemic auditing to verify the correct operation and integrity of critical elements of a decentralized system.  Under COAST the basic unit of exchange and accounting is a capability (an unforgeable right to perform some action within a system).  Taylor and his group propose that capability accounting — tracking the creation, transfer, exercise, and revocation of capability — is fundamental to the debugging, verification, and forensic auditing of decentralized systems.

Taylor’s researcher group has made fundamental contributions to the design and evolution of the world’s largest and best known decentralized system: the World Wide Web.  ISR alumnus Roy Fielding’s work on the HTTP 1.1 protocol played a major role in the astonishing growth of the web.  His Representational State Transfer (REST) has gained widespread acceptance as an architectural style for scalable web services, but as web applications pushed the web in new directions, ISR alumni Justin Erenkrantz and Girish Suryanarayana, and Ph.D. student Michael Gorlick defined Computational REST (CREST), a distinct architectural style for a new generation of decentralized, autonomous, self-governing applications where independent and physically distributed agencies collaborate by exchanging computations rather than content. 

Gorlick further evolved this work into COmputAtional State Transfer (COAST), which provides new principles to support the design of openly secure decentralized applications, and has built a new generation of infrastructure that supports more sophisticated forms of computational exchange. COAST addresses security as a fundamental concern. COAST targets decentralized applications where organizations offer services formulated as execution hosts (called peers) and third-party organizations create their own custom-tailored versions of services by dispatching computations to asset-bearing peers.  Decentralized security and guarding against untrusted or malicious mobile code are principal island concerns.  To this end, COAST offers two distinct forms of capability, (1) functional capability: what a computation may do, and (2) communication capability: when, how, and with whom a computation may communicate.  Functional capability is both granted and constrained by the execution site <E, B> to which a computation is confined. For any execution site, E is an execution engine that defines the execution semantics of the computation as well as any imposed machine-specific limits, and B is the binding environment that contains all functions and global variables accessible to the computation.

Communication capability is both granted and constrained by capability URLs (called CURLs).  A CURL is a capability that conveys the ability for two computations to communicate. A CURL c issued by a computation x, is an unguessable, unforgeable and tamper-proof reference to x that grants to any computation y holding c the power to transmit messages to x. CURLs are used to constrain interactions with a computation and also to bound the services that it offers.

In her doctoral dissertation ISR alumnus Alegria Baquero applied the COAST architectural style  to the security challenges of sharing healthcare data.  Her work explored how COAST could be used to: (1) securely exchange personal health data among users and providers with heterogenous levels of trust and permissions, and (2) empower providers to offer personalized services to the large numbers of users and organizations involved. Alegria developed COASTMed, a COAST-based software system for Electronic Health Records (EHR) management that assigns policy-based rights to individuals to access and manipulate  their data, and allows service providers to offer fine-grained, customer-controlled access to patient information.

Even in a world of perfect security, however, continuous auditing is necessary to verify the correct operation and integrity of critical systems.  As part of an NSF-funded project, graduate students Matias Giorgio and Gorlick along with ISR staff member Kari Nies are exploring systemic auditing, auditing policy, and architectural accountability in COAST systems.  The objective of this work is twofold: first, to create a framework that can capture, store, and analyze capability events, and second, to verify the framework and its efficacy within a real-world domain: financial trading platforms.

Before joining ISR, Giorgio worked for several years as a professional software developer, building monitoring systems for the financial industry.  Giorgio observes, “Working with these kind of systems is very challenging, especially when something goes wrong because they can’t be stopped for analysis; logs must be collected and inspected while the systems are still running.”

Auditing Policy and Systemic Auditing of Capabilities

In the proposed framework, four different types of events are captured and analyzed: the creation, exploitation, transfer, and revocation of communication capabilities. Creation occurs when a COAST peer creates a CURL which allows other peers to send messages to it. Exploitation occurs when one peer sends a message to another peer via a CURL. Transfer occurs when a peer sends a CURL embedded in a message to another peer. Revocation occurs when a CURL is invalidated and can no longer be used for communication.

Giorgio has augmented the COAST platform in order to capture capability events and store them in a database for future inspection and analysis, as shown in Figure 1.  Additionally, Giorgio is developing COMET (COast Monitoring Event Tool) a tool that can inspect and analyze capability events, detect event patterns, highlight useful information, and report anomalies.

COMET can be used to compare observed event patterns against expected patterns in order to determine whether a system behaves as it should.  Furthermore, COMET can also help developers perform exploratory analyses in order to understand the dynamics of a system, including who is communicating with whom, how often and, in some cases, why.

Figure 2 shows three peers running computations in a COAST system. Computations send messages to other peers as long as they hold valid CURLs. For example, the computation x₅ is able to send messages to computation x₁ because it holds the CURL c1. A CURL can be seen as a voucher that gives its holder the right to send a message to who issued it.

Messages sent from one computation to another can take various forms and its interpretation depends entirely on the recipient. A message can contain pure data such as numbers, strings or even CURLs, binding environments (i.e. a mapping between free variables and actual data or implementations) or closures (i.e. a parameterless computations). Sending closures is especially important because it is the way in which a computation can be deployed on a foreign peer. Furthermore, a closure may have CURLs embedded, as part of its own definition.

In order to receive messages, x₁ must create a CURL (i.e. c₁) that other computations will use to send messages to it. That creation event is captured by the platform. For the sake of keeping things simple, we will assume that x₅ somehow obtained the created CURL c1 and has the right to use it. When x₅ sends a message to x₁, it is exploiting the capability referenced by c₁. This event will also be stored into the database. In COAST, computations can setup filters and constraints for the reception of messages; assuming the message passed those filters, x₁ will receive the message, and that event will be stored as well.

In the same example, the computation x₆ possesses the CURL c₃, which enables its holder, to send messages to its creator (i.e. x₃). Imagine that for some reason unknown to x₃, x₆ transferred the CURL c₃ to x₅ in a previous communication.That is, x₆ included c₃, as a piece of data, in the payload of a message sent to x₅. Now, x₅ is also enabled to communicate to x₃. Transferring CURLs is another event captured. Finally, because x₃ does not trust x₅ and considers that security might have been compromised, x₃ revokes the CURL c₃. From that moment, the CURL c₃ is no longer valid and cannot be used either by x₅, x₆ or any computation that possesses it.

Capability Accounting Applied to Financial Trading

Giorgio and Nies are developing a COAST-based model of a securities trading system to illustrate how capability accounting can be used by developers to: debug a system, inspect the behavior of a component, and monitor its security.

In the example illustrated in Figure 3, a trading firm deploys a trading algorithm into a broker’s infrastructure to trade stocks on an exchange.  After that, the trading algorithm should immediately register itself with the Risk Management and the Market Data servers in order to receive market updates and use this information to start dispatching orders into the Order Router.  Now imagine that the trader’s computation does not generate an order within an expected time period, such as 10 seconds.  Several problems could prevent it from behaving as expected: the deployment or the initial registration with the servers failed, the connection to the Order Router could not be established, or servers were unable to send updates back, just to name a few.  These issues are difficult to debug; they involve not only the trading computation but also interactions with other components.  Looking at captured capability events can help software developers localize faults more quickly.

Registration on the exchange’s servers includes creating the necessary CURLs and transferring those CURLs to the servers so that the servers can send updates back to the trading computation.  In general, each interaction between peers can be mapped to a sequence of capability events.  COMET can be used to verify if the trading computation produced the expected events.  If COMET finds out that the expected sequence is not satisfied, it can notify software developers, helping them localize the fault.

Monitoring the execution of the trading computation in the broker system is essential for the ecosystem security and integrity.  The interaction between the trading computation and other computations can be anticipated; thus, unexpected patterns of behavior can be detected.  For example, if the trading computation issues a CURL different from the one that the trading firm should use to send commands, COMET can trigger an alert.  More generally, any unforeseen communication can be found and reported.

Taylor and his research group conjecture that, with enough information, even issues grounded in domain-specific business logic, such as spoofing in financial trading, could be mapped to capability events and analyzed using capability accounting.

For more information, contact Taylor and Giorgio. or visit: http://isr.uci.edu/content/coast-dynamic-secure-demand-services.

This is a slightly expanded version from that which was published in the Spring/Summer 2015 issue of the ISR Connector.

This work is currently supported by NSF grant # CNS-1449159 and by Bloomberg L.P.