When the proprietary software industry is already using technology, I don't think we benefit by refusing to touch it ourselves. We can use this tech to lock down devices that are better off locked down, and where we're not violating user freedom in the process. We can use this to make it harder for activists to have their machines seized and compromised in a way they can't detect. Refusing to do the good things isn't going to slow down the spread of the bad things.
We can use this to make it harder for activists to have their machines seized and compromised in a way they can't detect.
This argument is often-made and I hate it because it advocates destroying the freedom of many just for the needs of a tiny minority --- and if a nation-state is going after you, it's pretty much game over unless you can create your own hardware.
Refusing to do the good things isn't going to slow down the spread of the bad things.
Maybe to you it's a good thing, but to many of us, that is the equivalent of giving Big Tech the noose and saying "don't put it around my neck!" (The saddest part is how many will happily work in these noose-factories, either oblivious to or convinced that what they're doing is "good".)
Am I missing something? This seems to be incorrect, this is explicitly a case where you, the hardware owner, controls the signing keys. It's nothing like DRM, that is a case where an outside person controls the keys.
You mean... The last decade or so? Pretty much Mobile period sans the Librem 5 and I think maybe one other? Anything with an ARM chip that'll run windows must be secure booted and signed by Microsoft.
Or how about Nvidia(mostly)/AMD(to a lesser degree) video cards, where the entertainment industry increasingly relies on cryptographic attestation to constrain what people can do with hardware they bought? There is no "fully unlocked" buying option, and trying to divest yourself of Nvidia is impossible while being able to use your card to the fullest.
Or John Deere with their crippled hardware as a service model?
I'm all with charging for convenience. That's a value add. I'm not cool with intentional crippling, and extortionate practices whereby the manufacturer maintains ultimate control after first sale either legally or practically through privileged access to signing keys.
Just look at how fast the industry flipped over from dumb TVs to smart TVs, a similarly competitive and low margin market. I haven't been able to find a dumb TV at a big box store in years and the only options left are for commercial signage displays that command a large premium - largely made by the same brands that make the smart TVs.
I have a Pinephone myself but Android and iOS have already sucked all the oxygen out of the room - it's still nowhere near ready to be a daily driver and it's a decade plus late to the party. I got a small open source 3G cell tower for development years before the Pinephone even hit the drawing board.
Absolutely no web presence outside of (essentially) a brochure and email complaint form. I thought about complaining but I really don't care enough.
I think all the devices that provide more security by being heavily locked down should basically have a tinker switch. If you really want to write your own firmware for your phone or your dishwasher, flip it to tinker mode which locks you (maybe permanently) out of the software it shipped it and let you flash whatever on to it. The manufacturer gets to waive all responsibility for your safety (digital, physical, etc.) from that point onward.
Bonus points if it just blows away the keys to the onboard software so you can use the security mechanisms for your own code.
(And by the way - remotely exploitable dishwashers? What the heck is the world coming to?)
All I imagine is someone running their own firmware on an appliance, doing some unseen damage, and then reverting to the onboard firmware and getting hurt. It would be a field day for lawyers.
I completely agree that this sucks and it's the same reason robotics has proceeded at a snail's pace. God forbid making a Roomba with a more powerful vacuum, what if it ran over someone's toe.
I am not super mad if I have to run my custom kernel in a VM. It substantially reduces the surface area exposed.
For example voting machines should be done in this way. Open source software such that outsiders are able to verify + a secure boot process such that anyone can verify that the machine is really running the code it is supposed to run.
Of course we should all still be very careful of what we accept in terms of control of our hardware. And I agree with you that things are not moving in the right direction there, with locked ecosystems everywhere.
I think most people would prefer no voting machine software at all, seeing how most people can not "verify that the machine is really running the code it is supposed to run" but can indeed verify a paper ballot.
And of course signing a huge code bundle is the farthest possible thing from "run exactly the software you think it runs". Console manufacturers keep learning that. You really wanted to run that WebKit version that turned out to instead be a generic code execution widget? Think again.
The reason I bring it up is that one of the benefits of open source that is often mentioned is the ability to verify that it does what you think it's doing. Doesn't matter whether it's a voting machine, a self driving system or an ATM or whatever. It's still good for open source to have the capability to do this kind of proving in cases where you want it.
The majority of people, with normal sight and no mobility impairment, may be fine with paper ballots. But for some of us, an accessible voting machine is more than a convenience, as it enables us to independently (and therefore privately) cast our votes.
Even a mobile app to guide blind users on the ballet would be more secure.
Basically excludes any black box machines, block chain, cryptography and any existing computers.
Software is already here, particularly in social media (mastodon/SSB vs Facebook). That hardware eventually gets there seems to me an inevitability (arguably we're already at least partially there, as evidenced by the fact Purism/Pine64/etc exist).
I still don't see it as a problem, though, because an individual can have different technical interfaces (devices, OSes, etc) for different purposes.
Generally, I put my personal stuff on systems I understand/control.
For some things, like watching TV, I'm okay with going to Netflix because that transaction is expected to be transitory. If Netflix disappears or declares themselves a new world order tomorrow, I can simply unsub and no harm done.
Where things get problematic is when so much of someone's life is wrapped up in a mono-corporate cocoon (e.g. Amazon shipping things to your house and running your servers, or Google serving you search results + mail + maps).
So much for your $1000 TV that had Netflix and only Netflix builtin, and will refuse to boot when the cryptographic check fails becaused you changed the string that points to http://www.netflix.com to http://www.notnetflix.com
But your TV manufacturer still wants to provide Netflix to other users and Netflix decided to require all their devices to run its trusted code if they want to provide Netflix to anyone, whether you in particular want it or not. So your choice is to trash your existing TV and track down a manufacturer that doesn't have any support for Netflix, Hulu, Youtube, Amazon Prime, etc. at all to buy a new TV that doesn't ignore your choice. With TVs you might be lucky since there is a large market for dump displays that avoid any TV related functionality anyway, of course there might be restrictions in the license between Netflix and the TV manufacturer to close that loophole too, maybe limiting sales of dumb displays to specific types of users.
What more to want from a security perspective? In-device protection from flashing? Sounds similar to security through obscurity. I'd prefer easy ways to check what a device is flashed with. Something like a checksum calculator device. Not sure if that's a reasonable idea.
Out of band firmware validation is a real thing (Google's Titan sits in between the firmware and the CPU and records what goes over the bus, and can attest to that later), but that's basically just moving who owns the root of trust, and if you don't trust your CPU vendor to properly record what firmware it executes you should ask whether you trust your CPU vendor to execute the instructions you give it. Pretty much every option we currently have is just in a slightly different part of the trade off space.
I looked into TPM stuff a few years ago, and it all seemed pretty useless to me.
First of all, the entire key-protection house of cards relies on the assumption if you've booted the right OS, the keys can safely be unsealed. But the TPM does nothing to protect from security issues beyond that point, which is the vast majority of security issues.
Second of all, if you're worried about someone snatching your laptop or phone, full disk encryption where you type the password at boot gets you 99% of the protection with much less complexity. And the much lower complexity means many fewer places for security bugs to be accidentally introduced.
Third, if you're worried about evil maid attacks where someone dismantles your laptop and messes with its internals without you knowing then gives it back to you, then the TPM isn't sufficient protection anyway. They can simply put in a hardware keylogger, or get direct memory access, in which case it's game over anyway.
And fourth, the TPM doesn't have a dedicated hardware button (making it a shitty replacement for a U2F key) and doesn't have an independent clock (making it a shitty replacement for TOTP on your phone) so it's not even a good replacement for other security hardware.
About the only use I can see for this stuff is if you're some huge multinational company, and you think even the authorised users of your computers can't be trusted.
>the TPM does nothing to protect from security issues beyond that point, which is the vast majority of security issues.
I hear this type of thing often but it's the wrong mindset to take when dealing with this stuff. Security holes in one part of the stack are not an excuse to avoid fixing security holes in other parts -- if you do that, you now have multiple security bugs that are going unfixed.
>And the much lower complexity means many fewer places for security bugs to be accidentally introduced.
This doesn't seem to make any sense, avoiding securing the boot process does not mean the boot process is any less complicated or somehow has less parts that can be compromised. TFA is just describing how to secure the parts that are already there.
>They can simply put in a hardware keylogger, or get direct memory access, in which case it's game over anyway.
I'm not sure how this is related, building a tamper-proof case seems to be outside of the scope of this. This seems to cover only the software parts.
Of course it does: Not only does secure boot add an extra point of failure, it's a point of failure that's specifically designed to be highly sensitive, and to fail locked, and that hardly anyone in the kernel development community is testing with.
> I'm not sure how this is related
From a computer owner's point of view, the TPM's secure boot functionality exists only to protect against attackers with physical access to the device. After all, if a malicious attacker making a remote attack has the ability to replace your bootloader or reflash your BIOS, they've already got everything.
In other words, secure boot is there to protect against an evil maid [1] removing your hard drive, replacing your bootloader with one that logs your full disk encryption password, then subsequently stealing your laptop and password at the same time. Or something of that ilk.
However, the TPM is insufficient to protect against such attacks.
As such, secure boot fails to provide the one thing it claims to provide.
A serious system - like the xbox's security system - (a) has the functionality on the CPU die, and (b) has the hardware for full speed RAM, bus and disk crypto, all with keys that are inaccessible to the OS.
>However, the TPM is insufficient to protect against such attacks. As such, secure boot fails to provide the one thing it claims to provide.
I don't think anyone is saying TPM or secure boot alone is going to prevent against such attacks. It needs to be combined with some other physical protection measures, e.g. a tamper-proof case of some kind.
I had issues wrapping my head around this as well with regards to things like Network Boot etc, where I could not for the life of me understand or justify a boot process having a runtime capable of doing all this extra cryptographic/network nonsense when all I bloody wanted was my OS, up, now.
Not to get nostalgic, but that magical era for a user around Windows XP with a <5 second boot was just that; magic.
I know all the oldtimers will come out of the woodwork with horror stories of competing, sloppily specified BIOS implementations, the pain of malware hiding in CMOS, the threat of rootkits, etc... And the admins will chime in with "How do you expect me to power on the thousands of servers in my datacenter without network access during boot"?
Those are valid and real situations in isolation I can stomach. I cannot, however, stomach a boot process whereby a non-owner arranges things in a way where it is guaranteed that they get the final word in deciding how hardware you paid for is used, which requires the composition of those services.
xboxes and iphones don't need tamper-proof cases.
edit: the only people who think that being locked-down is a feature are rationalizing technologists who indirectly profit from that arrangement. It's not even more secure. The methods used to control locked-down devices (namely constant network connections and cloud storage/control) are the most vulnerable attack surfaces we have, and the source of virtually all contemporary security disasters.
It just means that you can be sure no one else has tampered with your device.
To me it seems very silly to not follow this line of thought just because someone in the future might use it lock out hackers. This is like leaving bugs unfixed because someone might have a use for it.
I tried to simply disable "secure boot" in the BIOS settings and then the boot loader just did absolutely nothing. Hot fucking garbage.
Apparently, if you have "secure boot" available during the install it will use "secure boot" without any way to opt-out.
You might also try signing the kernel module yourself (the manual method at the bottom of that page)?
Without free software implementations of secure boot et al. all this would just happen behind closed doors. At least with this the field progresses and you'll have the tools to secure your own applications when the right project comes.
> What good is having all the source code in the world if I can never put my (or anyone else's) modifications to it into effect?
Well, it'll be more difficult to get pwned, for one.
But you don't own (for example) Netflix. So Netflix can exclude you if you use your computer in certain ways, right?
i.e. if you refuse to use a secure boot infrastructure and do remote attestation of the trust chain to Netflix, they can refuse to provide you service - obviously based on the assumption that this was all made clear to when you signed up.
I try not to whip that out because it's all fun and cool til they do somethimg you don"t like.
Ironically TiVo is long gone from living rooms.
The iPhone is locked down, consumers buy 5.5 Android phones for every 1 iPhone. But rich users buy iPhones, and they also buy software, so...
What good is having all the source code in the world if I can never put my (or anyone else's) modifications to it into effect?