0

I am looking for ideas today.

The problem: Sensitive files are sent via REST (over SSL, of course) to a third-party server. I cannot touch them programmatically until they arrive at the server. Those files are stored there until users download them via SFTP and delete them from the server. Each file will reside for about a week on this server.

The goal: Secure the files at every step until they are on the users' machines.

My plan: Because I cannot encrypt the files until they arrive at the third-party server, my only hope for security is a SSL connection. I would like to ensure only my files are saved on the server, so I am thinking I should send a password along with the files. What is better than a static password? I would like to use unique passwords, but I'm not sure where to start.

As a file is downloaded onto the server, I will copy the stream into temporary memory and encrypt the data with RSA. I can keep the private key on the users' machines and store only the public key on the server. (Note the server has no hardware encryption.) When a user connects via SFTP, he can download the encrypted file and only decrypt it on his own machine once he is offline. Is there a better way to keep files until a user can access them?

Any other suggestions would be greatly appreciated!

Update After tinkering and reflecting, I have found this solution to be the most fitting given my limited control over the starting server: https://stackoverflow.com/a/19758235/1008395

In summary, send the files from A to B via SSL. Use AES-256 encryption with a randomly generated key when the file arrives at B. Encrypt that random key with RSA 2048 (the public key). Save everything on the server until it can be downloaded. Once the files are on the users' machine, decrypt the random key with RSA's private key (stored only offline) and then use that key to decrypt the AES encryption on the file. The reason for the hybrid Symmetric/Asymmetric encryption is because I want the public-private key format but RSA limits the size of the data to 256 bits (for 2048; it is only 128 bits for 1024). So we encrypt the data and key separately then send both. Yes, this results in 3 keys: One randomly generated each time, one public key, and one private key (which never sees the light of the internet).

Nihvel nailed this with even more security by encrypting the file before sending and saving the encrypted random key on Server A. Thus the two were never on the same server. Thanks for all your help!

  • encrypt before it goes out over the internet. safer, more flexible, and 100% secure w/ or w/o SSL – dandavis Feb 9 '18 at 7:09
  • Best idea was to encrypt the file before sending with the private key of your's. But as you said that you have no control until file arrives at your server. so, A storage can support encryption(like bitlocker, for windows; dm-crypt for linux). And file is being writing at server using a user. You should secure the user as much as possible, directory and system also. You need to do server hardening too. – again Feb 9 '18 at 8:24
  • ahh I would love to strengthen security on the servers. Unfortunately I own neither. I can really only control the file and, to a limited extent, the users. – Zachary Terlizzese Feb 11 '18 at 2:08
1

I'm doing the exact same thing already but the contest of my encryption is different. I will give you my view.

You have server A. The third party service host Server B. User(n) is user[n].

You will create a random key, with this, you will encrypt your file X.
You will encrypt the random key with your public-key.
You will create a HASH that links the encrypted file with the random-key.
You will send only the encrypted file X from A to B using HTTPS (use a second certificate, of course).

B will store your encrypted until the user[n] will download it with the HASH file.
User[n] will reach your server A through a webgui (why not), after a login(why not..) and after he uploads the HASH file, your system can decrypt the file and let the user download it.

No one will know your private-key, of course, and no one will be given the public key file.
Even if they will, you will store in A the random key you used to encrypt the file.

This pretty much sums up my idea, and 80% of it is applied in my environment (the 20% rest is other checks).

Sure there is some work to do, but not even so much. I built this in 1 day and I'm not even that good at it.

EDIT: I recently finished my script for backing up and encrypting a postgresql database. Here you will find everything you need but creating the HASH. At least the part of encryption/decryption is what you may want. https://github.com/Nihvel/Backup-Scripts/blob/master/postgresql_database_backup

  • Thank you for your well thought out answer! Unfortunately I literally cannot store anything on server. A. I can however create keys on the server via JavaScript and have them sent to different recipient servers. What do you think about that? – Zachary Terlizzese Feb 11 '18 at 2:18
  • I would personally not use Javascript, I would let some background app do the job and return the result to the front-end. Like, I would call a bash script from php's exec(), using the 2' argument of exec to return the data -> exec("/path/script.sh", $output) and basically you can do with $output everything you want. – Nihvel Feb 13 '18 at 8:19
  • I understand. I say JavaScript because that is what the application sending the file uses (It is Plum Fuse). Normally I agree, encrypting from the client-machine is too exposed. This answer is very good. I am going to update the question with a similar answer that I found which worked better for my limitations (no control over server A conditions). – Zachary Terlizzese Feb 20 '18 at 16:49
-3

You can use a opensource software Veracrypt to perform all encryption related operations. Veracrypt is available for both command-line and gui. Also, in Veracrypt you can use a particular file for authentication rather then using a password.

https://archive.codeplex.com/?p=veracrypt

  • 1
    I think you mean to say that you could use an encryption program to encrypt the files before sending. Veracrypt is one such option. There are many others. The way you wrote this, it sounds like an ad for Veracrypt and you do not connect this tool to a way to solve the problem in the question. – schroeder Feb 9 '18 at 7:52
  • lol I am not a promoter nor a employee of veracrypt. I thought that might help you. – Ankit Devnalkar Feb 9 '18 at 8:44
  • 2
    But you have not connected this specific tool to the problem in the question. Can you do that and maybe mention other tools that might also work (like gpgp) – schroeder Feb 9 '18 at 9:28
  • 1
    Veracrypt in fact would be a very bad solution. It uses XTS mode for crypto, which leaks a huge amount of information when used for encrypted snapshots over an attacker-controlled medium. – forest Feb 9 '18 at 14:01
  • I appreciate your input but I would like to avoid any additional software. The fewer unknowns in this process, the better! – Zachary Terlizzese Feb 11 '18 at 2:20

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.