IOTA Stronghold: Beta Release
Stronghold is an open-source software library that was originally built to protect IOTA Seeds, but can be used to protect any digital secret. It is a secure database for working with cryptography, which ensures that secrets (like private keys) are never revealed. It provides its own peer-to-peer communication layer, so that different apps can securely communicate using the state-of-the-art Noise Protocol over libp2p. Stronghold will form a secure base for the new IOTA Firefly wallet and will be integrated into IOTA Identity.
We dubbed this Beta release “Boden Fortress”, after the fortification in Northern Sweden set up to protect the country and its transport of the “coin of industry” - iron ore - during the world wars in the first half of the 20th Century. Its utility proven, it found use continuing throughout the Cold War. Like Stronghold’s Beta release is intended to be, the Boden Fortress was a temporary solution destined to be short lived and dismantled after it’s service period. That said, the Boden Fortress was in use for almost a hundred years. We are pretty sure that Stronghold’s Beta will be much, much shorter than that.
Today, three months after the Alpha release, we are happy to announce the Stronghold Beta. This version offers guarantees about the API, client logic and snapshot format - which will only change if security vulnerabilities are found. Being at this stage qualifies Stronghold for a full external audit, the completion of which will be a milestone that Stronghold needs to reach for the publication of its stable 1.0.
If you need a refresher about how Stronghold works, our resident Meme Lord Navin from the IOTA Foundation Board made a wonderful little diagram explaining what Strongholds will (and will not) do:
Generally speaking, most people won’t ever even need to know that they have a Stronghold. Its use should be invisible, much like how visitors to common websites don’t need to know which database is used on the backend. Of course, if websites were required to disclose how they were securing our user-data, then we might actually have greater faith in their ability to protect us.
Hopefully, at some point in the not so distant future, websites, apps and even operating systems will begin to recognize the strength and utility of approaches like IOTA Identity: where we control and secure our own data; where we decide what we share; where we choose with whom we share it; where we are empowered to revoke access when it suits us.
From a systems perspective, what we face today in software is that every application feels like it should be able to use any secrets it thinks it needs, and there are rarely strong guarantees that these applications protect the secrets properly. We want the industry in general to realize that this is a highly insecure practice, and the novel approach taken by Stronghold is not only obviously more secure, but an architectural pattern worth embracing. It’s really quite easy: you can’t leak secrets you don’t know about.
Shut up and take my money
It's never a good thing to be too confident, but at the same time we have to gain your trust by asking you to verify our faith in Stronghold. This is why, alongside the "Attack-a-thon", we are going to be running a Capture the Flag (CTF) challenge until Chrysalis (April 21st, 2021).
Somewhere, hidden in this blog page you can discover a flag (clue) that will help you to find a Stronghold Snapshot. This snapshot was created using the Stronghold CLI at git revision 93d1dfa12235f4c769a714a1cf39a4222b4ecc27. Once you find it, the rest of the CTF is 100% self-contained in that snapshot. In other words, there are no external resources available anywhere to help you, so really, do not waste your time trying to break into any other systems.
In the snapshot's store, there is a flag to prove you got inside. The vault, however, contains a current IOTA Mainnet seed in a secret vault/path that is another flag. This seed holds 3.78 GIOTA. At the time of this writing, that has a value of ~5000 USD. The only prize is the Seed.
If you find a flag, please visit the Stronghold Discussion at GitHub for instructions on being added to the leaderboard. Good luck.
Whats Next
Over the next several months, we will be preparing tutorials, examples, documentation and specifications as well as integrating with other IOTA Foundation projects. During this time, we will be enhancing the client with a flexible approach to Stronghold Procedural Cryptography, releasing a "version updater" for enabling the seamless upgrade of a snapshot to a new Stronghold version, and validating the communication system with a native desktop application. Finally, Stronghold will undergo a full audit and then will be marked as Stable.
Technical Notes About the Release
Stronghold is composed of a number of libraries that all work together. These libraries have been audited vertically in the context of an external audit of Firefly and reviewed by a number of IF Rust Engineers for quality and security. These have qualified it for beta release, however before we mark Stronghold as stable, there will be a future horizontal audit of the entire codebase.
What follows is a high-level description of each one, followed by its internal release status and a link to its changelog.
Client
The Client is the only interface to Stronghold that we can recommend using. It serves as an abstraction layer to the underlying engine and communication libraries, which guarantees that even if the internal codebase changes, your interface to Stronghold will continue to work.
Status: Beta
CHANGELOG
Vault
The vault is now write-and-use-but-never-read. This means that there is no method by which the client can ever read the secrets stored in the system, and provides solid assurance that Stronghold is as secure as possible. When a secret is retrieved from a record in the vault, it is passed to the runtime, which decrypts into an advanced memory allocator that guards the secret while in use. This is why we consider the vault to be “hardened”.
Status: Beta
CHANGELOG
Store
The store is a read-write key:value storage service that, while encrypted in the snapshot, does not enjoy the same memory protection used by the vault. This is because any data that can be returned to the client cannot be classified as “truly secret”. While it is encrypted at rest, it is not encrypted in memory and as such we classify it as “private and secure” but not “hardened”.
Status: Beta
CHANGELOG
Runtime
Perhaps the largest single change since the Alpha release is the new runtime, which is entirely based on libsodium-sys and guaranteed to work on all platforms. It still protects exposed secrets in memory using classical guard pages and canaries while cryptographic operations are being undertaken. Additionally, we now provide an internal Guarded Vector type, that allows Stronghold to protect records when in use and automatically zeroizes them.
Status: Beta
CHANGELOG
Snapshot
The snapshot crate serves to decrypt the persistence file and place the data in the vault and store. It also encrypts the vault & store to update the persistence file.
Status: Beta
CHANGELOG
Communication
The communication crate is using the libp2p system with the noise protocol, which enables permissioned use of remote strongholds for creating services like remote signing and multi-factor authorization. It is not in active use with Chrysalis, but will be used by the Wallet and Identity at a later date.
Status: Alpha
CHANGELOG
crypto.rs
While not an internal dependency of Stronghold, this library does provide cryptographic primitives for Stronghold (and any other IOTA libraries that need to use Cryptography).
Status: Beta
CHANGELOG
