How to avoid a shared symmetric key and its maintenance issues?

A business partner has implemented the following:

1. Website A uses a symmetric key to encrypt user contact data.
2. Website A redirects to 3rd party Website B with encrypted data in querystring.
3. Website B decrypts data and uses it to resume transaction.

So, the symmetric key is stored in 2 locations.

Now, we have requirements to create Website C, which will be similar to Website A. Website C must also encrypt data and pass it to Website B.

So, the symmetric key must be stored in 3 locations.

As we continue to deploy we开发者_开发知识库bsites, this symmetric key needs to be deployed in many places. It is a maintenance and security concern.

Is there a better way to achieve the same result?

Ultimately, we need to securely transmit data from various websites to Website B.

I suggest you work this the other way round with a public-private key system. These are designed to solve your issue. Such keys allow pairs of servers to create their own symmetric key dynamically for secure communication.

Each server should encrypt received data with its own privately generated key, rather than relying on a shared private key.

You don't mean private key, you mean symmetric key. (With a private key you use the public key to decrypt it and vis versa, with symmetric the same key is used for encrypt and decrypt.)

In any case, here is how you do it.

1. Generate a whole slew of passwords for all the websites - each website has a different password.
2. You generate a random password and encrypt the data with it.
3. Encrypt the password you just generated multiple times, once for each website.
4. Each website then uses its personal key to decrypt the password, then uses that password to decrypt the real data.

For step 1 you can use symmetric or public/private keys, it's up to you.
For step 2 you use a symmetric password.

Since the password is very small it's not expensive to transmit multiple copies of it. While the large data payload is only sent once.