Thanks for the replies and great comments.
If it clarifies, I'll toss in a few more details which are important to my scheme:
- data is encrypted on the server, but can only be decrypted at the fullfillment center. This helps ensure that the stored data is safe in case the server gets compromised. This is different than what SSL does for us, although we are using SSL for server<->client communication for additional security anyway.
- decryption at the fullfillment center is secured in some way (password to decrypt the key, or the key is physically bound to a device [e.g. smartcard], or both).
So the essence is to have one-way encryption on the server, and decryption possible only at the client computer for viewing purposes (e.g. credit card information). I suppose I could still have something like a Java applet, but store the private key on the client computer instead of using a smartcard system. If I can do that, then adding the smartcard to the mix would probably just be a matter of some additional hardware and programming to grab the key from the card instead of from the harddrive, if it is an improvement.
This brings up what is probably a dumb question:
- If I'm just using the smartcard to store the private key, is there any advantage (security-wise) to using a smartcard over, say, a CD-R? I.e., can the smartcard be secured in some way to only allow the key to be copied off only if a password is presented? Or perhaps, have the smartcard do all the decryption internally (and be impossible to copy the key off)?
Thanks!
Phil
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
