1

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!

Improve this question
3
  • encrypt before it goes out over the internet. safer, more flexible, and 100% secure w/ or w/o SSL
    – dandavis
    Feb 9, 2018 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, 2018 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
    Feb 11, 2018 at 2:08

2 Answers 2

Reset to default
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

Improve this answer
3
  • 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
    Feb 11, 2018 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.
    – aPugLife
    Feb 13, 2018 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
    Feb 20, 2018 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

Improve this answer
5
  • 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, 2018 at 7:52
  • lol I am not a promoter nor a employee of veracrypt. I thought that might help you.
    – Ankit Devnalkar
    Feb 9, 2018 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, 2018 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, 2018 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
    Feb 11, 2018 at 2:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .