Securing data and files so as they won't be openable anywhere else but your own server?

Question

I know this question might seem a bit weird, but I believe there should be a way, at least to reduce the ability to download or use script to download files from storage. I tried a lot but found nothing useful.

Consider that you have a storage server containing thousands of millions of files and data, how can you make them openable only from that server and un-openable from any other machine?

I know it's not possible to fully avoid attackers, so after securing all servers I thought by myself if it could be possible to make data more secure than what they are at the moment. So even if someone could hack servers, won't be able to carry your data anywhere since the file will be nothing but a broken stuff from that time on.

Maybe my question is not 100% right, so I'm completely open to any suggestion and edit for my question. The only thing I need, is to secure my data in a way that no one can use them outside of my server.

Answer 1

Why do you believe there should be a way? If an attacker can hack your server, they can presumably look at the data on that server - from that point, they could copy the plain data to anywhere else. We know the data must be plain at that point, since your server needs to be able to read it, and you need to be able to access the files (else it's a bit of a black hole). You could encrypt files in such a way that only your specific server can decrypt them - you could even use a hardware security module to make exporting the keys more difficult - but since they have to be decrypted for use, an attacker could simply take a copy at that point.

Think of it as being like a painting - you can protect the painting itself relatively easily, by locking it in a safe, but as soon as you want to display it, anyone can wander in with a camera and make a copy. For paintings, that's less of an issue - you can easily tell when a copy has been made. For digital data, there isn't any difference between the original and the copy, so whatever you can do with the original, you can do equally well with the copy.

Answer 2

This is not possible. Think about that: How is your server different from any same server bought? It might have some different serial numbers in some parts, but apart from that, it's the same.

You can encrypt the data with a key only stored on that server. But if the key is stored on the filesystem, a attacker can copy it!

There are hardware devices which securely store a key and don't allow it to be exported. They are usually called hardware security modules. If you encrypt all data with keys only stored on the HSM, the files can only be decrypted by someone with access to that HSM!

But note: if a attacker has access to your server, nothing prevents him from decrypting all files with the HSM and copy the decrypted files.

Also, obviously anyone who can access a decrypted file can then copy that file without restrictions.

So to sum up what you can do is buy a HSM, encrypt all files with that HSM and only store them encrypted. To prevent someone from stealing all your files, you need to implement warnings when too much crypto operations take place. (If on normal usage, one file per second is decrypted, when suddenly hundreds of files are decrypted, something is wrong). Still, a attacker can steal decrypted files if he has unlimited access to the server. It just makes it harder!

Answer 3

The best approach is the other way round: make it so that the server that stores the files is unable to read them, by encrypting them with keys held elsewhere.

Consider a system comprising a laptop, a smartcard, and the server. The keys are held on the card. A user requests the document from the server, and is given the encrypted copy. The laptop passes it to the smartcard for decryption, and then displays it on the screen.

Compromising the server is useless: it can't read the documents.

Compromising the laptop gets you any documents decrypted on it while it's compromised, but not all the documents.

Compromising the smartcard would get you all documents with the relevant keys, but these devices can be extremely attack-resistant.

The state of the art in secure end-user devices for the ordinary user is the iPhone, with its "TrustZone" components functioning as a HSM. Probably the next best most practical device is a Win10 system using BitLocker full disk encryption with a HSM storing the keys. You have to input the password at boot, and it's still potentially vulnerable to real-time attacks, but if the system is stolen while off the disk contents cannot be read without the password.

Answer 4

There is kind of a fundamental issue in that you're trying to do: You will need to decrypt the data. At this point it is decrypted and can be leaked. You can use full-disk encryption, even combine it with something like QubesOS to separate processes. This will prevent software from stealing the data, then your main issue is physical access. But there will always be a moment where the data lives unencrypted and can be stolen.

Every general implementation of crypto has this property and it can't be fixed easily.

Answer 5

Just to be different from the other answers, I'll point out a case where this is possible: private keys.

What makes private keys a special case is that A) the applications on the server never need to access the key directly, a secure device can hold the key, do any processing on it, and return the result, and B) the data is small enough (say < 1 kb) that you can spend large amounts of CPU time obfuscating it in memory.

HSMs: Sometimes private keys are stored on highly secure hardware devices designed for this purpose: HSMs, smart cards, TPMs, Secure Enclave, etc. The idea is that the server will never see the private key because when it needs to sign / encrypt something it sends the data to the HSM and gets back the signed / encrypted data.

Obfuscation in memory: if the key needs to be stored in software on the server then you're not entirely sunk; well-written applications can decrypt the key file and then obfuscate the key in memory so that even if an attacker gets a memory dump of the application, it's hard (but not impossible) to extract the key. Obfuscation tricks include: splitting up the key into 4 chunks and spreading them over the app's memory space, getting a random number or initialized memory and using that as a key to encrypt the chunks. These tricks require: A) that your applications are written with this in mind, and B) the data to be obfuscated is very small relative to the memory space of the app (say < 1 kb).

From your description it seems like your use-case none of this applies because the applications need access to the data, and the data is fairly large. You're probably wasting your time here, instead you should spend your time securing your server against remote logins / code execution vulnerabilities.