First I want to say thank you to Steve, John, Roy, Adwait, and James for the replies, and suggestions.
The data is credit card related, and represents the working batch. The file is only decrypted if the service reloads (from reboot etc), but must be accessible to the service on load. There is only 1 batch (generally 1 day) worth of data in the file, but a hardware failure or OS issue could necessitate moving the file to a new machine mid batch. So I have to balance security with recoverability, and ultimately I'm responsible for protecting the data from loss (be it from theft, or hardware / software failure). In a perfect scenario I could generate a random key, and give the User / Dealer / VAR the responsibility to back up and store the key for restoration. But at some point that will cause data loss from either failure to make the backup, or failure to secure the backup. I guess the next best thing would be to store the backup file myself (via code) to the same (user definable) location that I duplicate the file to in case of hardware failure, but that leaves a similar situation involving how to protect the key in the backup file, and ensure that the user actually uses the duplication feature. I'm currently leaning towards a heavily obfuscated and very convoluted stand alone app that would assemble a key (pre created via RNGCryptoServiceProvider) that has broken into different methods, math routines, etc., and write the key into protected storage. I would include the app as part of the MSI, but not actually install it. The MSI would call it during installation to have it write the key (possibly passing part of the key in for even more security). Thanks again to everyone that replied, and feel free to point out anything I am missing, or could improve with this scenario! -Rob -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Steve Johnson Sent: Thursday, March 20, 2008 5:03 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] Key storage. On Thu, Mar 20, 2008 at 2:25 PM, Robert Lee <[EMAIL PROTECTED]> wrote: > > Thanks for the suggestion. I have a routine that creates a key from a > password, using SHA512. The problem is distributing the password, or the > key. > Right. If you go with the derived key approach, you must derive the key each time you need it to decrypt data. If there's no access to the password at decryption time, then this approach won't work for you. Also, don't just use a hash to derive keys, because then your key will only have as much effective entropy as the password from which it is derived. For deriving keys from passwords use the Rfc2898DeriveBytes class. > > I will look into encrypting the key into a file here before release, and > then distributing the key file, and certificate, but I'm not sure how > secure > that is. It wouldn't be to hard with reflector to figure out that > certificate A is used to decrypt file B, .... and reproduce the code. If you go with this approach, then the cert's private key must be kept secure. You'll need to install the cert in the store of the user that is decrypting the data. If this user profile is not available, then put the cert in a LocalMachine store and grant access using winhttpcertcfg. As you can see, nothing is free when it comes to protecting keys. It's an extremely difficult problem to solve securely. -- Steve Johnson =================================== This list is hosted by DevelopMentorR http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
