I have been wondering if it might be possible enable secure boot on a small run-of-the-mill SOHO router or switch using an external tpm, either something you somehow attach to some GPIO pins if you have them like the EP0149, evaluation board or possibly (create an?) interface overUSB or even Ethernet ? Another alternative may be to use an external device with a tpm to verify the firmware over usb.
On the software side, I see tpm2 kernel modules are a part of Open WRT, uboot seems to support it, and there are projects out there that enable u-boot to support TPM's, especially with things like OS-TEE
P.s does the OpenWRT One have a TPM? I found a forum discussion thread but I a quick search for "tpm" on the product page didn't give me a result.
P.s.s ["Bonus" Question that may Slightly Expand Question Scope] Might it be possible to support [a form of?] measured/secure boot using another Hardware Security Module, such as a Smart Card or USB Security Key?
Thanks!
UPDATE:
Changed the name of the topic from "External TPM Module?" to "External TPM/HSM Module?" to reflect a slightly more generalized discussion.
Do tpm actually do anything more than making the headache pill manufacturers more money and making hardware manufacturer’s richer?
This is the big problem with Win11, a lot of fully working pc must be thrown away just because they lack tpm2.0 without any meaningful function for anyone anywhere.
And OpenWrt is rom so it can’t be a corrupt boot after the build is done.
There is no secure boot support on OpenWrt at this point.
It's unlikely that there ever will be secure boot support for OpenWrt on x86_64, why - because access to Microsoft's certification is expensive, takes weeks++ to get signatures back and makes several building approach (both on the buildbots and for testing at home) impossible - or at least very difficult. And introducing your own chain of trust is not going to be fun, varying widely between mainboard manufacturers and plain not-working on quite a few boards. That is the situation on x86_64, where all of this is 'easy' and where prior art exists in the big general purpose distributions - but the smaller ones (and at home developers) simply can't play on that level, cost and efforts are completely out of line for that.
How do you expect that to work on != x86_64?
So far, we are happy that secure boot on ipq807x can be disabled on many devices (u-boot setting), if the vendors remove that loophole, it's bye-bye for OpenWrt support, as there wouldn't be any way to installed anything not signed by the vendor (who has no intention to sign OpenWrt, nor realistically could, for daily snapshots).
I don't think there is any way to do secure boot at all, apart from x86_64 (at a serious cost, monetary and with a lot of invasive changes to OpenWrt's buildbots, the source recipes and boot chain, in other words, unlikely to happen) - or one self-produced hardware (where OpenWrt would keep the cert chain in their own hands), but OpenWrt is not a hardware shop (ignoring the OO for now, which can't cover all use cases). It would be madness to even try.
So what do you actually expect to implement here, what are your uses that require tpm support?
If you want it, you will have to do a lot of very invasive development first - and will have a lot of convincing to do that it is a) worth it, b) possible to implement, without breaking the bank, the buildbots and the developers' (and users'!) personal testing and c) look at the impact on the buildbots.
Those are questions you will have to answer, not to ask…
…and all of this comes up, before even thinking about hot-gluing on an external tpm onto systems not designed with that in mind.
Disclaimer: I'm not an OpenWrt developer, I can't speak for the project and the opinions above are my own only - however, I did look into- and follow this topic before, without being blinded by buzzwords.
If you care about this, do a very simple experiment on your own system(s) first:
take your preferred general purpose linux distribution that has secure boot support from the factory, for which documentation exists (in other words, where this is a solved and documented problem), e.g.:
Debian
Fedora
OpenSuSE
Ubuntu
…
install it on your x86_64 system normally (preferably on removable media), secure boot on and in enforcing mode - just as Windows mandates it from the manufacturer
now rebuild a few key packages on your own, do a simple modification here (e.g. bump the internal version number of them, simple one-character (non-)changes), rebuild and install them on your system (this obviously involves creating your own CA and generating your own keys, as well as enrolling your keys in the UEFI firmware of your mainboard(s), keeping secure boot enabled and in enforcing mode)
shim
grub
dracut/ initramfs-tools
kernel
(kexec)
(qemu)
take this disk, and boot it on at least three different (different mainboard manufacturers) systems, at least two of them being real physical (non-virtual) hardware
give the disk to a friend/ work colleague, advise them over the phone what they have to do to boot your disk (with your modified shim, grub, dracut/ initramfs-tools, kernel) on their computer (and how to enroll your keys in their UEFI firmware)
…I'd really like to hear about your experiences doing so.
If you like the result, start all over again to migrate your findings to OpenWrt, I guarantee you, it's going to be 'fun' and you won't be bored for years to come; that's before even thinking about the impact on project structures (get access to Microsoft's signing service, come up with the funds to join, fun little projects like buildbots, imagebuilder (online and offline), etc. pp.).
@slh I think you are more well versed in this subject than I am. The choice of words "secure boot" may have been poot as it seems to be a sort of brand name of something attached to Microsoft. I have also heard the terms "measured boot" and "verified boot".
I want to clarify that I'm not necessarily looking for the brand name Secure Boot, though if it were there I would take it.
I would like to know a router or switch has not been tampered with through well known firmware/hardware vulnerabilities or back doors (which I would hope to mitigate with secure boot, though a back door may not be detectable via verified boot depending on what is measured and hardware). The ability to plug in a usb stick with a tpm, gives users a greater diversity of hardware running open source firmware to choose from rather than being constrained to certain models which ship with "secure boot" (most of which are probably closed-source or cant run openwrt, dd-wrt, etc.). It also allows you to enhance the security of hardware someone may already have.
Back to this:
What I am looking for strong guarantees and a way for a Hardware Security Module (HSM) to independently verify installed software was not tampered with or modified.
This could be as simple as storing a hash in HSM and using it to independently audit the firmware and authorize loading.
It would be even better if we knew it had the software vendor's cryptographic signature.
It seems to me possible that a project like OpenWRT could have their own Private-Public key pair and distribute it. There are a lot of tools to manage "secrets" which can be injected into build processes. For example: github CI. It seems (not just here) throughout the post you are implying difficulty managing/handling the certs. I agree a Micro$oft cert might be a bit much but it seems like there are a lot of tools for handling sensitive data like that nowadays.
I don't want to understate work that it may be to the developers (who give their time and hard work). But maybe I need a bit of explanation here, my understanding is to sign code, you would build it then at the end of the build process once you have a binary, run it through something like gpg to generate a signature, and publish it.
In this case maybe it needs to be more incremental or each module needs to be signed? (I may have something that could be integrated into the ladder)
Working under the idea that Secure Boot is mostly a M$ thing think this is wrong if I am reading "Secure Boot" to mean the same thing in some of my sources. Otherwise, using a broader definition (verified boot, measured boot, non brand name "secure boot") I disagree with this statement.
I already mentioned OP-TEE (I called it OS-TEE, my bad) which works on platforms other x86_64
Das U-Boot supports measured boot and other forms of establishing a trusted execution enviornment (OP-TEE) on a wide verity of hardware, for example TI K3 chips and STM32MP1xx boards, it seems to also work with AMD TrustZone (noting some you can set parameters where some of these chips have some sort of "secure boot" mode).
More so however, Das U-Boot has a form of verified boot, using FITS images, perhaps an HSM could be integrated to work with this? This may be the most viable option since OWRT uses uboot. It may even be possible to run the software only version on OWRT today.
There is also Trusted Firmware A (github dot com/ARM-software/arm-trusted-firmware)
There are also open source projects like the Trusted Firmware Project which includes OS-TEE, and Trusted Firmware-A and other projects like MCU boot for 32 bit micro-controllers
Projects downstream of the Trusted Firmware Project like MBed OS may have utilities that can be borrowed.
I would also like to mention Trussed (github dot com/trussed-dev/trussed), which has an approach that may be able to address some of the challenges you mentioned, including what you said before with establishing a chain of trust, due it atomic update nature (its all done in one go). In this case it would be an improvement, as it can not verify the bootloader.
I would recommend reviewing What Trussed Is Not] and Portability Notes on that page
Trussed seems to be more of a framework which implementation details on different platforms can be specialized for each platform as required.
I think ripping out the existing framework and replacing it with Trussed might be too much effort to your point, but I think something can be learned from the approach and it is "secure boot" on another platform that is not x86_64
I do think that forms of secure boot can work on non-x86_64 platforms.
I think that verified boot is becoming a more standardized modern feature across most hardware devices (PC's, Phones, Entertainment Centers, and Routers & Switches). If OWRT wants to keep up it may be a bridge it has to cross eventually. Though my understanding is that its not primarily for enterprise environments. But if it does not it likely wont make it into those environments as significant parts of the infrastructure or down/up-streamed into hardware for that purpose (and generally for the good of FLOSS, as sort of implied in this thread)
Personally I like the extra assurance, but for IT departments or IT management its quite a big deal verifying computer's connected to their networks didn't boot malware at that stage in the process (which could undermine Anti Virus software or other security measures), and helping to protect corporate secrets, verifying the integrity of installed software, etc.
I personally think that vulnerabilities in this type of thing exist and try not to completely rely on it, especially when dealing with diverse hardware. I prefer to have a second factor (like an HSM) verify that assumption (after OWRT was written to that memory unit).
I am not a firmware expert, please feel free to correct me, however:
Firmware modification seems to be "a thing", a quick couple of searches revealed somelinks
Even if not: a TOCTOU attack of incorrectly implemented secure boot without an HSM can install persistent malware (I am unsure if this involves modifying the firmware). The reason I point out this specific type of attack is that it can be done on firmware like OWRT and it happens at runtime
You realize, should this be implemented correctly, that you could never install OpenWrt (or anything but the vendor's original OEM firmware) on these devices?
We already have this situation on some ipq807x devices - and quite a few ipq807x devices only allow installing OpenWrt, because the vendor 'messed up' and unknowingly(?) left in a (difficult) way to ignore secure boot.
It 'could', but I guess you underestimate the efforts involved (quite simple comparison, none of the big commercial distros do this, not RHEL, ORACLE, SuSE, Ubuntu) - and there are reasons for that. Mostly because trusting keys isn't single-sided, you need to convince the hardware to trust your keys. Microsoft has the market power to be 'trusted', no one else comes close - and importing an alternative set of keys is difficult (to downright impossible, depending on the mainboard) on x86_64 - and we aren't even talking about non-x86 yet.
My post above "food for thoughts" was intentionally phrased that way, to show you the problems on 'easy' hardware. And in an environment you can trivially test yourself (at least if you disable secure boot).
Not sure, since the HSM would be removable, I would think you could wipe the device and run unsigned software after (if you dont want to use your HSM). Also you could install additional keys onto the HSM possibly including your own for custom builds.
Its not technically a "correct" implementation full secure boot, but I imagine, for example, the raspberry pi here could have the secondary boot-loader wiped and the tpm disconnected (jerry-rigged solutions like this may be a necessity in some circumstances to support secure boot, though I still think it improves security).
Probably.
I get the sense though that you are still thinking about going through a formal process and getting keys onto chips/boards distributed by manufacturers?
I'm talking mostly cheap usb sticks for around 10-20 of your native currency that you can install whatever key you like onto yourself.
Thats fair enough. Given the software packages I saw and some of the projects I have seen online I thought this might be possible to do myself with some modifications (if it is someone please tell me )
I'm not sure its the same model, what you propose seems a bit more restrictive than what I am thinking.
Slight thing I wanted to add, Canonical and Fedora/Red Hat have at least some keys that can be installed or are installed on some hardware. If they don't, they allow you to self sign with a Machine Owner Key (MOK) and a utility is provided with a lot of distributions for that
Shim also seems to be signed with a Microsoft Key, so if one did want to go this route, you may not have to go through all the steps, you may be able to got M$ to sign a boot loader (like shim is), and have a lower level CA key (I assume that is what it is) for software booted with that particular bootloader [source].
That would be when trying to use the internal fTPM wouldn't it?
I know that, but it doesn't make your part of the thought experiment above any (at least not by much) easier.
That's why I keep coming back to the situation for x86_64, because there it is fairly standardized since ~roughly sandy-bridge, so you can try it on (almost) all x86_64 systems built within the last ~13 years. There are even quite 'easy' helpers for OVMF/ tiano_core to this for you in a virtual machine - that's why my thought experiment explicitly calls to replicate this on at least two different physical x86_64 computers, because then you'll notice that it isn't all roses.
You can do what you want on x86_64 already, now and for anything built within the last ~13 years, but it's so easy that only a handful of users (most of whom probably need to as part of their work as distribitution developers) actually do this in practice, on real hardware. My guess would be that the number of persons who do so probably doesn't exceed the three figure range, if it even reaches it, world-wide. But if you want to dabble into this topic, x86_64 is the easiest and cheapest way to do so, with plenty of documentation and prior art - doesn't mean that it's pretty, though.
And on x86_64 (so far), you can still enroll your MOK - that is not guaranteed on other architectures, where you might have paid for the system, but aren't considered to be its owner but rather the enemy.
As said, the idea to freely install OpenWrt in a router is the EU definition of malicious activity and corrupt firmware.
Why do you think more and more hardware manufacturers have signed firmware nowadays. It is legal demands in EU to secure routers with tamperproof firmware.
And the thing with rom installed firmware is that if that gets “infected” then the infections was installed at buildtime. And that means the sourcecode is infected. And then a tmp or other security won’t matter at all.
)