5 ms·

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 g

• pgeorgi 12y 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.
• geofft 12y ago
  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.
  • comex 12y 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!