Cryptographic File Storage scheme

Question

First of all,I am new to security as a whole and taking my first formal course on it.So sorry if any major errors are present. I had a scheme for remote file storage as an attempt to use my course topics:

• I have a few google accounts(say 2 = N) to which seperate firebase storage instances(2 again) are there
• within each instance there are a few folders(say 3 = M) each corresponding to a deployment service(heroku,pythonanywhere..).No cross folder access is permitted.
• Each deployed service(a total of N*M) has its own set of users and authentication implemented.
• All services have REST API's for read/write to their folders.
• On a local app on setup an master password is given and a key file is generated the master password is passed through an KDF(say to give masterkey) and then KDF(keyfile+masterkey) gives key encryption key(kek).
• A set of accounts for each storage bucket is created to 1 randomly chosen service per bucket and the accounts are registered with the service
• The data of all accounts is encrypted and stored locally by a database encryption key(dek) which is by itself encrypted by kek for storage.
• On a file to be uploaded it is broken down by (N,N) secret sharing scheme and N files are created which now is useless without all N being present.Each of this N files are uploaded to the buckets by the services mapped for this user.
• On a file read all N files are read and used. This might be overkill but I just wanted to use all schemes as a whole.Can somebody tell me if there are any critical vulnerabilities in this scheme?

Answer 1

Almost every question asking "is this secure?" will be met with another question: "secure against what?" and that's my question too. But I will infer the average attacker.

You defense must be built in such a way that an attacker that gets the encrypted file cannot do anything with it, and with a minimal amount of components to do so. Every new layer may marginally increase security, but can add vulnerabilities that can led attackers to easily get your data, or lock you out.

The critical step is this one:

The data of all accounts is encrypted and stored locally by a database encryption key(DEK) which is by itself encrypted by KEK for storage.

Anything else is superfluous from the security standpoint. Having data partitioned and distributed on multiple services is great for availability and vendor independence, because if any of your providers go offline (or go dark), you don't lose your data.

All your layers add little to the equation.

I have a few google accounts(say 2 = N) to which seperate firebase storage instances(2 again) are there

Phishing can deal with that, and the attacker will have access to the Google accounts.

Each deployed service(a total of N*M) has its own set of users and authentication implemented.

How is this implemented? Plaintext passwords? SHA1 and salt? Argon? And where the passwords are stored? When the database leaks, what is the consequences? Is the mapping transparent on the database? If data is encrypted, where is the key to decrypt? And if an attacker have database access, can he access the key? And how well protected against bruteforce is the authentication?

All services have REST API's for read/write to their folders.

How access to the API is managed? Are rate-limiting enabled? Soft-ban is employed if a client exceeds the rate?

On a local app on setup an master password is given and a key file is generated the master password is passed through an KDF(say to give masterkey) and then KDF(keyfile+masterkey) gives key encryption key(KEK).

And if the user loses this keyfile, how to proceed? He will lose everything, or there's a way to recover the keyfile? If there's a way, what stops an attacker from using this mechanism to create a keyfile for itself?

---

Having more pieces only makes your solution more difficult to understand and support, and can add hidden issues that will only become apparent when the service is being used and refactor isn't easy or even possible.