Protecting private keys on OpenVPN server using a TPM?
-
Does anybody know if its possible to protect the keys on the OpenVPN server using a TPM?
Windows has a feature called virtual smart cards which ive used to protect the client key but i cant find anything similar in pfsense for the server.
Alternatively could i use something like this:
https://shop.nitrokey.com/shop/product/nitrokey-hsm-7
-
Does anybody know if its possible to protect the keys on the OpenVPN server using a TPM?
In normal not. According to the TPM regulations or standard it is more to take there fore that no one from
outside is able to change the software.An USB Server from the vendor SEH can be used together with USB pen drives market as read only
for that actions if you want. They support VLANs and are well done in high quality.This nitrokey is more for the admin to store his SSH key for a secure SSH contact or connect to the
pfSense firewall and if he or she is leaving his workplace he is able to take his keys by him away from
3rd party or other person usage if he or she is not in place. -
Who are you protecting them against?? Who has physical access to your firewall? How exactly does pfsense get access them?
-
HI johnpoz,
I'm just using pfsense as my home firewall / router so its more from a learning / best practice point of view rather than defending from any specific adversary.
I'm not a Linux guy so i don't know how pfSense stores its private keys but they are exportable from the UI so I guess they must be stored in a confg file somewhere.
I was hoping there might be a way to do something similar to how Microsoft Virtual Smart Cards work. The keys are stored on disk but they are encrypted using the TPM root key, they are then loaded on demand into the TPM which decrypts the key and performs the cryptographic operation on behalf of the caller. This way the private key is never exposed and cannot be exported or copied.
I've got it working on the client so just for symmetry id like to see the same thing on the server if possible
-
I don't see the point to this at all…
Your trying to encrypt the server key.. So when your pfsense box reboots, how exactly is it going to get the key without intervention on your part? And if it can self decrypt the key to use it.. Then your whole encryption step is moot. Anyone that had access to pfsense would be able to grab the keys because they have been decrypted for use.
Encryption of anything on serves to protect the file encrypted from gaining access if they have access to the encrypted file. But once the file is loaded and the os is running, and you have access to the os you have access to the key.
That is great you encrypt the key you carry around with you on some stick, so when its not in use and you loose the stick someone would not have access to your cert. But this makes no sense for a system that has to have the key loaded to use and is running. And if the key is not loaded, how are you going to loose your firewall?? Who would have access to it if its off? If someone comes in and steals your pfsense box, you would just create new key pairs and the old server one would be useless to anyone.
-
HI johnpoz,
I think the bit you're missing is that the TPM performs the encryption on behalf of the application. The application (openvpn, pfsense, whatever) doesn't need access to the keys itself. It asks the TPM to perform the operation on its behalf. I thought this was a fairly standard setup in high security environments?
-
I'm just using pfsense as my home firewall / router so its more from a learning / best practice point of view rather than defending from any specific adversary.
This can surely be, but in networking general, the usage of a TPM module that holds a key that can not be
wiped, copied or push away is discussed for a real longer time now. So I was thinking you was reassume
or reopen this discussion line, that was ending up with the name "trusted networking" and sadly without
reaching a goal.I'm not a Linux guy so i don't know how pfSense stores its private keys but they are exportable from the UI so I guess they must be stored in a confg file somewhere.
pfSense is based on FreeBSD and not Linux, this at first and the keys will be not stored inside of a config file
but more in a key file format that must be readable! So encryption might be a real problem, because the entire
SSH or VPN or SSL or whatever communication will be not really be able to flow if needed. Something or somebody must be even in front of an action decrypt that key first if it should be used.I was hoping there might be a way to do something similar to how Microsoft Virtual Smart Cards work.
The USB network server with an attached USB pen drive marked as read only will do that job otherwise
with ease and in the nearly same matter.The keys are stored on disk but they are encrypted using the TPM root key, they are then loaded on demand into the TPM which decrypts the key and performs the cryptographic operation on behalf of the caller. This way the private key is never exposed and cannot be exported or copied
I think more that the key is inside of the TPM module and this key will be then taken for the encryption job
of the other keys on demand but as I am informed the key inside of the TPM will be not able to change, to
wipe or copied and so this would be a safe thing then. But for sure you can be right and I am have a greater
knowledge hole of that action.I've got it workign on the client so just for symmetry id like to see the same thing on the server if possible
Out of the box it would not be able as I see it right, but if someone writes code to realize your wish it
might be able to do. There is a SDK (software development kit) from IBM under an OpenSource license
and with that anybody will be free to code something that is able to use this TPM modules for any other
kind of action as he need it. Again at your case of use I was not really thinking at first when I was reading
your question you made here. -
Hi BlueKobold,
Sorry i am having some difficulty understanding your message but i appreciate that you have taken the time to reply.
Unfortunately my German extends only as far as being able to ask for beer and yet more beer :).
Can you provide a link to the "USB network server with an attached USB pen drive" so i can understand what it is you are suggesting?
-
Can you provide a link to the "USB network server with an attached USB pen drive" so i can understand what it is you are suggesting?
SEH utn-80 and your nitrokey if you want
-
Have never seen any discussion what so ever on using TPM on the server side in openvpn. There are lots guides and discussion on using it on the client side.
Again I don't see the point to this on the server side. Your server side is always in a secure location, if someone has access to your vpn server, then they most certainly have have access to all your other network stuff. Securing the key the server uses seems pointless in any scenario I can think of..
Please explain a scenario were this step would be required?? I just do see it..
This works out to be the same as say a https connection, where is discussion of using TPM for a server serving up sites via ssl/tls that has to load its private key from TPM..
-
Hi johnpoz,
Yeah I've seen quite a few guides about using it client side but not that much about using it server side. I'm thinking this might be because the performance would suck if you had hundreds of clients connecting all the time but for a small office or home setup I don't think that would be an issue.
I did find some work by a guy called Thomas Habets (https://github.com/ThomasHabets/openvpn) who looks like he has actually done it but for whatever reason its not made it into the main openvpn code base. [edit] actually it looks like Thomas change was in the client not the server… time to give up on this now i think [/edit]
This is more about software security rather than physical security. If a machine is compromised through malware, hacking, whatever then the keys remain secure.
-
How exactly is your firewall/router going to get infected with malware. If someone gets in via ssh or webgui, or somehow gets a rootkit or any sort of backdoor/anything on it then you have worse problems then them getting your private keys that is for sure.
And glad you mentioned home setup again - this is SO FAR OVER the TOP for a home setup is beyond ridiculous.. I would call it wasteful even if you were in a DOD setup.. Think about how the keys are used. What is the advantage to getting these keys. To get them you have either local access or have compromised the box - access to the keys at this point is beyond moot.
Where is makes sense is the client side were the device could be stolen or compromised with say virus/rootkit access to the client keys would then allow access into the network behind the vpn.
Security is always a hit on performance or in overhead in access to some resource. Locking your door does not prevent people to access, it makes it harder for them to access. Not only the bad person but even the good person now has to remember to lock and then have to unlock said door. All security is this way.. Before putting any sort of security in place you have to warrant the extra cost in performance or speed of access, ease of the user of said system, etc.
If the thing being projected does not warrant the extra overhead, then it makes no sense to implement the level of security. Do you put a lock on your shed door that stores your lawn clippings before they get picked up every week?? You might put a latch on it to keep the wind from blowing it open - but it sure does not warrant a lock of any sort.
Look at what your wanting to secure, think about the cost of level of security you want to implement not only in performance but time of setup, etc. What is the actual risk if the something is lost.. Does it make sense??
In your scenario it makes ZERO sense to implement such a system.. That is my 2 cents on the matter..
-
Hi johnpoz,
Obviously there is a trade off between security and convenience but changing the key storage provider makes no difference to the end user experience so if the option existed i would enable it. As i said its just a learning exercise and if you cant see the point that's fine you don't have to :)
I'm going to put this on the back burner for a little while as i have other things to do but if anybody else reading this and has any suggestions let me know.
-
It sure might make a difference to the end user if the vpn takes longer to come up or is slower because of it. And it sure makes a difference to the complexity of the setup, which is cost..
Lets say the option existed - how do you get your keys out? What if you want to move this vpn connection to a different server. Now if you can not export the key or move the key does your replacement setup take the TPM config. If not you would have to generate new keys and issue new certs to all your users.
This is clearly more than clicking a checkbox or editing a simple config file..
While I can understand the learning aspect of it… I have been doing this for many many years, and have never seen any system where TPM was implemented on a server side anything.. End user box securing their keys sure, not on a server or appliance that provides the service or connectivity. As I said before these devices are normally in secure locations with already loads of security to prevent unauthed access. Securing something like the private side key in a key exchange for a secure connection be in vpn, ssh, ssl/tls makes no real sense..
-
It sure might make a difference to the end user if the vpn takes longer to come up or is slower because of it. And it sure makes a difference to the complexity of the setup, which is cost..
I don't think it would make any noticeable difference to the startup time or have any effect on the tunnels speed. The certificates are only used during the handshake to establish a shared key after that its all symmetric encryption. In theory the only setup / UI change would be an option on the system settings page to change the key storage provider (TPM would be an option if one is detected). I cant see this adding any significant complexity from an administration point of view.
Lets say the option existed - how do you get your keys out? What if you want to move this vpn connection to a different server. Now if you can not export the key or move the key does your replacement setup take the TPM config. If not you would have to generate new keys and issue new certs to all your users.
Well you wouldn't be able to get the keys out but that's kind of the point of putting them in tpm/hsm in the first place. I think there is a misunderstanding here. The client is only verifying the identify of the server. Its checking that the common name is right and that it was signed by a trusted CA. I can setup another server on a completely different box with a new certificate, change the DNS to point at it and all the clients will still work as long as the certificate has the same CN and is signed by a trusted CA. Conversely the server accepts the clients certificate because its signed by the CA. It has nothing to do with the servers own certificate
Securing something like the private side key in a key exchange for a secure connection be in vpn, ssh, ssl/tls makes no real sense..
I think hardware storage of private keys (using a HSM not a TPM) is pretty much standard for things like bank inter branch vpn's, hospitals, data-centers etc.
-
"is pretty much standard for things like bank inter branch vpn's, hospitals, data-centers etc."
No No its not… We have a fairly large hospital as one of our customers that I support. No they do not have any sort of TPM storing the vpn keys be it the remote users coming in, nor to any of the vpn connections between their branches and the datacenter or between each other.
We also have multiple DCs across the country and the globe, I can tell you that no there is not any TPM storing any of the server keys. And to be honest I am not aware of any customer even doing it for their remote users, etc..
