I noticed light support for TPM in VyOS. I recently started a project, go-trusted-platform, that deeply integrates with TCG and ACME specs to support fully automated device enrollment and certificate issuance for IoT and Enterprise networking use cases. The same project is the core platform for a cloud service provider solution I’m working on, which I would love to use VyOS as the routing and CA platform.
Integrating my project into VyOS would allow VyOS to be fully supported by TCG workflows as a client or Privacy/Enterprise CA (or both), and significantly increase the security posture of the router and overall network security by allowing administrators to use the TPM to store keys and participate in automated device enrollments into the Enterprise CA / network, perform ongoing remote attestations, etc, to fully support Trusted and Confidential computing environments.
Is this a desirable feature for the VyOS maintainers and community? If so, I’d be happy to take on the integration challenge.
We have some basic PKI management, but i don´t think that it supports the CA case ( I could be wrong, though)
Let’s ask @sarthurdev
More security features never hurt
Yes, I noticed that. Integrating my project would replace the current CA features with a CA that stores it’s keys in the TPM and supports the ACME protocol for TLS certificate issuance, as well as custom challenge types to facilitate Endorsement Key Certificate and Device Enrollment procedures outlined by the TCG and 802.1AR secure device identity.
It can also be used to store keys for authentication, VPN secrets, and facilitate remote attestation requirements for clients joining the VPN, such as having to provide a valid attestation statement prior to establishing the connection.
There are many other use cases it could support as well.
The thing is that not everybody has TPM available, and we need to have basic version
on other hand, I don’t see why both can’t coexist, we just need to come up with proper design
The CA in go-trusted-platform uses a pluggable key store backend that currently supports basic PKCS 8 keys on the file system (encrypted or raw) as well as TPM 2.0 or PKCS 11 HSMs, so the CA config would have an option to specify which store is needed.
There is also preliminary support for Dilithium to address post-quantum safe algorithms. It also supports client and server based Ed25519 TLS connections, which are not supported by most mainstream CAs or browsers. Since safecurves considers P-256 insecure, it seems we could use better support for TLS connections, at least at the network infrastructure layer. The included web service and CA make this possible.
It seems like enabling the Trusted features could be a global config option, that when enabled, expect a TPM available.
Is there a development channel somewhere that would be more appropriate to dive into the details?
significantly increase the security posture of the router and overall network security by allowing administrators to use the TPM
My BS-ometer got triggered there. Those claims are only valid when the TPM is in locked down state which isnt really the case for a router who must be able to on its own access this data and when the router itself can access it then any malware (or unwanted admin) who gets onto the router can do the same. Also if the terminal the admin are using to manage these devices is already connected to the internet then thats a more likely attackvector to gain access to the private keys being populated onto the VyOS-router.
But with that being said Im in favour of adding support for TPM so the admin can have the option to use it or dont use it (if you for whatever reason dont trust that TPM-chip to do what its at least on paper supposed to be doing).
And as already stated VyOS is being runned both on hardware and as a VM (or even some attempts to run it as a container) so making TPM mandatory would be a very bad move - but making it optional sounds great.
Apologies on triggering the meter. I agree if keys and secrets are accessed using PCR sessions to automatically release keys (as is the common use case) on a backdoor’d system or compromised tooling, the secrets can be stolen.
As with everything security, there isn’t a 100% secure solution, and it’s a constant cat and mouse game that will likely go on forever. That said, the platform is built to support any key storage mechanism present and future, so as specs and technologies evolve, so will the APIs and capabilities. As long as there aren’t any remote exploits, I think it can be considered a safe key store for most security conscience and standards compliant use cases. The Integrity Measurement Architecture in the Linux kernel also integrates with TPM PCR’s and can be used to create state / intrusion detection systems that can respond to changes on the system any way one would like. Having that capability on a router, especially with remotely accessible APIs, that can be used to automatically make firewall configs on the fly seems like a powerful combination.
If keys are stored in the TPM with authorization policies that require password instead of PCR sessions, or are integrated with MFA or other external mechanisms, even if the system were to become compromised, an attacker will not be able to access the secret (hardware / protocol vulnerabilities aside).
Even with vulnerabilities, I think It’s still better than storing raw key bytes and secrets on a file system or env vars, and has features beyond key storage to support automation and configuration policies that make it a useful technology. It’s also compliance regulated in some industries. I expect the vulnerability mitigation and spec to continue to evolve, I hope 3.0 supports Curve25519 and post-quantum algorithms.
The popular usecase for TPM is to use an encrypted storage and by storing the keys in the TPM the content of the drive is somewhat protected when/if its disconnected from where its supposed to be installed.
And sure adding TPM support could make encrypted storage for VyOS being “automatic”.
But for other cases such as private key used for SSH or (if there ever will be) HTTPS (webgui) but mainly when x509 is used for VPN-tunnels (since passphrases will be stored in config-file) then the VyOS must be able to access the TPM on its own - it cannot relay on an admin to login to it to every time unlock the TPM using a password or MFA or such for the VPN software to get hold of the private keys (from the TPM) to be used.
Which gives that using TPM for a router is only a matter of false security since the TPM in that case wont protect against a malware who gets onto the router or an evil admin who gained access to the device.
Again Im in favour of adding TPM support so it becomes optional but Im a bit allergic against false claims that TPM would somehow make things more secure when it comes to the usecases for a softwarebased router.