Hacker News Reader

Comment by c0l0 | Hacker News Reader

While I find this post and the ideas presented very interesting on the technical level, work in that direction ("remote attestation", making devices "tamper-proof") tends to give me a dystopian vibe - foreshadowing a world where there's no hardware left you can hack, build and flash your own firmware onto: Complete tivoization, to re-use lingo from when the GPLv3 was drafted. With that, really neutering all the benefits Free Software provides.

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?

View on HN

You're not wrong, but unfortunately those of us on the side of free software aren't the ones driving most technology decisions. This technology already exists, and if people want to use it to lock us out of our own hardware, they can already use it to do so. Right now we're partially saved by remote attestation on x86 systems just being too complicated (and, basically, too privacy violating) to deployed in a way that could be used against users, but this is basically what things like Safetynet on Android are doing right now.

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.

Development work is expensive. A cheap turnkey way of building a locked-down, remote-attesting distribution is going to make the bad things cheaper and more common. I'm sure proprietary developers would get there eventually, but this is one class of software where I think publishing a stable, bug-free implementation that anyone can use does more harm than good.

How? You can use this to secure your own devices from tampering. Lots of (cheap) devices are already locked down like this, would it really help to deprive yourself of the capability to secure your own devices too?

Many people want contradictory things and loudly ignore the contradictions.

It's been already done many times. You can lock down your own machine from scratch in a couple of days with no prior knowledge. There's really nothing to hide and all elements of it are useful in their own right.

Yes, and you only need this at the root hypervisor level, once peripherals can be abstracted in a new way (maybe DMA at a different privilege level, certain hardware features would be required).

I am not super mad if I have to run my custom kernel in a VM. It substantially reduces the surface area exposed.

Heh, Safetynet is consistently fooled by Magisk's hide-root option, so is it really doing that?

Yeah, on devices without hardware attestation. Which is now the new normal on all phones sold. When the software route inevitably gets disabled and you can no longer fool google into believing you dont have hardware attestation you are done for good.

I am completely against any form of this technology, just like DRM, because it breaks the concept of physical ownership.

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

>it breaks the concept of physical ownership.

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.

The problem is now that this exists and is easy to set up, it's easy for the manufacturer to make a device where they're in control of the keys forever instead of the eventual owner gaining control.

So don't buy that device? Those devices already exist, that doesn't prevent you from buying other devices where you control the keys. If manufacturing an unlocked device becomes unprofitable and stops happening everywhere, then we can talk about what to do, but I don't think the existence of secure boot on Linux is going to make much of a difference either way.

>If manufacturing an unlocked device becomes unprofitable and stops happening everywhere, then we can talk about what to do, but I don't think the existence of secure boot on Linux is going to make much of a difference either way.

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.

So.... don't buy those devices? I have a pinephone myself, I don't really use GPGPU, and all the farmers I know buy tractors from other companies.

It's a race to the bottom - or the top depending on how you look at it. Unless right to repair laws cripple their attempts, companies like John Deere will be able to use their lock in to wring ever more revenue out of their customers. That extra revenue, even if marginal in the grand scheme of things, will drive improvements in their hardware and software that competitors will have to match, most often by implementing the same tactics as John Deere (why not, when JD has already proved them? an MBA will say). Agriculture is already an industry forever on the razor's edge so any short term competitive advantage in yield or even up front capital cost will rapidly outweigh any medium to long term maintenance issue for farmers that live from loan to loan.

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.

That's just making their argument for them. What is the argument in favor of them making unlocked devices? Can it be done while increasing their profits?

More and more services require Android/iOS, either with Google services, or they even detect and block users with rooted devices/custom firmware such as LineageOS (for example Revolut). So far, one can go without them, with some inconvenience, but it's getting progressively worse.

There's some startup (maybe a ycombinator one) that "provides online meeting places for apartment communities." The managers of the building I live in have been pushing it pretty hard. I went to join it the other month because it's always good to socialize some.

Absolutely no web presence outside of (essentially) a brochure and email complaint form. I thought about complaining but I really don't care enough.

Sorry, but the future of computing is secure attestation of everything the CPU runs -- from the boot firmware to end-user applications. In the open source world we have two options -- we can either get on board with this or we can fight it and lose.

I personally don't dislike the concepts of trusted computing. As much as I love to tinker with things, the last thing I want is some data appliance being remotely exploitable.

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.

That's still very consumer-hostile. How am I supposed to write a replacement firmware for my dishwasher if I have to brick it first? I have dishes to wash! I'm not gonna buy a second dishwasher for development purposes. Why can't I test it against the native firmware?

(And by the way - remotely exploitable dishwashers? What the heck is the world coming to?)

I was just thinking of the extremely litigation happy culture in the US. We literally have thousands of highway signs in cities saying that if you were in an accident, call us and we'll sue the person who rear ended you.

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 think the technology itself is great to have in the open source sphere. There are many valid reasons to want to have a system that is both open source AND cryptographically proven to run exactly the software you think it runs.

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.

But nothing here is cryptographically proven. Remote attestation ala Intel SGX is an opaque black box that comes down to trusting Intel.

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.

TPM-based remote attestation doesn't involve SGX at all. If Boot Guard is enabled then you're trusting the ACM to perform its measurements correctly, but that's a not overly large amount of code that can be disassembled and verified.

Sure, you can prefer paper ballots, but that's just one example.

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.

> I think most people would prefer no voting machine software at all

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.

