> From: Nico Kadel-Garcia [mailto:nkadel@xxxxxxxxx] > Sent: Wednesday, December 29, 2021 2:06 PM [...] > > With Windows 11, they're *mandatory*. Corporate policies now > > effectively *require* TPM-based mechanisms *in addition* to classical > > password or token-based multi-factor authentication. > > As often occurs with DRM. it's proven burdensome and there are > numerous published workarounds, including those published by > Microsoft. > > Can you point to a particular multi-factor authentication technology > that uses TPM? I'd not seen that in any server based setups, though I > could believe it exists for portable devices which support less > development. It's a problem partly because TPM puts private escrow > keys in the centralized hands, and the root keys to revoke other keys > in manufacturer's hands. The key management, and signature authority > management, is a problem. I'd be concerned at yet another attempt to > re-invent the security wheel, and secrete the wheel itself away in the > kernel without direct visibility to the user running or writing the > software. The TPM has a fundamental advantage, compared to other mechanisms. It is tamperproof, it often receives high-grade certifications, and it is one of the few components that you could rely on to protect your sensitive data in the event your host becomes compromised. The fact that the TPM might be used for DRM does not preclude its usage for the users themselves. The TPM technology is not meant to secrete the wheel, but rather the opposite. For example, it might help to detect tampering of audit logs by attackers trying to cover their tracks. The TPM has a very simple logic: record a security-relevant event before it happens, or do/release something if the system is in the condition I have myself defined. The TPM might not be even required if you like to enforce an IMA appraisal policy. The built-in and secondary keyrings in the kernel will act as your trust anchor. > > The difference between IMA/verity and DRM is that the former is under > > the system owner's control (in this case, *you*), and the latter is > > *not*. > > Since IMA is oriented to third party vendor keys, according to its own > documentation, I don't see how this would be. It would be easier, and > more visible, for signature validation and verification to occur in > userspace. There are old tools that attempted to provide such > validation for system files, such as "chkrootkit". and for which I've > provided up-to-date bundling. It would be a design problem. You cannot put a component at the same privilege level of the components you are defending against. > The work of signing and validating one's own data or software files is > so large, I don't see the benefit of embedding it in the kernel except > to enforce it for DRM use. > > > While Palladium as a whole hasn't *yet* made it, huge chunks of it > > has. Verified and measured boot mechanisms exist in Windows and macOS, > > remote and local attestation for integrity exist for Windows, and so > > on. Some of these features exist in Linux, but not all just yet. > > Nor should they, precisely for "free software" reasons. Palladium was > an attempt to provide a hardware verified, vendor signed stack from > boot to kernel to software to data files, all under the authority of > third-party generated signatures which could be revoked, at whim, by a > more root level authority, and which could be revoked or even turned > over from escrow at whim with no published procedure for when and how > such keys would be turned over. I'm concerned that these third-part > keys will suffer similar vulnerabilities. For IMA appraisal, there will be no keys in the kernel other than the ones your package manager uses to verify the integrity of the packages you install. Plus your own keys, if you wish. That would be sufficient to run any free software. Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
