How does Storm4 work ?
Storm4 is a new cloud storage app. It can be described as a “secure Dropbox”. It’s differentiating features are:
- Pay-as-you-go pricing model
- Zero-knowledge encryption (in the cloud)
- Local encryption (on your disk)
Due to it’s encryption/privacy focus, it’s targeting a niche market of the cloud storage industry. Direct competitors would be apps like Spider Oak or Tresorit.
In this article I’m going to discuss the technical details behind Storm4’s encryption system.
Public key system
When a user creates a new Storm4 account, they create a public/private key pair. (ECC curve 41417) This key is generated on the user’s own device, and then the public key is uploaded to the server. As an example, here’s my public key.
The private keys are private. The server does NOT know the private key. Only the user has this information.
Identity system
A public key, in and of itself, doesn’t do anything to identify a user. There are pros & cons of this, as exemplified by Bitcoin. In the cryptocurrency world, most people like the idea of accounts that aren’t inherently tied to a real-world identity. But at the same time, they expect P2P payments to be as easy as Square Cash. Which requires the ability to search for people. Which requires the ability to link a public key to a real-world identity…
The successful solutions for this have mostly been a hybrid model:
- (default) privacy for those who need it
- (opt-in) searchability for those who want it
Storm4 follows suit here. To accomplish this, the system allows you to optionally link social identities to your account. A dozen or so identity providers are supported, including:
- Microsoft
- GitHub
- and more…
You can link multiple social identities to your Storm4 account. And a particular social identity (i.e. my GitHub account) can only be linked to a single Storm4 account. So if I created multiple Storm4 accounts, I’d only be able to link my GitHub account to one of them. (The app does support using multiple accounts simultaneously.)
Once linked, your account is searchable via that identity. Which means other users can search for your account using the social identities that they’re already familiar with. For example, if colleagues are familiar with your LinkedIn account, then they can search for your LinkedIn name. And search results will display your LinkedIn name & avatar. This makes sharing & collaboration rather easy.
The identity system is built on top of OpenID Connect. This is often confused with other systems (such as OAuth), so an overly simplified example is instructive.
OpenID Connect works something like this:
- Storm4 sends you to the login page of the provider (e.g. Google’s Login page)
- you login to Google (using Google’s own login system)
- after you login Google sends Storm4 a “signed document” that essentially says:
“I, Google, hereby declare that the user is ‘johndoe@gmail.com’. I certify this information with my signature, which is …”
The signature is checked to ensure it was actually signed by Google. And then the system can trust that you are, indeed, ‘johndoe@gmail.com’. What OpenID Connect does NOT do is give companies a token that allows them to read your email. Or post evil tweets on your behalf. Or spam your Facebook wall. Or any other such shenanigans.
Of course, you don’t have to link a social identity to your account. You can also go the traditional route, and simply create a username/password directly with Storm4. If you’re looking to remain anonymous, this would probably be the easiest way to go.
2-Factor Authentication
It seems like everybody is implementing 2FA these days. And for good reason. The idea behind 2FA is to require the user to confirm their claimed identity using a combination of 2 different factors:
- something they know
- something they have
- something they are
From a security perspective this is great, because it makes it much more difficult for somebody to impersonate you. However it doesn’t do anything to protect your data. For example, Google can implement 2FA until they’re blue in the face, but that’s not going to stop them from reading all your data. (Their business model depends on it.) This means your data could leak due to the business itself, hackers or over-reaching government organizations.
Fun story: I met a guy in San Francisco who described himself as a “social hacker”. His day job was to infiltrate the IT of various organizations. He often accomplished this by, as he described it: “find employees who aren’t happy, and hand them an envelope full of cash. Or find employees who are happy, and hand them an even thicker envelope.”
Storm4 also implements 2FA, but it’s done using your public/private key pair. Here’s how it works:
- First you have to login using one of your linked accounts (e.g. Facebook, Twitter, etc) (This may itself implement 2FA !)
- Then your private key is required to actually decrypt your data
So it requires something you know (your login info for a linked identity), and something you have (your private key). The interesting twist here is that the “something you have” component is not “something the server also has”. Contrast this with SMS-based 2FA and you’ll see what I’m getting at here.
Blockchain verification
There’s an age-old problem with public-key infrastructure systems. And Storm4 solves this dilemma using the Ethereum blockchain.
The man-in-the-middle problem, in brief:
Alice & Bob have both created Storm4 accounts, and have uploaded their public key to the server. Now Alice wants to send a file to Bob. But she doesn’t have Bob’s public key. She can easily download it from the server. But how can Alice be sure that the public key hasn’t been tampered with?
For example, what if a “man-in-the-middle” has hacked the Storm4 servers, and replaced Bob’s public key with his own public key. If this happened, then Alice would get the hackers public key. And the file she uploads would then be readable by the hacker.
To address this issue Storm4 has a created a smart contract (fancy word for code) and deployed it to the Ethereum blockchain. Due to the nature of Ethereum, the contract is immutable. And you can read the code here.
The general idea is to write a smart contract such that the public key for any particular userID can be set once, and only once.
In pseudocode:
if (users[userID] == null) {
users[userID] = publicKeyInfo // <= can only be set once !
}So the smart contract ensures the public key info for a user can only be set once, and Ethereum ensures the smart contract itself cannot be modified. On top of that, the smart contract can be queried by anybody via any Ethereum node in the world. In other words, third-party verification via a decentralized system. Thus any kind of public key tampering would be easily detectable.
So Alice can fetch Bob’s public key from the Storm4 servers. And then she can query any ethereum blockchain node in the world in order to verify the public key hasn’t been tampered with.
File encryption
Zero-knowledge encryption means the server cannot read the content of the files that you store in the cloud. (It has “zero knowledge”…)
In Storm4, every file that gets uploaded to the server is first encrypted on the local device. (e.g. encrypted on your phone before going up to the cloud) Each file has a randomly generated 512-bit key. And the key is then used to encrypt the file using Threefish. So every file is encrypted with a different random key.
The encrypted file is uploaded. And the file’s encryption key is “wrapped” using the user’s public key before being uploaded. That is, the file’s encryption key itself gets encrypted using the user’s public key. In other words:
- you cannot decrypt the file without the encryption key
- you cannot decrypt the encryption key without the user’s private key
Thus only the user’s devices (which have the user’s private key) will be able to decrypt & read the file.
In addition to encrypting the contents of the file, the metadata is also encrypted. This includes the filename & all path components.
Sync across multiple devices
There are a lot of secure backup solutions that work similarly to this. (Without the cool blockchain stuff, or the identity linking, etc.) But backup != sync. There’s a LOT more tech required to make a sync system.
For the purposes of this discussion, however, we’re only interested in how the private key gets transferred from one device to another. (Recall that the server doesn’t know the private key.)
So say I’m logged into Storm4 on my macOS device. And now I want to login to the same account on my phone. First I need to login using one of my linked identities. (e.g. GitHub) Next the app will prompt me for the private key. And the app supports 2 solutions to transfer the private key between devices.
The first option is the easiest, in my opinion: QR Code. On my mac I can bring up a QR Code for my account, scan it with my phone, and boom I’m in.
The second option isn’t too bad either: a word list using mnemonics. In fact, it’s using the official Bitcoin mnemonic spec. Although slower for transferring between devices, the word list is probably easier to backup. (i.e. easier to store in something like a password manager.) It also makes it possible to backup your key using Cryptosteel !
Sharing & Collaboration
Now we have all the technical information we need to understand how sharing works. Say Alice wants to share a file with Bob. Here’s how that would work:
- Alice generates a random encryption key, and encrypts the file
- Then she wraps the encryption key using her own public key (requires Alice’s private key to decrypt)
- Then she fetches Bob’s public key
- Then she uses an Ethereum node to verify Bob’s public key
- Then she wraps the encryption key to Bob’s public key (requires Bob’s private key to decrypt)
- Then she uploads the encrypted blobs
Here’s the actual structure used by the app:
{
"version": 3,
"fileID": "E5C743215F68409A9BA7721CA3F46422"
"metadata": "<encrypted filename & metadata goes here>",
"keys": {
"UID:<alice's userID>": {
"perms": "rws",
"key": "<file encryption key, encrypted to alice's public key>"
},
"UID:<bob's userID>": {
"perms": "r",
"key": "<file encryption key, encrypted to bob's public key>"
}
}
}Notice it has the required information for both Alice & Bob. So either one of them will be able to decrypt the encryption key, and then decrypt the file. (And since every file is encrypted with a different key, this only shares a single file.)
Local Encryption
So far we’ve only discussed how data is encrypted in the cloud. But Storm4 also encrypts the files on your local device. This is somewhat unique to the space, and has some interesting benefits that I’ll explain shortly.
On macOS, Storm4 uses FUSE (filesystem in userspace) to present your files. So instead of having a “Storm4” directory in your home folder (à la Dropbox), you instead get a Storm4 volume. A “volume” is something you can mount/unmount, so conceptually similar to a USB stick.
However the volume is virtual, and the files themselves are still stored on your machine. In fact, you can find them here:
- ~/Library/Application Support/com.4th-a.storm4/Offline/ac
However, all the files in this directory:
- have random filenames (a UUID scheme)
- and are encrypted using different random keys (Threefish 512)
So if you unmount your Storm4 volume, all your files “disappear”. That is, the files are still technically on your hard drive. But when your Storm4 volume is unmounted, one cannot read any of the files, nor even discover the filenames.
The app makes it easy to mount & unmount your volume. And you can do the expected security/privacy stuff such as adding password protection in order to mount the volume. However, even better than that (in my opinion) is the ability to add password protection at the folder level. Here’s a demo.
A brief note on backend architecture
Storm4 runs on AWS. In fact every user account gets their own individual S3 bucket. And all your files are mapped to an S3 path using an encrypted filename scheme. (i.e. filenames & filepath components are encrypted to maintain “zero knowledge”.) Files are automatically migrated from “hot” storage to “infrequent access” and to “glacier” based on how often you access them. And you pay less for these tiers.
The backend is 100% serverless, and makes heavy use of AWS Lambda and the serverless deployment system. The stack can be deployed to any AWS region in the world, although currently it’s only deployed to 2 regions:
- us-west-2 (Oregon)
- eu-west-1 (Ireland)
(These happen to be regions with the cheapest S3 pricing.)
A brief note on pricing
Storm4 is the only consumer app (that I know of) to use a pay-as-you-go pricing system. There is no minimum fee — so if you don’t store anything you aren’t charged anything. And there’s no maximum storage amount — so you don’t have to worry about quotas, thank god. And the current offer is a free $10 credit if you sign up. Which, depending on your usage, could last several years.