Keep it as a secondary option then? Or, at worst, have every state or county independently write the software for their machines so they won't all be compromised. A scalable way of breaking an election is dangerous.

Even a mobile app to guide blind users on the ballet would be more secure.

A machine could fill out the paper ballot in these cases.

If you don't trust the CPU vendor, a solution there would be to buy multiple CPUs from multiple vendors, run the same thing on all of them, and compare the results. You would still want them all to have the equivalent of SGX.

I have yet to see a digital voting system that a grandma with 0 digital literacy can dream of trusting. That's my standard for digital voting.

Basically excludes any black box machines, block chain, cryptography and any existing computers.

Why can’t we have both? General-purpose computers for whatever-we-want, and single purpose devices from a trusted source which we can be more confident are untampered with?

I've not thought this through extensively, but couldn't you just flash signed firmwares onto those "single-purpose trusted devices"? If they were open to flashing that is.

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.

There's a bunch of cases where you want these devices to be resilient against attackers who have physical access to the system. That means it has to be impossible to simply re-flash them given physical access, unless you can detect that this has happened. That's what the trusted boot side of this is - it gives you an indication that that reflashing has occurred.

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.

> There's a bunch of cases where you want these devices to be resilient against attackers who have physical access to the system.

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.

Just some small notes/nitpicks...

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

> avoiding securing the boot process does not mean the boot process is any less complicated

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.

[1] https://en.wikipedia.org/wiki/Evil_maid_attack

I don't understand what you mean extra point of failure. There is a boot process, you can't get rid of it because then you can't boot the machine. So you either secure it or you don't. I get the concern that the hardware implementation could contain bugs, and that's a real concern, but your system is not going to be less secure by having this -- at worst, it seems it can only be as insecure as it would be without it.

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

Likely what they are referring to is how UEFI has greatly complicated the nature of a computer's boot process by essentially inserting a firmware runtime into what was a simpler to understand chain of POST->Hand off to program at address.

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.

> It needs to be combined with some other physical protection measures, e.g. a tamper-proof case of some kind.

xboxes and iphones don't need tamper-proof cases.

Note the term "appliance" in the submission title, and "single-purpose trusted devices" in the comment chain you replied to. General end-user desktop devices like your laptop indeed aren't that high on the list of use cases, at least not without further development in other areas. (although I think you are somewhat skipping over the part of being able to protect secrets stored in the TPM against being requested by an unverified system)

Copyright owners will push for the later, maybe even take a page out off Googles Play store licensing and outright prohibit hardware manufacturers of even dreaming about producing a device that doesn't enforce their draconian requirements. So hardware manufacturers get the hard choice of either going for the general market that expects things to work or going for a tiny market that is happy with some of the most popular services not working by design.

> So hardware manufacturers get the hard choice of either going for the general market that expects things to work or going for a tiny market that is happy with some of the most popular services not working by design.

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

> I can simply unsub and no harm done.

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.

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

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

Or when Netflix refuses to continue supporting their app on your device and so you are forced to upgrade, despite your device still being fully capable of running video streaming (like the Wii, and probably soon the PS3 and Xbox 360)

You can still do both. Just allow the user to blow a fuse, and from then on the locks are removed.

People will not willingly buy a locked-down device over an open device, all other things being equal. So general purpose devices will not be made available, so that locked-down devices will sell.

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.

I sorely wish you were right, but the success of companies like Apple seem to indicate otherwise. I won't buy a locked-down device, but for every person like me there are thousands who don't care.

This is a perfect example of survivor bias. OSes are secure now, so attacks that succeed attack the sxurit system.

Being able to verify that your program runs on authenticated firmware does not mean you can't modify the firmware or the software running or replace it with something else.

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.

The user being able to verify things isn't the issue, the issue is somebody else being able to verify things, perhaps even requiring verification. This can even be extended (and already has been) to where binaries can be supplied in encrypted form and run on a processor that never reveals the unencrypted code to its user.

Who cares? Then you just wont hack that device

The question with secure boot is who has the keys. As long as that's the end user it is awesome.

Which is why every trusted computing platform with free software on it should have an owner override. (The total count of such platforms is, as far as I know, unfortunately zero.)

Pretty much every x86 system with a TPM and UEFI Secure Boot can have the secure boot keys swapped out by the owner.

I recently went to write a kernel module on my Ubuntu system, only to discover the boot loader now defaulted to "secure boot" nonsense and I couldn't insmod a non-signed module.

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.

Did you try disabling it in shim-signed instead of the BIOS (method 2 on this page [1])? I'd expect that to be more consistent and/or reliable since BIOS quality can vary a lot from vendor to vendor.

You might also try signing the kernel module yourself (the manual method at the bottom of that page)?

[1] https://wiki.ubuntu.com/UEFI/SecureBoot/DKMS

I don't want to do any of that. I just want to insmod a module like I've been doing since 1995.

While the use case of secure boot is often anti consumer/end-user, there are many applications that make sense to have attestation (yubikey type embedded projects, etc)

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.

I know this is going to be an unpopular opinion, but if a service provider wants to support only specific clients which have a rigorously-managed supply chain of their hardware/software, then that's up to them.

I buy a computer I own that computer there should be no strings attached.

Yes; sure.

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.

The 'ole "they're a private business, they can do what they want" defense.

I try not to whip that out because it's all fun and cool til they do somethimg you don"t like.

> Complete tivoization

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

Reply on news.ycombinator.com