The SecureBoot code is not maintained like it should be
TPM/SecureBoot is largely a Microsoft headed project
The TPM is an Oxymoron. They don't trust you with the keys and the TPM module can be hardware profiled/fingerprinted and can be tracked when you attempt to be anonymous
Credentials that can allow code execution on you machine are known by hackers and actually make your PC more vulnerable
TPM/SecureBoot can allegedly be used to make your files inaccessable to you as though you were cryptojacked.
The Secure Boot code is not maintained as it should be
False. First, most of it is handled by your UEFI firmware, not your bootloader. And for the part handled by your bootloader, GRUB and systemd-boot have excellent support. Secure Boot is often used in the server/enterprise space, both of which supports financially the implementation of it.
TPM/SecureBoot is largely a Microsoft headed project
TPM standards are driven by the Trusted Computing Group (TPG), and Secure Boot is a UEFI standard.
It is a myth that both of those are Microsoft standards, they are not. Microsoft participated as a member of both consortium, but they are not leading the effort at all.
The TPM is an Oxymoron. They don't trust you with the keys and the TPM module can be hardware profiled/fingerprinted and can be tracked when you attempt to be anonymous.
The point of the TPM is two fold:
Provide a means to attest the firmware state and establish root-of-trust from the hardware upward. That's using the endorsement key hierarchy. The keys are indeed from the manufacturer for that specific key.
Act as a HSM to hold your keys. That's a separate key hierarchy called the storage hierarchy that you fully control.
Credentials that can allow code execution on you machine are known by hackers and actually make your PC more vulnerable
Everything uses assymetric encryption. Kernel images are to be signed using private keys you or "hackers" don't have access to.
This point is pure hogwash. FUD. Pure and simple.
TPM/SecureBoot can allegedly be used to make your files inaccessable to you as though you were cryptojacked.
Rolls eyes. If you:
Deliberately, as a user, use LUKS full-disk encryption.
Deliberately, as a user, setup LUKS to ONLY use a TPM backed keyslot tied to a specific PCR value.
And the PCR value changes due to a system configuration change.
Then yes. But you, as a user, deliberately made that poor choice.
EDIT: OP has replied and then blocked me. You know someone has rock solid arguments when they don't even want to discuss. Bad faith arguments as always. So I will address them here:
Most of the code is maintained by Microsoft
Microsoft doesn't write UEFI firmware, nor does UEFI Consortium publish a reference implementation. Most of the Secure Boot implementations out there are written by AMI and INSYDE CORP., the two biggest suppliers of UEFI firmware that motherboard manufacturers use. The UEFI consortium simply provides Test Tools to make sure your implementation matches the spec.
TCG does have a reference TPM implementation, but Intel is known not to use it, and AMD uses a heavily modified one.
The base code is not maintained to the level it should be and known exploits and certificate cloning have not been addressed in it for the past 5 years.
[CITATION NEEDED]. There are some certificates that were indeed leaked, and they were promptly added to DBXs as updates. An anti-cheat solution can verify that the DBXs are up-to-date by inspecting the EV_EFI_VARIABLE_DRIVER_CONFIG events of an attested log.
Yeah, the UEFI standard just favors Microsoft Software and technologies and implements their features with little or no room for competition
PCs tend to ship with Microsoft certificates as default yes. But there are plenty of other industries and other devices where Secure Boot is implemented, and no Microsoft certificates are used.
There is nothing in the specification that forces motherboard manufacturers to ship Microsoft certificates. The only reason this happens on PC hardware is that 90%+ of the user base installs Windows. There's nothing stopping you from putting your board into SetupMode, and loading your own keys.
and as an IT professional on the Windows Platform I know very well what it does
In your context, it allows you to make sure only company hardware is allowed access to company resources. That's a good thing. And yes, it does that through the endorsement key hierarchy.
Not issues with Secure Boot, but issues with bootloader software signed by Microsoft. That said, that's exactly why the forbidden database (DBX) mechanism exists: to blocklist/revoke bootloader images with known exploit. Software is not perfect.
What I was speaking of was an encrypted volumetric sytem that had trusted their keys to the TPM, and then had those keys, and I point this out that this is ALLEGEDLY, they change your passphrase and then reset the TPM thus leaving you with no way to decrypt your PC, and this is a risk of an always on PC like a server, because the passphrase has to propagate.
So you state that you are "an IT professional on the Windows Platform I know very well what it does", and you don't even understand how people get locked out specifically of Bitlocker.
That happens when:
A user doesn't know their recovery key (which is a static keyslot set in Bitlocker alongside the TPM-backed keyslot)
One of three things happen:
The user's system configuration changes in such way that (by default), PCR 0,2,4,7 or 11 changes, thus preventing the TPM from releasing the key to the OS (as the key is locked to specific PCR values)
The user deliberately resets their TPM storage hierarchy
The user changes their CPU (thus changing their fTPM).
At no point is the passphrase changed, at no point is anything syncing to a server or propagating (as the recovery key doesn't change). As for the "server" part, recovery keys on Windows CAN optionally be synced, either to Microsoft's server or to the attached enterprise Entra ID / Active Directory.
The user always has the option to add a password key slot to their Bitlocker partition using Add-BitlockerProtector, provided they have administrative access to their computer (which is not the case on business provided laptops normally).
The keyslots are only used to unlock a master data key, and that master data key never changes (as it is the key used to actually encrypt/decrypt the data).
LUKS on Linux follows a similar architecture. Keyslots are used to unlock a master key, which is then used to encrypt/decrypt data. You can absolutely have a TPM backed keyslot, and the same thing can happen to it.
And in both cases, the choice of encrypting the disk or not has absolutely nothing to do with the TPM. The TPM is only used for one specific type of keyslot, to support auto-unlocking on boot if the system is in a good, known operating state.
In both cases, TPM or no TPM slot, a software with administrative / root access can change your keyslots without your permission, locking you out of your data. The solution, in both cases, is to keep a backup of your headers, and don't trust shitty third-party software (or don't use full disk encryption if you don't see a benefit. I do, because I see the benefit).
this is a risk of an always on PC like a server, because the passphrase has to propagate
Technobabble. Why would full-disk encryption on a server be any different than on a non-server PC? What does "passphrase has to propagate" even mean? Servers often use HSM backed keyslots (PKCS#11) for full-disk encryption, backed by a dedicated HSM appliance. But from a technical perspective, it's a keyslot like any other. There is no "propagation".
Bitlocker specifically has TPM+PIN keyslots / protectors, where the PIN portion of the TPM+PIN slot can be network supplied via a DHCP field and a WDS server, but that's an entire different process, and the network administrator has the responsibility of enrolling devices and managing keys. Either way, there's also no "propagation" here; at bootup you either have the right PIN provided to you via DHCP+WDS, or you don't and the user is prompted for the PIN.
So in short, how are those Microsoft-Os you are having with your corporate breakfast, because you just seem to be eating the company line right up.
I'm a Linux-only user. The only Windows machine I have is the machine provided by my employer for work. All my Linux PCs are running with Secure Boot and Measured Boot, with Secure Boot in DeployedMode with my on CA, and no Microsoft key in sight.
False. First, most of it is handled by your UEFI firmware, not your bootloader. And for the part handled by your bootloader, GRUB and systemd-boot have excellent support. Secure Boot is often used in the server/enterprise space, both of which supports financially the implementation of it.
??? yeah that IS the issue, motherboard / bios updates might as well be not a thing for 99% of people, except for companies on lvfs
First, most of it is handled by your UEFI firmware, not your bootloader. And for the part handled by your bootloader, GRUB and systemd-boot have excellent support. Secure Boot is often used in the server/enterprise space, both of which supports financially the implementation of it.
False. Most of the code is maintained by Microsoft and the consortium that created SecureBoot, and UEFI merely implements it. The base code is not maintained to the level it should be and known exploits and certificate cloning have not been addressed in it for the past 5 years. This leaves users of it, including enterprise users, literally more vulnerable than if they hadn't used it.
TPM standards are driven by the Trusted Computing Group (TPG), and Secure Boot is a UEFI standard.
It is a myth that both of those are Microsoft standards, they are not. Microsoft participated as a member of both consortium, but they are not leading the effort at all.
Yeah, the UEFI standard just favors Microsoft Software and technologies and implements their features with little or no room for competition and if OEM's want to sell their boards as a Windows product they have to get Microsoft's approval for how they implement the UEFI. The only company that can stand up to Microsoft in that association was Apple and they just wanted to have a say in forming the new standard and it wasn't a priority. I wonder why Micorsoft was so integrated into what was supposed to be the open standard that replaced BIOS....
The point of the TPM is two fold:
Provide a means to attest the firmware state and establish root-of-trust from the hardware upward. That's using the endorsement key hierarchy. The keys are indeed from the manufacturer for that specific key.
Act as a HSM to hold your keys. That's a separate key hierarchy called the storage hierarchy that you fully control.
Hmmm, interesting but does not address what I said, and as an IT professional on the Windows Platform I know very well what it does. Now try addressing my claim instead of answering a question that was not asked.
Everything uses assymetric encryption. Kernel images are to be signed using private keys you or "hackers" don't have access to.
Deliberately, as a user, use LUKS full-disk encryption.
Deliberately, as a user, setup LUKS to ONLY use a TPM backed keyslot tied to a specific PCR value.
And the PCR value changes due to a system configuration change.
Then yes. But you, as a user, deliberately made that poor choice.
Rolls eyes... What I was speaking of was an encrypted volumetric sytem that had trusted their keys to the TPM, and then had those keys, and I point this out that this is ALLEGEDLY, they change your passphrase and then reset the TPM thus leaving you with no way to decrypt your PC, and this is a risk of an always on PC like a server, because the passphrase has to propagate.
So in short, how are those Microsoft-Os you are having with your corporate breakfast, because you just seem to be eating the company line right up.
18
u/LordDarthSaber 17h ago
Can someone explain what's the problem with secure boot enabled like I don't think thats a bad thing in general