At the end of describing an "end of the GPL as we know it. Film at 11." scenario, Ross asks:
> Can anyone from HP comment on whether this is actually their plan? I "can't", in the sense of not being an Official HP Spokesdroid; but I'd very much like to, being known to a good few of you, and having sat on my fat behind for the last few years within a few yards of the HP team working on the TCPA spec. I'd also like to apologise in advance for this being a "hit-and-run" posting - I'm away from email for the next 10 or so days (Glastonbury Festival first, then a crypto engagement in London), so can't promise to follow up beyond this message. No, a subversion of the GPL is not HP's strategic intent, never figured in any TCPA design stuff I heard about, isn't what our local "could Linux in general, and our Trusted Linux work in particular, play well with TCPA" work is all about, and is - with apologies to Ross - no more than a far-fetched imagining. The Trusted Linux work is described at the "general comp sci reader" level at http://www.hpl.hp.com/research/papers/Dalton.ACM.pdf Marketing guff is at http://www.hp.com/security/products/linux/papers/ Source code for the kernel patches is at ftp://ftp.hp.com/pub/security/hplx_source/v1.0 (Because of HP's current revenue model for this software, the kernel patches and some minimal tools are GPL'd, but the full-useability stuff is payware. *That* illustrates how up-clued the Greater HP Corporation is about GPL and open-source economics, OK? Flame us for stupidity if you will, but ascribe deep conspiracy to our actions and you'll only look daft!) If you look at the Trusted Linux writeups, you can see what a Nice Thing it would be for the security properties if kernel-module loading could have some hardware-based enforcement of policy. *That* is the kind of TCPA-(Trusted)Linux integration we've been thinking about. To the core issue of whether TCPA is a DRM-plot, my personal answer is "no: it's a technical mechanism which can be used to implement a wide range of security policies". Those policies include, in principle, strong protection against "unwelcome" code (trojans, spyware, and the like - though depending on what languages the malware's written in, and what the execution environment's been programmed to treat as "loading code", some "user-level scripting" could still do Bad Stuff). The TCPA spec - which has been out for public comment for the last 15 months or more - includes explicit support for multiple pseudonymous platform identities, to avoid the privacy-hostile consequences of a fixed platform ID. Raw crypto capabilities on which the higher-level TCPA functions are based are themselves exposed - with the notable exception of freely-keyed symmetric crypto (usual influence of (now dated) exportablity controls, I'm afraid). It's simply not the case, as Ross's paper avers (section 4.1, initial para), that TCPA is "an initiative led by Intel whose stated goal is to embed digital rights management technology in the PC". TCPA does *enable* DRM, as it *enables* anti-malware functionality, secure local storage of confidentiality keys, a more predictable execution environment for security-critical code, and many other applications which a general-purpose "this PC could be running ANYTHING" platform is less well suited to. Arguing that *one* application is "the" driving force behind the whole spec - in the absence of either contact with the design team, or strong corroborative external evidence - is verging on the delusional. Intellectually, it's on a par with the UK Government of 1996 arguing that because strong cryptography can frustrate some aspects of intelligence gathering, strong controls on the use of crypto are therefore necessary - a debate Ross and I and many others in the UK were eventually successful in winning. There are some further specifics in Ross's "end of the GPL as we know it" posting which don't coincide with reality. For one thing, any user of a TCPA platform can switch off the TCPA features - not only the platform Owner. So, an unenhanced Apache (to take one of Ross's examples) can run on an "unTCPAd" GNU/Linux distro on a TCPA-disabled machine as it does now. Any conspiracies to subvert open-source licensing models would have to face that economic competitor - and without added value for TCPA-enabled machines, the clone motherboard vendors will soon drop support for TCPA, whether or not it's part of some "industry-wide agreement". (A painfully-close-to-home comparative instance is IrDA, the fast infra-red standard in which HP owns potentially revenue-generating IP. Much of the early R&D work on that was done here in HPLabs Bristol; a number of my colleagues hoped it would pay for all our pensions. An industry consortium formed around the standard. Motherboard manufacturers started to incorporate IrDA capability. However, the market in general didn't find it to be enough of a "must have" that the few-dollar manufacturing cost was justified; it's now built-in to rather few motherboards, available as a "riser" option for some, and absent from most. But I digress...) A closer look at the TCPA mechanisms will show that a "more secure" Linux could choose to selectively use some TCPA features (say, the local key storage ones) without buying into the controlled boot/controlled loader support - and remember, in all cases, TCPA provides *support* for such features - it's the *OS* which chooses whether they're used or not. At some point, I hope someone Empowered To Speak And Answer For HP will issue some more comprehensive reply to the issues Ross has been raising; but it's difficult for me to watch the efforts of my colleagues in creating a spec for a less leaky PC being traduced on this list by a well-respected, usually well-informed source... Cheers, Stefek --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
