0

We are trying to encrypt files in a manner that they can be completely secure in an insecure environment (like a public cloud). We're talking about military grade secure.

The data should be so secure in the public cloud, that the employees cannot access the files (insider threat) and no MitM can access the file.

Our initial idea was to make a VPN (OpenVPN) tunnel between the customer and the public cloud and encrypt the files exchanged using PGP (GnuPG).

Is this secure enough for this use case? We are dealing with PII.

P.S. is it possible to somehow split out trust for the private key on multiple servers on multiple split files on multiple cloud providers?

kenlukas
  • 835
  • 6
  • 18
Munchkin
  • 212
  • 2
  • 10
  • 2
    Military grade security is incompatible with a public cloud infrastructure. – A. Hersean Apr 25 '22 at 12:25
  • The VPN and GPG usages you describe only protects data in transit on the public network. How do you plan to protect the stored data? – A. Hersean Apr 25 '22 at 12:27
  • Also, this might be a XY problem. What are your trying to achieve? Why do you need to use a public environment? – A. Hersean Apr 25 '22 at 12:30
  • @A.Hersean the stored data should be secured using PGP if that's possible. We want to achieve a secure communication of PII from the customer to our infrastructure. We want to use public cloud due to the fact that it supposedly uses higher security standards and we're not able to achieve these standards ourselves (high physical security etc) – Munchkin Apr 25 '22 at 12:33
  • "high security standards" depends on the point of view. Cloud providers have an interest to advertise it even if that does not apply to your use case. Using the cloud will not help you store the GPG encryption keys more securely than with an on premises solution. Using a cloud infrastructure expose your PII to national agencies and potential rogue administrators of the cloud provider. – A. Hersean Apr 25 '22 at 13:03
  • Also, using a cloud provider will make you dependent of it: you most likely will not be able to later move to another provider (or in house) and you will find yourself needing to buy more from them to expend your services. Think carefully before making this decision. Switching providers or going back can be very expensive (in time and money). – A. Hersean Apr 25 '22 at 13:05
  • You need to ask yourself: Who (among users, administrators, apps and services) needs to access the encryption keys? Who must not access it? How to isolate them (with access control, air gap, HSM, TPM, etc). Using encryption to protect encryption keys is just moving the issue elsewhere without solving it. If you split a key among multiple servers, you will need multiple servers to unlock the key, which will be used at one place in the end: it looks unlikely that this could help to solve your issues, but it will certainly make your system far more complicated and prone to errors. – A. Hersean Apr 25 '22 at 13:16
  • @A.Hersean Only the software running on the server should access the encryption keys with no human interaction. The requirements are apparently to use the public cloud and we cannot change anything about it apparently... – Munchkin Apr 25 '22 at 13:37
  • If there is no difference between the software using the keys and the software manipulating the data once it came out of the encrypted communication canal (preferably with TLS rather than a VPN for finer access control), why encrypt the data at rest? Encryption at rest is supposed to protect against which threat? (Backups can be encrypted by another process.) – A. Hersean Apr 25 '22 at 14:06
  • 1
    You have a problem with your threat and trust models. Address those first. If you consider the remote service insecure, then you shouldn't be storing secret keys or other brute-forcible items there in the first place. YTTMMV. – Todd A. Jacobs Apr 25 '22 at 15:09

2 Answers2

1

I'm sure there's a few security professionals that can spin stories about "military grade" security.

So you want to encrypt data and process it with zero insider threat? What you're looking for is homomorphic encryption. That's a mean geanie, formulate your questions perfectly. But if something is ever decrypted in the cloud there is an insider somewhere with access to that running process/decrypted data (in the public cloud).

To be less hyperbolic, minimize insiders with access to a system, store keys in a KMS or HSM and store all values encrypted at rest. Clouds often have special pricing for HIPPA or military grade clouds. And hire a security consultant for the particulars if it means that much to you.

foreverska
  • 1,115
  • 11
-1

This is certainly possible using new encryption schemes.

See sample code below:

Alice wants to send a message to a Resource Server X. The resource server saves the encrypted data in the cloud and I presume this is your use case.

Alice fetches a shared key for X and encrypts the message to be sent to X. This message can be stored on the public cloud and no one other than the resource server can decrypt this message not even administrators.

var HEClient = new ASKClient("Alice Resource Login Token","Alice Resource Name", "Alice Resource Login Token Password");

This is how alice will fetch the shared key for X

var sharedkey = HEClient.GetPreSharedKeyByKnownName("X",UnixTimeStamp);

This is how alice will encrypt the message

var encryptedmessage = HEClient.EncryptMessageUsingSharedKey("X",<Encrypted Message>,<sharedkey>);

Note here that internally the library also makes use of "Alice Resource Login Token Password" to encrypt the message.. This kind of encryption scheme is not currently available anywhere where the private passsword and shared key together is used to encrypt the message.

This encrypted message can be sent to the resource server. The resource server can download the shared key for alice by using the unix timestamp and save the shared key.

This encrypted message/file can be stored in the public cloud along with the shared key (What?? saving it along with the key, that's right, the shared key is useless since the encryption and decryption also needs the resource secret(password) to decrypt the message like shown below)

var HEClient = new ASKClient("Resource X Login Token","Resource Name", "Resource Password");

Note here that the shared key of alice along with the resource password is required to decrypt the message

This is how Resource Server will fetch the shared key for X

var sharedkey = HEClient.GetPreSharedKeyByKnownName("alice resource name",UnixTimeStamp);

This is how Resource Server will decrypt the message

var decryptmessage = HEClient.DecryptMessageUsingSharedKey(<Encrypted Message>, sharedkey>);

You can search for this library in nuget: ASK Client Library ASK Client nuget

schroeder
  • 123,438
  • 55
  • 284
  • 319
Sriram Shankarlingam
  • 1
  • 2