twhite333
asked on
Safest place/method to store private key?
We use RSA within our app to encrypt/decrypt sensitive info. The app has to have access to the private key to perform these operations.
What is the most out of the way place you can think of to store the private key on the system?
We have considered the registry but it doesn't work for the private key (has escape chars in it that do not store in a registry string).
Many regards,
TW3
What is the most out of the way place you can think of to store the private key on the system?
We have considered the registry but it doesn't work for the private key (has escape chars in it that do not store in a registry string).
Many regards,
TW3
you can still use the registry and use a reg_binary field type rather than string.
is your app a service that is running 24/7 or a user/event driven application? the reason i ask is because if it's a service, then you might want to opt for external storage of the key (pendrive, floppy, cd, etc.) once the service app is up and running with the private key already loaded into memory, remove the storage unit and keep it in an accessible but secure safe.
is your app a service that is running 24/7 or a user/event driven application? the reason i ask is because if it's a service, then you might want to opt for external storage of the key (pendrive, floppy, cd, etc.) once the service app is up and running with the private key already loaded into memory, remove the storage unit and keep it in an accessible but secure safe.
ASKER
I like your idea, trywaredk. In fact, I can see other applications for that, too. And droby is right about the reg_binary thing. I just tried it and it worked. But, since trywaredk's answer had broader application for us, I think I am going to give that a try.
Many thanks. This site and the people on it have really helped us out a lot. We are a tiny little company trying to do big things that are sometimes beyond our natural capability. We sure do appreciate all the great ideas people have here.
Regards,
TW3
Many thanks. This site and the people on it have really helped us out a lot. We are a tiny little company trying to do big things that are sometimes beyond our natural capability. We sure do appreciate all the great ideas people have here.
Regards,
TW3
wow...not to complain, trywaredk usually comes up with some great links, but storing a private key "safely" was the original concern...and now you're considering putting it on a share? that would be quite a remarkable move from out of the frying pan and into the fire, in light of your original concerns, and i can't say that this is the best advice given from the all-around-pro.
read-only is a no-factor, because the entire point of securing private key data is to prevent people from reading it and thus compromising encrypted communications/data. hidden shares aren't really hidden - you can still enumerate them without administrative priviledge (the microsoft packaged utilities for doing so simply filter them).
read-only is a no-factor, because the entire point of securing private key data is to prevent people from reading it and thus compromising encrypted communications/data. hidden shares aren't really hidden - you can still enumerate them without administrative priviledge (the microsoft packaged utilities for doing so simply filter them).
DROBY10 ..."is to prevent people from reading it"
TWHITE333 asked:
1) "We use RSA within our app to encrypt/decrypt sensitive info"
2) "The app has to have access to the private key to perform these operations"
1)
If the app must read the private key in order to do an encryption/decryption, how should it be possible to hide the key in registry ?
Inserting it as binary doesn't encrypt it !
Text-to-Binary (and back!) Converter
http://www.sitinthecorner.com/binary/binary.php
2) You have to have it readable somewhere
TWHITE333 asked:
1) "We use RSA within our app to encrypt/decrypt sensitive info"
2) "The app has to have access to the private key to perform these operations"
1)
If the app must read the private key in order to do an encryption/decryption, how should it be possible to hide the key in registry ?
Inserting it as binary doesn't encrypt it !
Text-to-Binary (and back!) Converter
http://www.sitinthecorner.com/binary/binary.php
2) You have to have it readable somewhere
TWHITE333 ---> :o) Glad I could help you - thank you for the points
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
hmmm... lemme think here.... What do you guys think about this?
Assuming the worse case scenario (someone has unfettered access to the system(s)), there is nothing that can be done to totally protect the sensitive stuff. So, our goal at that point is to slow them down as much as possible so that their intrusion is given the greatest chance of being caught before they make it too far.
So, assuming a worse case scenario (hacker with unfettered access), our goal is to slow down access to these items as much as possible. We know we can put things in the registry and read them easily enough. If we name them something non-mnemonic their importance is not not easily identified just by looking at them. And, if we encrypt them, then at least they have some work to do to get at them even if they identify their importance.
However, all this is moot if they do one thing - get at the application code. The code would necessarily spell out the storage medium (no matter what it was), the location, naming, decryption method, etc. So, actually, this then becomes our weakest link in the chain (sort of - the complexity of the code is in our favor - 100,000 lines of code that do not make it obvious how any of this is done).
Compilation of the code does slow the hacker's process down. After that, we may very well be back at some version of trywaredk's suggestion so we can try to hide the key code elements as much as possible and continue to slow the progess of the intrusion.
Ultimately, though, I think that we are going to have to devise an application architecture that helps us here. The more I think about it, trywaredk's idea is only good short term. Ultimately, we will need to take this further using a better app architecture and HW infrastructure to help us out. But, I think these combination of ideas may be our best short term solution.
Any thoughts?
TW3
PS: on the issue of points, I may have been a little quick on the draw and would look to advice from others on the appropriate etiquette in this situation. I am new and if a mistake was made then I will do what I am supposed to do to rectify it. I do believe that your combined suggestions were useful for this problem.
Assuming the worse case scenario (someone has unfettered access to the system(s)), there is nothing that can be done to totally protect the sensitive stuff. So, our goal at that point is to slow them down as much as possible so that their intrusion is given the greatest chance of being caught before they make it too far.
So, assuming a worse case scenario (hacker with unfettered access), our goal is to slow down access to these items as much as possible. We know we can put things in the registry and read them easily enough. If we name them something non-mnemonic their importance is not not easily identified just by looking at them. And, if we encrypt them, then at least they have some work to do to get at them even if they identify their importance.
However, all this is moot if they do one thing - get at the application code. The code would necessarily spell out the storage medium (no matter what it was), the location, naming, decryption method, etc. So, actually, this then becomes our weakest link in the chain (sort of - the complexity of the code is in our favor - 100,000 lines of code that do not make it obvious how any of this is done).
Compilation of the code does slow the hacker's process down. After that, we may very well be back at some version of trywaredk's suggestion so we can try to hide the key code elements as much as possible and continue to slow the progess of the intrusion.
Ultimately, though, I think that we are going to have to devise an application architecture that helps us here. The more I think about it, trywaredk's idea is only good short term. Ultimately, we will need to take this further using a better app architecture and HW infrastructure to help us out. But, I think these combination of ideas may be our best short term solution.
Any thoughts?
TW3
PS: on the issue of points, I may have been a little quick on the draw and would look to advice from others on the appropriate etiquette in this situation. I am new and if a mistake was made then I will do what I am supposed to do to rectify it. I do believe that your combined suggestions were useful for this problem.
>"on the issue of points, I may have been a little quick on the draw"
https://www.experts-exchange.com/Security/Win_Security/help.jsp#hi79
Post a 0 points question in https://www.experts-exchange.com/Community_Support/ with a title like
Moderator - please refund points and open the question again
and in the comments tell why, and a link to https://www.experts-exchange.com/questions/20948839/Safest-place-method-to-store-private-key.html
https://www.experts-exchange.com/Security/Win_Security/help.jsp#hi79
Post a 0 points question in https://www.experts-exchange.com/Community_Support/ with a title like
Moderator - please refund points and open the question again
and in the comments tell why, and a link to https://www.experts-exchange.com/questions/20948839/Safest-place-method-to-store-private-key.html
DROBY10..."and i really don't want to argue"
:o) Neither do I - We are all getting better, when we comments on issues, and I'm very interested in reading other experts arguments.
BTW: It's not allowed according to https://www.experts-exchange.com/memberAgreement.jsp)
:o) Neither do I - We are all getting better, when we comments on issues, and I'm very interested in reading other experts arguments.
BTW: It's not allowed according to https://www.experts-exchange.com/memberAgreement.jsp)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
actually, i was making a specific point of using aes, which is the defacto default algorythm for efs (since xp sp1), rather than the weaker alternative schemes available within efs.
but, you deserve the points for the dpapi solution. that's the most appropriate answer thus far as it's designed specifically for this kind of scenario. very nice answer.
but, you deserve the points for the dpapi solution. that's the most appropriate answer thus far as it's designed specifically for this kind of scenario. very nice answer.
DROBY10..."rather than the weaker alternative schemes available within efs"
:o) You're quite right, because I forgot to study the notes before answering above:
***quote***
NOTES:
Windows 2000 can only use the expanded Data Encryption Standard (DESX) algorithm for EFS encryption and decryption.
Versions of Windows XP earlier than SP1 can only use the expanded DESX or the Triple-DES (3DES) algorithm for EFS encryption and decryption.
Windows XP with SP1 or later can encrypt or decrypt files using DESX, 3DES, or AES.
***end of quote***
:o) You're quite right, because I forgot to study the notes before answering above:
***quote***
NOTES:
Windows 2000 can only use the expanded Data Encryption Standard (DESX) algorithm for EFS encryption and decryption.
Versions of Windows XP earlier than SP1 can only use the expanded DESX or the Triple-DES (3DES) algorithm for EFS encryption and decryption.
Windows XP with SP1 or later can encrypt or decrypt files using DESX, 3DES, or AES.
***end of quote***
LOL - and I also forgot the link to the notes in my quote
http://support.microsoft.com/default.aspx?scid=kb;en-us;329741&sd=tech
http://support.microsoft.com/default.aspx?scid=kb;en-us;329741&sd=tech
ASKER
ok - After some thought, I decided to increase and then split the points. I increased the points because I think it was more involved than I thought it might be in the beginning. I split the points for obvious reasons - it was a combined effort that evolved based on numerous comments.
I appreciate you two working together on this. The outcome was a far better solution that I believe to be immenently workable.
Many regards,
TW3
I appreciate you two working together on this. The outcome was a far better solution that I believe to be immenently workable.
Many regards,
TW3
:o) Glad we could help you - thank you for the points
Modulo - Happy to see that we all agree about the issue: Helping the questioner, and not fighting with each other.
Many Regards
Jorgen Malmgren
IT-Supervisor
Denmark
:o) Your brain is like a parachute. It works best when it's open
Modulo - Happy to see that we all agree about the issue: Helping the questioner, and not fighting with each other.
Many Regards
Jorgen Malmgren
IT-Supervisor
Denmark
:o) Your brain is like a parachute. It works best when it's open
looks like we're all in agreement - nice job everyone!
Understanding NTFS permissions:
http://www.windowsitlibrary.com/Content/592/1.html
Share Names With a "$" Character at the End Are Hidden
http://support.microsoft.com/default.aspx?scid=kb;en-us;90929
You Cannot Access Shared Files and Folders or Browse Computers in the Workgroup
http://support.microsoft.com/default.aspx?scid=kb;en-us;318030
Default Permissions for Shared Folders Is Read-Only Access for Everyone
http://support.microsoft.com/default.aspx?scid=kb;en-us;328065
Shared Folder Name Does Not Appear on Mapped Network Drive in Windows Explorer
http://support.microsoft.com/default.aspx?scid=kb;en-us;817861
Many Regards
Jorgen Malmgren
IT-Supervisor
Denmark
:o) Your brain is like a parachute. It works best when it's open