Hacker News Reader

Comment by ChuckNorris89 | Hacker News Reader

We have to disagree here. The threat models where the security that TPM offers are mostly applicable to the enterprise and business sectors where all devices on the network/AD/VPN have to be trusted and their storage encrypted. There TPM makes perfect sense.

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)

View on HN

To give an example harm caused by the TPM / disk encryption feature in the consumer space: A recently-deceased friend's wife contacted me about getting personal data off from her late husband's computers. I ended up being able to get nothing for her.

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.

I'm sorry for your loss, but did your friend not have a right to privacy just because he had dementia? Should we be building dementia backdoors into all our platforms' encryption systems? What about cases where people are estranged from their spouses?

As I said, it wasn't handled well. I don't think we should be building backdoors into secruity systems. I also don't think my friend explicitly requested the functionality or would have understood the ramifications even if he did.

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.

This is similar to why enabling 2FA actually scared the heck out of me! I use a password manager to generate strong unique passwords, so I think the chances of someone getting in that way are incredibly low. But I can absolutely see myself loosing all of my 2FA keys some day in a freak accident.

Nowadays the password managers can store the 2fa secrets and generate the codes as needed.

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.

Nowadays 2FA are always about something you know and somebody that vouches for you (SMS, email, whatever). Nobody seems to do any version of it that relies on you alone. So a password manager won't improve its reliability.

You are supposed to store the recovery key(s) in a secure location. Then if you lose your 2FA device, you can reset your 2FA from those recovery keys.

What secure location? My sock drawer? Or am I expected to go buy a safety deposit box? I'm really not that organized and I loose slips of paper all the time, it's a major reason I was drawn to computers growing up.

I keep mine in a file in a drawer. My threat model doesn't cover people breaking in and finding them as well as knowing my password managers master password.

Sock drawer, wallet, locally on your computer, wherever. If the recovery keys are compromised, that really just downgrades your 2FA back to 1FA.

I’m not concerned about the keys being compromised, I’m concerned about loosing them, since the idea is they’re unneeded for many years and then suddenly become essential.

This seems like a plus not a problem.

If you can log into his microsoft account on the internet, you can recover the bitlocker key from there if his account on his machine was a microsoft one

> (The Windows accounts on these machines are local accounts so the Bitlocker recovery keys weren't saved on Microsoft's servers either.)

Reading the comments, before posting, helps.

Did he enable a boot pin or are the drives just encrypted?

The drives are encrypted without a boot PIN. If I could exploit a vulnerability in the OS I could get the data. There will probably be a vulnerability discovered, at some point, that will allow access. I'd advised my friend's widow to hold onto the computers for the time being.

Please also advise her to power it on every 2 or 3 months or so (and leave it running for a bit), so that SSDs continue keeping the data, and HDDs don't get "stuck".

Just as long as she can keep it from connecting to the internet.

This assumes that home users don't have any data worth protecting. I think that's a ridiculous thing to assume.

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?

What about the scenario where your laptop is stolen and the attacker reads your data off the disk? All modern mobile devices protect against this scenario by default, but Windows devices required additional configuration to be protected.

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 when has it ever been the case that it prevented you from installing Linux?

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.

>And in fact Secure Boot does protect against Grandma being infected by boot-time malware.

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.

> 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.

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.

>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.

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?

I agree that the process could be more straight-forward, especially as, from what I read, some computers may need some coaxing into changing the keys.

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.

> Can't remember last time I saw this type of malware in the wild.

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.

That branch of malware was already rare when uefi secure boot was introduced.

> 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.

It hasn't been mandated at all. A number of years ago, Microsoft made headlines by changing their policy to get rid of that mandate. See https://arstechnica.com/information-technology/2015/03/windo... . Microsoft's page at https://docs.microsoft.com/en-us/windows-hardware/manufactur... says that you can "usually" disable it, so I don't think they've changed their policy since then.

> And how can grandma get boot time malware at Home?

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.

Can you please provide some sources for JS ad-based boot time malware you mentioned that one can get off the web?

Usually JS part it's just exploit that is just a first step. After there is compiled and native "loader" malware that required to setup actual trojan / rootkit.

Reply on news.ycombinator.com