undefined | Better HN

0 pointscomex11y ago0 comments

I don't know why people are portraying measured boot (i.e., allowing the TPM to prove that your system is running some particular set of code) as unilaterally good. Remote attestation was one of the key parts features of trusted computing that people got up in arms about back in the way[1]. After all, in theory, it could be used to enable DRM that is very difficult to crack, making it more difficult to make fair use[2] of videos and other files one has access to. I admit that it doesn't seem terribly dangerous in practice; the portability problems that have prevented remote attestation from being used for DRM in practice on existing hardware are not affected by the TPM chain of trust getting shored up, and the Windows kernel is never going to be anywhere near unhackable. (Instead, DRM on PCs is probably eventually going to use Intel SGX, which allows protecting a userspace process without having to trust the rest of the system, making trusted boot unnecessary; but a harm is not well justified by the existence of a greater harm.) And on the flip side, using TPMs to secure user data against attackers sounds like a very nice feature, especially given the level of sophistication of the threats some people face these days. So I agree that in a cost-benefit analysis, having measured boot is better than not, and it may as well be properly secured. But there is a cost-benefit analysis to having it; it's not pure good.

[1] https://www.gnu.org/philosophy/can-you-trust.html

[2] I don't mean fair use in a strictly legal sense, because I live in the US where the DMCA forbids breaking DRM even for what would otherwise be fair use under copyright law; but I think it should be fairly uncontroversial that doing so is moral.

0 comments

4 comments · 2 top-level

geofft11y ago· 2 in thread

Something that occurred to me recently about the cost-benefit analysis:

Historically, hackers have been very good at taking software that was meant to be secure, and breaking it. As you point out, the Windows kernel was never going to be unhackable. iOS (iPad/iPhone), which is arguably the state of the art in walled-garden verified boot with hardware support, has been reliably jailbroken.

Historically, hackers have been very bad at writing software that was meant to be secure, and keeping it secure.

I'm a lot more confident in our ability, as the hacker movement, to destroy any DRM scheme that wants to use a TPM than to successfully make a general-purpose OS that keeps someone's files secure. And that worries me. If these two were somehow a direct tradeoff (which they're not), I'm pretty sure I'd prefer a world where DRM worked but security breaches and malware weren't an everyday occurrence.

comexOP11y ago

As someone who's spent a good amount of time hacking various devices, I have an odd split mind on security. I detest activities such as those of the NSA and more traditional malware authors and think it would be great if people could trust their computers (never mind that I like sci-fi and wonder whether we will sort this out by the time computers store people's brains and whatnot). But then there are cases like iOS where compromising the system really can be for the benefit of users... but iOS vulnerabilities can be and are used for nefarious purposes (in fact, one of the recently leaked documents mentions that the NSA once used one of my jailbreaks), and jailbreaking has become necessary for fewer and fewer use cases over the years - if I want an open system so much why don't I switch to an Android phone that I can unlock legitimately, without depending on vulnerabilities? It doesn't seem like there will be a scarcity of those in the near future... Should I feel proud of having gotten vulnerabilities fixed by using them in jailbreaks, or guilty that I attempted to maximize rather than minimize the exposure window? And then emotionally, there's a big part of me that always roots for things to be insecure, since hacking is fun and represents a fairly big part of my life. I think I should take joy in the prospect that I might become obsolete (especially since that won't happen for a long time no matter what I do :p), but it's hard to actually feel that way.

Anyway, there are a few recent developments which make me feel somewhat anxious, which I guess means they're good. Among them are Rust and seL4.

Rust, which I'm quite enthusiastic about when not in a hacking mindset, could be one of a few languages that can get rid of the assumption that fast/small/light tools have to be written in C or C++ and thus memory unsafe. To name a particularly egregious case, it strikes me as ridiculous that OpenBSD's ntpd feels the need to include a privilege separation feature, despite being a low-thousands-of-lines implementation of a tiny protocol; I mean, there are probably no vulnerabilities in that particular codebase anyway, and given a danger, being paranoid is a good thing - but in the context of the complexity of something like NTP, we have so many CPU cycles to spare that programs simply should not be a typo away from magically turning malformed input into arbitrary code execution. (To be fair, high-level languages have their own vulnerability classes which might allow the same, but at least you're not constantly teetering on the edge of the cliff. Well, unless the language is bash :) And of course Rust is aimed at far more performance critical scenarios - they aim to build a whole browser which is competitive with existing ones performance-wise while being mostly safe code.

seL4 as a product is overhyped: the kernel they verified is tiny, and the proof enormous. It will be a long, long time before a significant fraction of the code running on a production system will be formally verified. However, whereas before there was always a hope of finding a critical bug in even the innermost low level bits of every system... well, now there is one system where that's theoretically impossible. That's a step. Perhaps, slowly but surely, there will be more steps, more places created where bugs (even logic errors, panics, and other types not caught by languages like Rust) cannot lurk. In the long run, that's certainly the type of software I want running my brain!

scrollaway11y ago

Fully agreed about Rust; getting rid of fundamental issues rather than perpetuating the cat-and-mouse problem of chasing classes of vulnerabilities, which sometimes are even intentional backdoors is fantastic. I hope we see more languages like Rust.

But every time I hear about it, people are disappointed by the language. So how is that going?

2 more replies

pgeorgi11y ago

Remote attestation poses a problem when working with proprietary network services. But you already have a problem in that case, the network service.

But when done sensibly and used in a system that's under the user's control (incl. that remote service), it's a security enhancing feature.

And people might not be as much in arms about it anymore because the landscape changed: The original Palladium proposal was made in an environment where the only threat model was "consumers 'steal' content".

Today, measured boot is also a legitimate security measure against criminal activity targetted at the user (eg boot kits, extortion ware), which didn't really enter the picture back then.

j / k navigate · click thread line to collapse