Capability-based security — enabling secure access control in the decentralized cloud

When the tech industry began the transition to cloud-based resource provisioning, the attack/security vectors in which DevOps and CISOs focus to protect their resources, shifted along with it.

Suddenly, protecting users’ data required a fundamentally new approach to containing resources. Rather than simply ‘defending the perimeter’ (through ownership of network infrastructure, firewalls, NICs etc.) the model shifted to an identity-based approach to control access to systems and resources.

This practice became known as Identity and Access Management (IAM), and defines the way that users authenticate, access data, and authorize operations in the cloud. This article will focus on the evolution of the IAM model, the trade-offs between various implementations, and the approach that the Storj V3 network has taken towards IAM and access control mechanisms on its decentralized cloud, which is a completely “trustless” environment.

When it comes to implementations of authorization and authentication on the web, the standard Public Cloud approach is through Access Control Lists (ACLs). However, the Capability-based approach leveraged by decentralized networks is definitively more secure, and I will explain why in this blog post.

Problems with todays’ ACL model.

The Access Control List model, which is sometimes referred to as the Ambient Authority Model, is based on the privileges of user identities (for example, through RBAC).

The ACL keeps a list of which users are allowed to execute which commands for every capability on an object, or file. This list of abilities is separated from identity which is associated to these abilities.

Generally, the appeal of ACLs arises from a notion of a singular “SuperAdmin” being able to list and fully control every user ́s account and privileges. This** centralized approach** to control creates a massive honeypot for hackers. When the SuperAdmin loses control, the entire system falls apart.

Because ACL model defines access through the identity of the user agent (or abstractions like roles, groups, service accounts etc.), each resource acquires its access control settings as the result of people making deliberate access configuration choices for it.

This is a major weakness of the approach, especially within todays’ massively parallel and distributed systems — where resources are accessed across different operating systems and data stores.

The weakness of the model can be illustrated through a few examples:

Problem 1: Ambient Authority Trap

Ambient authority describes a user privilege that is exercised, but is not knowingly selected by its agent.

The authority is “ambient” in the sense that it exists in a broadly visible environment (aka an Access Control List) where any subject can request it by name (and may or may not be denied).

Systems based on the ACL model often fall into the ambient authority trap where user roles are granted an array of permissions in such a way that the user does not know which permissions are being exercised.

In this security trap, agents are unable to determine the source or the number and types of permission that they have, as the list is held separately on the ACL. In general, if an agent cannot identify its privilege set, it cannot safely use an authority on another party’s behalf.

In the world of operating systems and distributed systems, avoiding ambient authority privilege escalation is crucial, especially when running untrusted code. This is why many systems implement FreeBSD jails like Capsicum and Linux Docker containers to sandbox software. Google is even working on a new capability-based operating system called Fuchsia to supercede the Linux Android kernel.

Problem 2: Delegate Problem

Also known as the Confused Deputy Problem, a deputy is a program that manages authorities coming from multiple sources. A confused deputy is a delegate that has been manipulated into wielding its authority inappropriately.

[Create an example outside of the compiler overwriting the billing system that is more fit for Storj, Decentralized Web, and modern day distributed systems]

Examples of the Confused Deputy Problem can be found across the web. These include injection attacks, cross-site request forgery, cross site scripting attacks, click-jacking etc. These attacks use the victim’s existing program logic to nefarious ends in web applications.

In order to avoid the Confused Deputy Problem, a subject must be careful to maintain the association between each authority and its intended purpose. This is wholly avoided by the Capability-based model described below.

What is Capability-based Security?

Capability-based Security is a fundamentally better approach to Identity and access management today’s ACL framework for creating secure Identity and Access Management system.

By tying access to key, rather than a centralized control system, Capability-based models push security to edge, decentralizing large attack vectors known as honeypots.

Often referred to as simply a ‘key,’ a capability is the single thing that both designates a resource and authorizes some kind of access to it. The capability is an unforgeable token of authority.

Those coming from the blockchain world will be very familiar with the capability-based security model, as it is the model implemented in Bitcoin where “your key is your money” and in Ethereum where “your key is gas for EVM computations”.

