J
jared
a1. Generate a random symmetric key on the server.
a2. Encrypt the symmetric key with the server's own public key.
a3. Sign the encrypted key blob with the server's own private key.
a4. Store the signed, encrypted blob someplace.
-----------------
To encrypt a package:
e1. retrieve what you believe to be the signed, encrypted symmetric
keyblob.
e2. verify the signature on the key blob using the server's public key
e3. if the signature is valid, decrypt the symmetric key using the
server's public key.
e4. use the plaintext symmetric key to encrypt the data you want to
send to the client.
e5. erase the plaintext symmetric key from memory
e6.store a signed md5 hash of the encrypted client data
e7. store the encrypted client data
---------------
To send a formerly encrypted package to a client:
s1. retrieve the encrypted client data and your signed hash of it
s2. verify the integrity of the encrypted client data
s3. initiate Diffie Hellman key agreement between the server and
client, the result of which will be your key transport session key
s4. use e1, e2, e3 above to get a plaintext version of your symmetric
data encryption key
s5. re-encrypt the symmetric data encryption key using the key
transport session key agreed upon via diffie hellman
s6. send the encrypted symmetric data encryption key to the client
machine
s7. erase the plaintext data encryption key from memory
s8. erase the key transport session key from memory
-----------
The client machine should decrypt the symmetric key using its copy of
the key transport session key, decrypt the data you just sent it, and
erase both keys from memory as soon as possible. Your secret symmetric
key should never reside anywhere in plaintext when it is not actually
in use, and should only be stored protected by the server's private key
(which itself, ideally, will only exist in hardware).
The hard part is implementing Diffie Hellman, and I'm guessing there's
a good free implementation available.
Cheers-
a2. Encrypt the symmetric key with the server's own public key.
a3. Sign the encrypted key blob with the server's own private key.
a4. Store the signed, encrypted blob someplace.
-----------------
To encrypt a package:
e1. retrieve what you believe to be the signed, encrypted symmetric
keyblob.
e2. verify the signature on the key blob using the server's public key
e3. if the signature is valid, decrypt the symmetric key using the
server's public key.
e4. use the plaintext symmetric key to encrypt the data you want to
send to the client.
e5. erase the plaintext symmetric key from memory
e6.store a signed md5 hash of the encrypted client data
e7. store the encrypted client data
---------------
To send a formerly encrypted package to a client:
s1. retrieve the encrypted client data and your signed hash of it
s2. verify the integrity of the encrypted client data
s3. initiate Diffie Hellman key agreement between the server and
client, the result of which will be your key transport session key
s4. use e1, e2, e3 above to get a plaintext version of your symmetric
data encryption key
s5. re-encrypt the symmetric data encryption key using the key
transport session key agreed upon via diffie hellman
s6. send the encrypted symmetric data encryption key to the client
machine
s7. erase the plaintext data encryption key from memory
s8. erase the key transport session key from memory
-----------
The client machine should decrypt the symmetric key using its copy of
the key transport session key, decrypt the data you just sent it, and
erase both keys from memory as soon as possible. Your secret symmetric
key should never reside anywhere in plaintext when it is not actually
in use, and should only be stored protected by the server's private key
(which itself, ideally, will only exist in hardware).
The hard part is implementing Diffie Hellman, and I'm guessing there's
a good free implementation available.
Cheers-