In our Let’s Talk Storj DCS Webinar Series and a number of blog posts, we talk a lot about how we provide the technology and tools to help developers build more secure and private applications and that those tools were a byproduct of the work required to make our decentralized network secure in the first place. In this post, we’re going to dig into that security layer and talk about zero trust in the context of decentralized services.
The concept of Zero Trust has been in the news a lot based on significant recent cybersecurity events like the SolarWinds attack, as well as President Biden’s Executive Order on Improving the Nation’s Cybersecurity earlier this year. In this executive order, President Biden specifically calls on government agencies to adopt zero trust architectures as one way to combat “sophisticated malicious cyber campaigns that threaten the public sector, the private sector, and ultimately the American people’s security and privacy.”
What is Zero Trust?
Let’s talk about what Zero Trust is and isn’t. Zero trust is a strategic cybersecurity model designed to protect technology environments, which increasingly include public and private clouds, SaaS applications, and other distributed resources.
Zero trust is based on the thesis that every person or system attempting to reach a protected resource has been compromised and thus can’t be trusted. The point of zero trust is to mitigate the risk and blast radius of cyber attacks.
Zero trust solutions are mainly focused on implementing strong network perimeter defense combined with Identity and Access Management (IAM) working from the assumption that a user’s system has been compromised. The typical approach is a castle and moat system using a VPC (Virtual Private Cloud) - once you're across the moat, you're in the castle although it’s becoming more nuanced.
Zero Trust is becoming increasingly relevant
The evolution of cloud resources has driven development of zero trust technology, as on-premise networks have evolved to include cloud-hosted infrastructure, as well as IaaS, PaaS and SaaS resources. A number of recent trends are making it increasingly relevant.
Consumers have become much more interested in the privacy and security of their data in the wake of massive data aggregation by some of the world's largest companies as well as a significant amount of high-profile data breaches. A complex web of regulatory frameworks has evolved to address these consumer privacy concerns. Companies are adapting to an evolving post-pandemic world with rapid expansions in cybersecurity threat surfaces due to a rapid expansion of remote workforces. Finally, driven in part as a reaction to privacy and security concerns, is the rise of decentralized systems.
Decentralized Systems and Zero Trust
While the concept of Zero Trust traditionally means resources are protected based on the assumption that every user is compromised but your own resources are secure, decentralized architectures must assume that even the third-party infrastructure providing the resource is compromised.
Decentralized systems have to be architected in such a way that failures can occur without giving attackers unauthorized access to data or bringing down the entire system or service altogether, whether they are end-users of the software or providers of decentralized infrastructure.
Depending on the function and relationship between peer classes in a decentralized system, there may be implicit or explicit limited trust boundaries. In the Storj network, Uplink clients trust Satellites to safely store metadata and automatically repair data as nodes fail or leave the network. Uplink clients may choose to trust a Satellite when using server-side encryption with the hosted gateway or use end-to-end encryption to fully eliminate that element of trust, by running a self hosted gateway or using one of the other client tools.
Storj operates multiple Satellites in multiple geographies. Within each geography, each Satellite is operated as a distributed service across multiple regions. Trust between an Uplink client and a Satellite is truly a matter of convenience. While it is feasible to operate a Satellite and Uplink client to eliminate that element of trust, the trade-offs in terms of cost, complexity and effort in general outweigh any benefit. When it comes to anonymity of Storage Nodes however, that’s where zero trust is most important.
Anonymous Infrastructure
When anyone can download the software from an open-source repository, modify the code and provide resources to a decentralized service, that software has to eliminate trust from the equation. In any decentralized system, there is always the possibility that one or more of the participants in the network could be operating a system that has been compromised, is misconfigured, or is otherwise likely to fail.
Frequently, decentralized systems use the Byzantine, Altruistic, Rational (BAR) model as a useful rubric to describe the participants in a decentralized system.
- Byzantine - Nodes will actively try to disrupt the network
- Altruistic - Nodes that will behave in the way most healthy for the network, regardless of the outcome or reward
- Rational - Nodes that will optimize behavior for the highest possible reward
The key takeaway is that you can count on having some byzantine nodes, no altruistic nodes and a majority of rational nodes, but it’s impossible to tell the difference between them. Decentralized systems have incentive structures and technical enforcement points to ensure the rational behavior is the same as the altruistic behavior that identifies and defends against byzantine behavior. A significant part of the technical enforcement ensures that transactions on decentralized systems are private and secure through the use of strong encryption and zero knowledge architecture.
Security and Privacy at the Protocol Level
In the case of Storj, for example, Storage Nodes only store small pieces of encrypted files and never have access to the entire file, the metadata associated with a file, or the access credential or encryption keys associated with the file. No Storage Node has access to the data, the protocol enforces that security and privacy, and there is no trust required for Storage Nodes - the security, privacy, and durability of data are all a function of the Storj protocol.
The Storj protocol is an abstraction layer between an object storage interface and a decentralized storage infrastructure with all of the security and privacy protections built into it. The Storj protocol is a uniform set of rules for formatting and processing data for transmission between a standard object storage format for consumption by applications and an encrypted and distributed format for the secure and private maintenance, storage and retrieval of metadata and object data via a distributed collection of decentralized components provided by the peer classes comprising the Storj network.
What this means for decentralized services
The Storj protocol dictates how data moves through the network and establishes trust boundaries that ensure data is secure, private, durable and available to the applications storing data on the object storage service, and at the same time is opaque and unassailable by operators of the decentralized infrastructure on which that data is stored.
The underlying technology components of the zero trust architecture such as strong encryption, erasure-coded and distributed storage and edge-based delegated authentication ultimately provide continuous and dynamic validation of resource availability and authorization verification. The tools that enable the network to function without trust, for a secure, performant and highly available storage service also enable developers to build greater security and privacy into their applications.