This illustrates the core tenet of the Capability Mindset: “don’t separate designation from authority.”

Capabilities make it very easy for developers to write code that granularly defines security privileges. Once baked, the rules within the capability cannot be changed, without changing the key itself. This enables developers to automatically Ambient Authority trap, as capability is bound to the object itself.

The importance of “privilege separation” holds especially true for trust-minimized decentralized systems, like the Tardigrade decentralized cloud storage service, which provides sophisticated tools for implementing access management to objects within an application (link to documentation).

Similar to how in the blockchain world, “your keys are your money,” with Tardigrade, “your keys *are *your data, and macaroons add additional capabilities that allow the owners of data to caveat it, or granularly delegate access for sharing, programatically.

Based on the state of cutting-edge security research, we think that this model is a fundamentally better approach than the access-control model used by web2 providers.

Key-based ownership of object data will enable users to intuitively control their data as a first principle, and delegate it as they see fit. The decentralized cloud eliminates the increasingly apparent risk of data loss/extortion due to holding data on one single provider (like Amazon, Google, or Microsoft). Storj, with its Tardigrade service, presents a better model where object data is encrypted, erasure-coded and spread across thousands of nodes stratified by reputation whereby any and every computer can be the cloud.

Macaroons are the key ingredient that enables object sharing in decentralized systems

Macaroons enable granular, programmatic authorization for resources in a decentralized way.

The construction of macaroons was first formulated by a group of Google engineers in 2014. These chained, nested HMAC constructions are a great example of the capability-based security model and are deeply integrated into the V3 Storj Network.

They are excellent for use in distributed systems, because they allow applications to enforce complex authorization constraints without requiring server-side modification, making it easy to coordinate between decentralized resource servers and the applications that use them.

Their name, “MAC-aroons”, derives from the HMAC process (hash-based message authentication code) by which they are constructed, while also implicitly alluding to a claim of superiority over the HTTP cookie.

In practice, HMACs are often used to simultaneously verify both the data integrity and the authentication* *of a message.

Similar to the blocks in a blockchain, HMACs are chained within a Macaroon (whereby each caveat contains a hash referring to the previous caveats), such that caveats which restrict capabilities can only be appended, and not removed.

In the Tardigrade Network, macaroons are referred to as API Keys, and enable users to granularly restrict and delegate access to object data in a way that is decentralized and more secure than existing cloud solutions.

Macaroons improve upon OAUTH2/OpenID connect

As illustrated earlier, today it is practically impossible for the owner of a private, sensitive image stored on one cloud service to email a URL to that image safely,given the possibility of impersonation through eaves-dropping(cookie theft).

A common attack on OAUTH2 authentication involves stealing a browser cookie from the client (via man-in-the-middle attacks, or otherwise), and spoofing the user’s browser session and IP address. Once executed, session hijacking in Oauth2 is rather difficult to revert. A great comprehensive overview of the current threat model associated with OAuth2 is discussed by IETF here.

Macaroons solve the cookie-theft problem associated with OAUTH2 and traditional cloud services by delegating access to a bearer token that can only be used in specific circumstances through HMAC chained ‘caveats’ (ie restrictions on IP, time-server parameters, and third- party auth discharges) whereby these caveats can be extended and chained, but not overwritten.

Given these security risks, macaroons are a better solution that builds on the OAuth2 standard because of their:

• Speed: HMACs are very fast and light-weight
• Timeliness: Can require fresh credentials and revocation checks on every request
• Flexibility: Contextual confinements, attenuation, delegation, and third-party caveats
• Adoptability: HMACs can run everywhere

Useful for Rate limiting and Billing Control

It is also worthwhile to note that macaroons are also a great tool for rate limiting in CDN-like use cases where you don’t want to run complex verification/authentication. You can easily program macaroons in a way to help cap billing usage by indirectly limiting bandwidth access per user etc.

Conclusion

Macaroons are a great example of capability-based security models in action, and Storj is a shining example of their implementation in decentralized cloud protocols.

One of the best ways to learn about capability-based models is to try them in action. In Storj, we refer to Macaroons as API Key