Re: full-disk subversion standards released
Peter Gutmann wrote: John Gilmore g...@toad.com writes: The theory that we should build good and useful tools capable of monopoly and totalitarianism, but use social mechanisms to prevent them from being used for that purpose, strikes me as naive. There's another problem with this theory and that's the practical implementation issue. I've read through... well, at least skimmed through the elephantine bulk of the TCG specs, and also read related papers and publications and talked to people who've worked with the technology, to see how I could use it as a crypto plugin for my software (which already supports some pretty diverse stuff, smart cards, HSMs, the VIA Padlock engine, ARM security cores, Fortezza cards (I even have my own USG-allocated Fortezza ID :-), and in general pretty much anything out there that does crypto in any way, shape, or form). However after detailed study of the TCG specs and discussions with users I found that the only thing you can really do with this, or at least the bits likely to be implemented and supported and not full of bugs and incompatibilities, is DRM. You could note a certain overlap between the promoters of Digital Content Protection and the Trusted Computing Group: http://www.digital-cp.com/about_dcp Nearly 400 leading companies license the technology, including the following: Semiconductor: PC Companies:Consumer Electronics: AMD HP Panasonic Analog Devices Microsoft Samsung Intel Lenovo Sony Silicon Image Toshiba Full List of Licensees: Click here (Fuji Xerox Co., Ltd.) https://www.trustedcomputinggroup.org/about/members/ Current Members Promoter Contributor AMD... Fujitsu Limited Panasonic Hewlett-Packard... IBM Samsung Electronics Co. Infineon ... Intel Corporation Sony Corporation Lenovo Holdings Limited... Microsoft Toshiba Corporation Seagate Technology Sun Microsystems, Inc. Wave Systems The costs and economy of scale say at some point all the disk drives will be capable of FDE, whether or not it is enabled (whether or not you pay for the 'extra' feature). The distinction is the added cost of testing the encryption versus the cost of two different testing regimes, when silicon is typically pin bound defining area and cost. The same integration cost advantages makes the like of HDMI close to zero cost to the television media consumer. Enterprise 'platform owners' have the capability of assuming control of the attestation chain, while 'personal computing' might have few opportunities other than to allow the likes of an operating system vendor to provide control 'in loco parentis' for the naive consumer. Loss of control of personal computing would come about by seduction - the offer of benefits in exchange for more of the camel edging under the tent skirt. More's the pity if it offers competitive advantage excluding open source. You'd think video content providers would be anxious for a way to provide secure delivery of content via download. Being able to stick video onto a disk protected by a plus thirteen Mage DMCA spell would be a definite benefit. I'd also imagine we'll see vulnerabilities that will allow content recovery. Getting 'secure' computing requires a secure operating system. Building a computer secure against end user tampering would incur high adoption costs that wouldn't be supportable in the marketplace. To borrow and mutilate a turn of phrase from Bruce, what we get is Kabuki security theater with the commiserate tendency toward prostitution. All that said and done, people may still well end up with better security - data encrypted at rest. I'd think fighting DRM would be a separate battle from opposing FDE. It may be worthwhile to show systemic vulnerabilities that despite the encryption endanger threaten 'content protection', because while DRM's proponents like to provide a stylized threat model the real world doesn't match up. The enterprise is able to leverage further behavioral limits on users actions during platform operation and the Trusted Computing threat model allows users within the cryptographic boundary (undoubtedly due to the cost of exclusion). Additional behavioral limits aren't available for the DRM usage model, and there is nothing stopping the malevolent end user from monitoring unencrypted data from a drive for example. Trusted Computing may never be suitable for DRM either. I'd expect an enterprise would field a careful selected configuration that they could manage to make work for their purposes. DRM has to work for any
RE: UCE - a simpler approach using just digital signing?
On Saturday, January 31, 2009 6:36 AM, Sascha Silbe wrote: Another scheme (that could be combined with the above one to solve only the CC party problem) would be accepting only PGP mail and use a manually updated whitelist / web of trust of PGP keys. Unfortunately, PGP still isn't widespread enough to reject non-PGP mails and the ones not using it are often far more susceptible to address harvesting malware, limiting the usefulness of such a filter. On Saturday, January 31, 2009 2:56 PM, John Levin wrote: This has the same fundamental problem as Zoemail and any other white list system. It's really easy to implement a white list. Unless your name is Paypal, the amount of mail forging your address is vanishingly small, and the utterly insecure From: line address works just fine for practical purposes. I use that to manage my 12 year old daughter's mail. On Saturday, January 30, 2009 6:17 PM, John Levin wrote: This is the wrong place to go into detail about its limitations, although it should be self-evident that if it were effective, sometime in the past 13 years we'd have started using it. Though John's January 30th note was about Zoemail, I am reacting to the words PGP still isn't widespread in Sascha's post about PGP. I also was once under the assumption that I should always have PGP installed. I was able to verify signatures, and I thought that one day, most people would gravitate to PGP in some form. However, losing a fight with PGP Support over whether the enterprise plug-ins I was requesting for a corporation would reduce the security level of their product (long story about trying to integrate it with single sign on), and also spending many hours over three months trying to install the commercial version on Vista, only to have the PGP engineers tell me that I would have to uninstall all my other Outlook plug-ins for them to continue working on the problem (e.g. card scanner), I realize that it will never be the solution of choice for either commercial enterprise or home office given its current support model. I have not used it since July and have not missed it a bit. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: full-disk subversion standards released
Peter Gutmann wrote: John Gilmore g...@toad.com writes: The theory that we should build good and useful tools capable of monopoly and totalitarianism, but use social mechanisms to prevent them from being used for that purpose, strikes me as naive. There's another problem with this theory and that's the practical implementation issue. I've read through... well, at least skimmed through the elephantine bulk of the TCG specs, and also read related papers and publications and talked to people who've worked with the technology, to see how I could use it as a crypto plugin for my software (which already supports some pretty diverse stuff, smart cards, HSMs, the VIA Padlock engine, ARM security cores, Fortezza cards (I even have my own USG-allocated Fortezza ID :-), and in general pretty much anything out there that does crypto in any way, shape, or form). However after detailed study of the TCG specs and discussions with users I found that the only thing you can really do with this, or at least the bits likely to be implemented and supported and not full of bugs and incompatibilities, is DRM. Apart from the obvious fact that if the TPM is good for DRM then it is also good for protecting servers and the data on them, Mark Ryan presented a plausible use case that is not DRM: http://www.cs.bham.ac.uk/~mdr/research/projects/08-tpmFunc/. I wrote it up briefly here: http://www.links.org/?p=530. As for John's original point, isn't the world full of such tools (guns, TV cameras, telephone networks, jet engines, blah blah)? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: UCE - a simpler approach using just digital signing?
One idea I have not seen mentioned here (and which I have not yet encountered in RL, but only weird people send me email these days) is for the sending MTA to use pgp to encrypt mail using the recipient's public key, available on one of the key servers near you. I don't understand what problem this is intended to solve. Bad guys can look up PGP keys just like good guys, so all this would accomplish would be to fill your inbox with signed spam. Perhaps it would be useful to make a section of the ASRG wiki in which we describe the difference between the spam problem and the other problems that people confuse with the spam problem, such as the introduction problem and (more familiar to cryptographers) the authentication problem, the interception problem, the non-repudiation problem, and doubtless others that I can't think of just now. R's, John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
