> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Robert Moskowitz > Sent: Tuesday, September 05, 2017 08:43 > > Also he recommends password protecting the keypair. That results in > needing to provide the password at responder startup. Is this the > 'normal' approach? Is the password provided in some other file (like a > responder config file)? I am use to putting SQL passwords into php > config files, not that I like that...
That's one of the oldest problems in IT security. Most approaches fall into one of three categories: - Specialized hardware. This was one of the original intended uses for Sun's JavaButton hardware token, back in the '90s, but the JavaButton never really took off. These days we have various flavors of HSMs which act as key vaults and signing servers - though then you have the problem of authenticating to the signing server, or if you offload all crypto operations, authenticating to the crypto server. TPMs (which are essentially integrated HSMs), smartcard readers, etc can also hold keys, but typically require some authentication by a human at system startup. - Attended startup with manual passphrase entry. The server can't start until someone enters the passphrase at the keyboard. - Passphrase or private key in a file for unattended startup, hopefully protected as well as possible by filesystem permissions, filesystem encryption, etc. This is obviously the weakest choice for key protection, since it has a wider threat tree (more paths for an attacker to make use of the private key) than the other two options. For general-purpose applications where you don't need particularly good performance, such as a moderate-volume web server, there are some very inexpensive hardware options. OpenSSL works well with the NitroKey HSM (via the PKCS#11 engine), for example. Things get tougher as you add requirements. -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
