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.

  • Do you actually need to download and serve the files, or do you only use the files to do some computation and merely return the result of it? In the second case you can keep the files on a separate, hardened machine that only talks to your server (preferably through something non-IP like a serial port) with some software that interpret the requests from your main server, does the computations and returns the result without ever revealing the sensitive data. – André Borie Nov 7 '16 at 12:45
  • 2
    Possible duplicate of Refuse download request, but allow use online – suriv Nov 7 '16 at 13:59

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.

  • I meant maybe changing some kernel stuff, isn't it possible? If it's not so, how can I make sure my data and files won't be downloaded by anyone (easily)? It's not important if someone capture a video or record a sound that I have on my site, the only thing that I care about is that the file won't be stolen. Any idea? – Parsa Samet Nov 7 '16 at 11:08
  • BTW, shall I ask you to explain a bit more about the part that you said "You could encrypt files in such a way that only your specific server can decrypt them" ? – Parsa Samet Nov 7 '16 at 11:09
  • 2
    @ParsaX no, it is not possible! – Josef Nov 7 '16 at 11:18
  • 2
    @ParsaX No, you can modify the kernel, but the best you could do is have software which only runs on a specific machine, due to checking for specific hardware which is only attached to that (this is called a dongle). If your server can read the files, so can anyone else who gains access to your server. For files at rest (when the server is turned off), you can have encryption to prevent access, but they would be decrypted when the server needed to use them, else it wouldn't be much use. Doesn't matter what type of files they are - if the server can decrypt them, so can attacker on server. – Matthew Nov 7 '16 at 11:29

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!

  • Myriad thanks mate. So I guess I have to think of hardware security modules plus encryption. – Parsa Samet Nov 7 '16 at 11:17
  • 1
    HSM encryption is the right answer, and you can potentially limit the HSM to requiring specific keys or hardware tokens to do decryption. – pjc50 Nov 7 '16 at 13:35
  • Not sure whether this is available out of the box, but I suppose that it should be possible to not only send a warning if normal use tresholds are exceeded, but also to stop/bottleneck any transactions untill the HSM receives an 'all clear' via a manually entered password.-- With proper monitoring this might prevent you from letting people steal more than 1% of your data at once (assuming they don't take over the HSM). – Dennis Jaheruddin Nov 7 '16 at 16:13

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.


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.

  • So is there any idea or scenario that I can have to keep my files safe as long as no one has physical access? What if someone can sniff and find out where my files are kept? To keep it simple, how is IDM downloading most of things and how can we stop it? – Parsa Samet Nov 7 '16 at 11:16
  • The only way to get the files if you have FDE is to infect the computer and read out the RAM. If you can prevent that, only physical access would work. As i said, sandboxing is great for this. – J.A.K. Nov 7 '16 at 11:21
  • 2
    @ParsaX at first, you should define exactly what the scope of your protection is. Who is the attacker? What can he do? What can he not do? etc. Then you can find possible solutions protecting in specific scenarios. Then you estimate the costs. Then you decide what makes sense. If your scenario is: Attacker can get full access to the server you can't prevent that and the economic solution is don't do anything, because everything you do will cost but won't increase the security. – Josef Nov 7 '16 at 11:53
  • 1
    So let's say just keeping data safe from being downloaded and stolen by any tools like IDM, as long as there is no physical access. – Parsa Samet Nov 7 '16 at 12:16
  • 1
    @ParsaX you should open a new question for that. Also, I don't know what IDM means. And by "full access" I also didn't mean physical access, just root/Admin access to the OS. – Josef Nov 7 '16 at 12:42

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.