CODEWITHSUNDEEP
javaencryptionamazon-s3cryptography
Danijel
Danijel

Reputation: 8616

How to exchange encryption keys with the customer?

My Java app needs to handle encrypted files. This is the workflow:

  1. Customer encrypts files (RSA encryption for example) and uploads them to Amazon S3.
  2. My Java app picks up the files from AS3.
  3. My Java app decrypts the files.
  4. My Java app creates other files using decrypted ones.
  5. My Java app encrypts new files with different key and uploads to AS3.
  6. Customer picks up the files.
  7. Customer decrypts the files.

Amazon S3 provides the Java classes for download/upload, decryption/encryption. This API takes as input java.security.KeyPair. I am unsure how the customer should supply the key to My Java app, so that the app can get the key as java.security.KeyPair?

What would be the proper way to exchange the keys between Customer and App? Which key file format could be used?

Upvotes: 1

Views: 1274

Answers (2)

Maarten Bodewes
Maarten Bodewes

Reputation: 93968

The problem is that you don't have a method of distributing trust yet. Fortunately there is one that works reasonably well: TLS. TLS certificates are stored within the browser (and in the JRE, if you require a thick client instead).

Your key pair should be generated locally (or on a secured machine and imported). The private key should be kept safe the whole time. The customer connects to your site using TLS, and downloads your public key. Then the customer uploads the public key of his key pair. This can be performed during some setup/configuration phase.

Now the customer can encrypt files for you, and you can encrypt files for the customer. Note that TLS already provides encryption (confidentiality). So what you have gained is that files are protected during storage, after they have been transported. Once you have trust in the public key (and a trustworthy system) you could send files over plain HTTP.

Adding a signature is pretty important, otherwise anybody can replace the files in storage. Some audit logging is probably required as well, otherwise files may be removed.

Other schemes are possible (I prefer a PGP scheme for file encryption/decryption), but they require out of band communication of the keys. Note that this is just the basic scheme, there are a lot of pitfalls, but working out a specific security architecture for you application is clearly off topic.

Upvotes: 1

brimborium
brimborium

Reputation: 9512

Ussually, assymmetric encryption/decryption works like this:

  • You generate a private/public key pair. The private key should be held secret and should not be sent around etc. The public key can be given to the customer without security concerns.
  • Now the customer encrypts his files with this public key. The encrypted file can only be decrypted with the private key. So the user can send the file to you (over Amazon S3 in your case).
    • You receive the file and decrypt it with your private key.

Now you have got a file from the customer. To be able to send back encrypted messages, you need another public/private key pair. This time, the customer must be the only one knowing the private key. He can - for instance - put the public key in his file that he has sent to you. Anyway, somehow you need to get a public key from him. With that key, you encrypt your files and send them to Amazon S3. The user picks them up and decrypts them with his private key.

So, the customer must not give you a java.security.KeyPair, because those contain the private key. It's unsafe to send the private key. But he can send you the public key as a java.security.PublicKey. I think the best way would be to send it to you either within the file he supplies anyway, or within a separate file that he uploads at the same time and besides the supplied file.

Upvotes: 3

Related Questions