>purely arbitrary
As if years of experience hasn't taught us that opt-in security is stupid. This would be arbitrary if the TPM was useless, but it isn't.
As if years of experience hasn't taught us that opt-in security is stupid. This would be arbitrary if the TPM was useless, but it isn't.
You average consumer/home user does not benefit at all from the features of TPM since they're not subject to the same threat model. Here TPM, and also stuff of the UEFI security chain like Management Engine and Secure Boot in the past, act more like hostile wall-gardening that limit what a user can install on his system (remember how enabling secure boot originally meant you couldn't install any linux distro?) rather than add any meaningful security (will TPM and Secure Boot prevent grandma from getting her PC infected by malware off some shady phishing site? No? Then don't force those requirements for private users)
My friend, no doubt influenced by dementia and paranoia he was feeling, changed the passwords, made no note of them, and subsequently died. The computers in question run Windows 10 using Bitlocker and key storage in the TPM.
The data is effectively gone. I believe he was using encrypted backups to a "cloud" storage provider, too, but I'm also fairly certain the key is only on these computers. (The Windows accounts on these machines are local accounts so the Bitlocker recovery keys weren't saved on Microsoft's servers either.)
Matters were arguably handled poorly on my friend's part prior to his becoming of unsound mind. He wasn't terribly technically savvy and I'm not sure he considered the "losing my own mind" threat model. Nonetheless, it adds insult to injury that Bitlocker, which added no security for his day-to-day use, effectively caused the loss of his data.
Reading the comments, before posting, helps.
Bitlocker is, apparently, enabled-by-default on consumer machines that, I'd argue, don't suffer from a threat model that necessitate its use.
There is a huge problem with technical and legal constructs associated with the rights to accounts and data after death. I don't have the answers for everybody. I've done what I can for myself and my immediate family.
The "I've lost my mind and undermine efforts I made, while still in my right mind, for successors-in-right to access my data" is one that I'm not sure how to defend against, and one that scares the willies out of me. I can document my last wishes but if I, in a fit or paranoia, change keys / passwords / remove recovery mechanisms, then those last wishes might be irrelevant.
It kind of defeats the purpose of the second factor -- the password manager becomes it -- but at least it makes the services that insist on it happy.
And in fact Secure Boot does protect against Grandma being infected by boot-time malware. And when has it ever been the case that it prevented you from installing Linux?
And how can grandma get boot time malware at Home? IIRC those were common back in the days when people were plugging in infected floppy disks or thumb drives everywhere and you'd try to boot off them. Can't remember last time I saw this type of malware in the wild as phishing and ransomware is a lot more profitable for malicious actors than boot time malware.
>And when has it ever been the case that it prevented you from installing Linux?
This was always the case ever since secure boot launched and any OS that didn't have it's first stage bootloader signed by Microsoft could not boot. Even To this day, to install arch or puppy on my XPS i had to disable secure boot. Ubuntu and other major distros are fine here though but this gate keeping doesn't make it ok in my book.
That's exactly because widespread secure boot has made it impractical!
As for niche Linux distros, it's been mandated since the beginning that you can install your own Secure Boot keys on Microsoft certified desktop platforms.
> it's been mandated since the beginning that you can install your own Secure Boot keys on Microsoft certified desktop platforms.
...on x86; on ARM they mandated that the user couldn't install their own keys, which shows that they will lock users out as much as they think they can get away with.
But this is kind of a circular problem, isn't it?
If everyone's bootloader is signed and recognized by every Secure Boot implementation, then signing is useless since it doesn't afford discrimination between "known good" and "dubious" bootloaders.
I'm not familiar with XPS computers, but to me what's important, as another sibling says, is that the user be able to load their custom keys with which they sign their own bootloader. This is how I run Arch on my HP computers.
This way, I can be reasonably sure that when I boot my arch linux, it's actually mine, and not some random live medium based of arch's (or whoever's) install disk that will sniff my passwords or whatever.
To me, this is what SecureBoot is supposed to offer, and I don't see how you would implement this if you could easily get anything signed and accepted by most PCs.
Like I said above, this and stuff like management engine and TPM makes perfect sense in the enterprise environment where the owner of the device (the employer) is different than the user (the employee), so IT needs to strictly control what's running on the devices they trust on their infrastructure, but why should we expect home users to have to sign bootloders to use whatever software they want as they're both the users and the owners of the devices and the network infrastructure in their homes?
But the thing is that, like it or not, most people simply don't care enough, so they'll just use Windows. I remember a while ago, when there were many live CD-based distros and there was no such thing as SecureBoot, people wouldn't even be curious to give Linux a spin. All it would have taken was to pop a CD in the drive and boot up. To paraphrase another commenter, I think many people feel the same way about their PC as their washing machine: just another appliance. Of course, lock-down platforms don't help instill curiosity in people...
So you get, roughly-speaking, two populations: those who care and those who don't. And usually, those who do care are curious enough to follow a few simple steps to disable SecureBoot for the installation and then set up their own signing process.
But I stand by what I said earlier: the process cannot be fully automatic, or it defeats the purpose. But I do think that willingly making it a pain is wrong.
Depending on the demographic, they can: get caught up in during some (possibly unrelated, likely automated) attack, click the wrong ad, or load the wrong common page with JS.
There was a window, when shim.efi was not signed.
> And in fact Secure Boot does protect against Grandma being infected by boot-time malware.
When it was the case that grandma was infected by boot-time malware? One-half-like malware happened decades ago, and under windows they need administrator rights anyway.
IME does not affect your average user at all, so I'm not sure why you'd bring that up.
>remember how enabling secure boot originally meant you couldn't install any linux distro?
A lot of people were spreading this FUD back when secure boot was being introduced. It was a lie back then, it is a lie now.
> rather than add any meaningful security (will TPM and Secure Boot prevent grandma from getting her PC infected by malware off some shady phishing site? No? Then don't force those requirements for private users)
Secure Boot essentially killed off bootkits, that's a significant achievement. Perhaps you should learn what these technologies are actually used for before attacking them?