I’m new to Storj but convinced that end-to-end encryption is the way to go. I need help with interpreting some of Storj’s functionality.
I am building an app that will store user created videos from their mobile apps, which will be end-to-end encrypted, on Storj.
My understanding is that for a mobile app to be able to store data, it needs to use an API Key to request an Access Grant from a satellite. The user will provide a passphrase for that.
I tested and concluded that Access Tokens will grant access to files, regardless of what API Key was used to issue those Access Tokens.
Specifically, two different mobile apps, using different API Keys to request for Access Grants, would enable users to see each other’s files if they accidentally chose the same passphrase, when requesting for the Access Token.
The mobile app can enforce complexity criteria for passphrases, sure. I want however to clarify with the team here that I am reading the situation accurately i.e. As long as the passphrase is the same, and the Access Grant happens to provide access to the same bucket, users can see each other’s data.
You should probably create an access grant for each user using their passphrase and include caveats to only allow access to user specific paths. That way you create user separation with more than just the passphrase. Access Restrictions - Storj DCS Docs
You may also consider using some password based key derivation function to ensure long encryption keys, even if the user chose some weaker shorter password. It’s hard to convince end users to do it right. This would at least add some additional security against brute force by adding a computational cost to each attempt.
An API Key is the credential the Satellite needs to authorize a request. This can be restricted in a variety of ways.
An Access Grant is a client-side only serialized envelope that contains an API Key and encryption keys for what the API Key allows for. The access grant actually keeps what’s called an “encryption store” which is a serialized database of mappings of path prefixes to derived encryption key roots. This allows you to restrict an access grant to a specific bucket or path without leaking encryption details to other buckets or paths.
An Access Key is used specifically for our edge services. It is the encryption key for an encrypted Access Grant that our edge services store.
Bummer that Storj has all three, cause that’s a bit confusing. But anyway.
Since you’re building an end to end encrypted app, you’ll mostly want to concern yourself with Access Grants. Access Grants can be created by combining an API Key with a root Encryption Passphrase and a project salt (see RequestAccessWithPassphrase), or just in the web interface, which uses a web assembly Javascript client for calling that method I linked.
Once you have an Access Grant, you can restrict it to just a specific bucket or even to a specific object path prefix. In your case, it sounds like you may want to have a server-side application generate a per-customer AccessGrant that is restricted to a portion of a bucket with a customer specific prefix. Specifically, maybe for customer 1234 you restrict an access grant to customer-data/customer/1234/.
Once you have this restricted Access Grant, of course you want the user to choose their own key - this is where you would have them use OverrideEncryptionKey on the client side, which allows you to specify the encryption information for just a subtree of your project. This allows them to interact with their portion of your bucket in a way that allows for them to keep their keys.
This will allow for each customer to have their own keys and not be able to see someone else’s data, even if they use the same passphrase, since the real encryption keys are derived based not just on the passphrase, but on the salt and path derivation.
From a logistics perspective, you’ll probably want to keep in mind that the uplink cli has some utilities for helping manage encrypted data, such as uplink ls --recursive --encrypted and uplink rm --encrypted --recursive
why not make account per client, it will give you opportunity to hold eggs separately, also give client some free tier, that will help promote your app and give client to try by free some amount.