4 ms·
The TCG got this right in that TPMs do not force you into a DRM world, but they certainly enable it. I say that's right because any TPM-like technology that co
by cryptonector 4y ago
The TCG got this right in that TPMs do not force you into a DRM world, but they certainly enable it. I say that's right because any TPM-like technology that could let you secure boot could also let the platform vendor lock you into a DRM world -or lock you out of the walled garden if you opt out- but the TCG took a neutral approach that lets the user opt out.
- p_l 4y agoBy making it only possible to verify that you run on certain stack (which enforces your DRM) they made a very simple but powerful scheme that doesn't in fact infringe on users rights (No matter what FSF's FUD campaign said)
- cryptonector 4y agoThere's more to it. A TPM comes with an endorsement key certificate, and the platform to which the TPM is attached can come with platform certificates, and the OS can require those to exist and be valid and that the TPM still have the corresponding private keys. An OS can use those keys and certificates to implement a garden walled by secured boot + attestation. The user gets to change the relevant key hierarchy seeds, thus causing those private keys to no longer be available, and those certificates to be useless, and the OS to no longer be able to do attestation using those keys and certificates -- but then the OS vendor gets to lock that device out of the walled garden.
- mindslight 4y ago> they made a very simple but powerful scheme that doesn't in fact infringe on users rights This is straight up false in the standard model where protocols are what mediates between otherwise-independent parties. If a remote party can verify the software I am running on my machine against my wishes, that creates a security vulnerability that prevents me from running software of my choice.
- cryptonector 4y ago> > they [the TCG] made a very simple but powerful scheme that doesn't in fact infringe on users rights > This is straight up false in the standard model where protocols are what mediates between otherwise-independent parties. I've answered this elsewhere. TPMs are neutral technology enabling technology that you might approve of and technology you might disapprove of. > If a remote party can verify the software I am running on my machine against my wishes, that creates a security vulnerability that prevents me from running software of my choice. TPMs do not prevent you from having opt-out. The matter of whether someone can give you only a binary choice of opting into or out of walled gardens is a market/political problem. I don't see how to prevent walled gardens using technology, especially when walled gardens vendors can make it so you can only access the walled gardens on devices that they manufacture (or bless) -- it's their tech, so what can you do to make it not possible for them to implement lock-in? It's just not possible.
- mindslight 4y ago> I've answered this elsewhere. TPMs are neutral technology enabling technology that you might approve of and technology you might disapprove of. And I strongly disagree! A TPM with an attestation key that is known to the previous owner (eg manufacturer or distributor) allows the previous owner (and everyone who trusts them) to compel the current owner to verify what software they are running on their own machine. The presence of the neutral hardware capability, plus the non-neutral treat-owner-as-an-attacker security property that the owner cannot read the private attestation key, creates a non-neutral security vulnerability for the owner. Hence my point (3) to mitigate this vulnerability by making it so that the owner can always choose to emulate an attestation. This property would make the hardware feature actually neutral. > it's their tech, so what can you do to make it not possible for them to implement lock-in? The problem is not set top boxes and other narrow-purpose devices created by vertically integrated companies - code signing is enough to lock those down and guarantee the creation of e-waste. Rather the issue is general purpose computers including hardware that allow remote parties to dictate what code you're running when you interact with them. For example, a bank that says "for [our] security, you must run a known copy of MS Windows with a known copy of InterChrome Explorer to access our website" (or analogous proprietary environment). The market basically moves in lock step, so you won't be able to choose a different bank (just as with the now-common "SMS 2FA" hassle). So given the basic non-neutral capability, corporations can gradually shove the general purpose computing genie back in the bottle, rather than having to make due with trusting device owners. With binary/proprietary software, a similar dynamic exists right now. But for important cases it's possible to reverse engineer protocols and make third party clients. Owner-hostile remote attestation closes off the escape. This further pushes us into computational disenfranchisement, where the computer you purportedly own, that's sitting right in front of you, is enforcing the rules of the corporate-government power structure rather than functioning as your agent. We do need to win the battle in the market, but to do that we at least need an option for people to buy that respects their freedom. Saying "buy this corporate phone and then run this procedure to change the TPM key [destroying your ability to use corporate-based attestation]" isn't a compelling story, but saying "buy this freedom-respecting computer based on a freedom-respecting TPM" is. We need enough of the people doing the latter that it is market-infeasible for banks et al to require remote attestation.