RE: Seth on TCPA at Defcon/Usenix
At 12:58 AM 08/11/2002 -0700, Lucky Green wrote: >BTW, does anybody here know if there is still an email time stamping >server in operation? The references that I found to such servers appear >to be dead. The canonical timestamping system was Haber & Stornetta's work at Bellcore, commercialized at Surety.com. The site is current, has some Digital Notary Service and Secure Email things on it, and something much more amazing - it looks like they received $7M in financing in June :-) There's a nice collection of pointers to timestamping systems at http://saturn.tcs.hut.fi/~helger/crypto/link/timestamping/ though I don't know how current the references are - the page was last updated 14.8.2002. The free PGP-based system http://www.itconsult.co.uk/stamper.htm has a news item from 04-Jun-02, which comments that, although they haven't posted any news items in five years, they've been in continuous operation
Re: Seth on TCPA at Defcon/Usenix
On Tue, 13 Aug 2002, James A. Donald wrote: > To me DRM seems possible to the extent that computers themselves > are rendered tamper resistant -- that is to say rendered set top > boxes not computers, to the extent that unauthorized personnel are > prohibited from accessing general purpose computers. But even then, if it's perceptable to a human in some form, it can be copied. Suppose it's displayed on a screen in english and copied with a pencil in Japanese, then sent by unicode across the planet. I agree it'd be mighty hard to copy pictures from a set top box at video frame rates by hand, but there are many musicians who can hear a song once and play it again perfectly. All it takes is one person who has valid access and they can copy anything. It may take a lot of expensive equipment and be hard to do, but they don't have to crack anything, they can just copy the human perceptible data onto a machine that doesn't have any DRM crap. This is what makes the whole "analog hole" idea idiotic. Humans are analog - they can copy the data! To plug the "analog hole" Hollywood will have to control every human mind directly. > To me, TCPA only makes sense as a step towards some of the more > monstrous outcomes that have been suggested by myself and others > on this list. It does not make sense as a final destination, but > only as a first step on a path. Yeah, it sure seems obvious to me too. I think preventing that first step is mighty important. Patience, persistence, truth, Dr. mike
Re: Seth on TCPA at Defcon/Usenix
-- On 12 Aug 2002 at 20:38, Mike Rosing wrote: > I'm actually really confused about the whole DRM business > anyway. It seems to me that any data available to human > perceptions can be duplicated. Period. The idea of DRM (as I > understand it) is that you can hand out data to people you don't > trust, and they can't copy it. To me, DRM seems fundamentally > impossible. To me DRM seems possible to the extent that computers themselves are rendered tamper resistant -- that is to say rendered set top boxes not computers, to the extent that unauthorized personnel are prohibited from accessing general purpose computers. To me, TCPA only makes sense as a step towards some of the more monstrous outcomes that have been suggested by myself and others on this list. It does not make sense as a final destination, but only as a first step on a path. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG xnGldvXqRQB8PKwYfVNs7FqNlzHkJtffm/JPsWY9 2NZkA77opkyGpXY+3+uMUIXDusHs6+ZgOeCu7YXgJ
Re: Seth on TCPA at Defcon/Usenix
In discussing how TCPA would help enforce a document revocation list (DRL) Joseph Ashwood contrasted the situation with and without TCPA style hardware, below. I just want to point out that his analysis of the hardware vs software situation says nothing about DRL's specifically; in fact it doesn't even mention them. His analysis actually applies to a wide range of security features, such as the examples given earlier: secure games, improved P2P, distributed computing as Adam Back suggested, DRM of course, etc.. TCPA is a potentially very powerful security enhancement, so it does make sense that it can strengthen all of these things, and DRLs as well. But I don't see that it is fair to therefore link TCPA specifically with DRLs, when there are any number of other security capabilities that are also strengthened by TCPA. Joseph Ashwood wrote: > Actually it does, in order to make it valuable. Without a hardware assist, > the attack works like this: > Hack your software (which is in many ways almost trivial) to reveal it's > private key. > Watch the protocol. > Decrypt protocol > Grab decryption key > use decryption key > problem solved It's not always as easy as you make it sound here. Adam Back wrote Saturday about the interesting history of the giFT project, which reverse-engineered the Kazaa file-sharing protocol. That was a terrific effort that required considerable cryptographic know-how as well as supreme software reverse engineering skills. But then Kazaa changed the protocol, and giFT never managed to become compatible with the new one. I'm not sure whether it was lack of interest or just too difficult, but in any case the project failed (as far as creating an open Kazaa compatible client). It is clear that software hacking is far from "almost trivial" and you can't assume that every software-security feature can and will be broken. Furthermore, even when there is a break, it won't be available to everyone. Ordinary people aren't clued in to the hacker community and don't download all the latest patches and hacks to disable security features in their software. Likewise for business customers. In practice, if Microsoft wanted to implement a global, facist DRL, while some people might be able to patch around it, probably 95%+ of ordinary users would be stuck with it. Therefore a DRL in software would be far from useless, and if there truly was a strong commercial need for such a solution then chances are it would be there today. I might mention BTW that for email there is such a product, disappearingink.com, which works along the lines Seth suggested, I believe. It encrypts email with a centralized key, and when that email needs to be deleted, the key is destroyed. This allows corporations to implement a "document retention policy" (which is of course a euphemism for a document destruction policy) to help reduce their vulnerability to lawsuits and fishing expeditions. I don't recall anyone getting up in arms over the disappearingink.com technology or claiming that it was a threat, in the same way that DRLs and SNRLs are being presented in the context of Palladium. > With hardware assist, trusted software, and a trusted execution environment > it (doesn't) work like this: > Hack you software. > DOH! the software won't run > revert back to the stored software. > Hack the hardware (extremely difficult). > Virtualize the hardware at a second layer, using the grabbed private key > Hack the software > Watch the protocol. > Decrypt protocol > Grab decryption key > use decryption key > Once the file is released the server revokes all trust in your client, > effectively removing all files from your computer that you have not > decrypted yet > problem solved? only for valuable files First, as far as this last point, you acknowledge that if they can't tell where it came from, your hacked hardware can be an ongoing source of un-DRL'd documents. But watermarking technology so far has been largely a huge failure, so it is likely that someone clueful enough to hack his TPM could also strip away any identifying markings. Second, given that you do hack the hardware, you may not actually need to do that much in terms of protocol hacking. If you can watch the data going to and from the TPM you can extract keys directly, and that may be enough to let you decrypt the "sealed" data. (The TPM does only public key operations; the symmetric crypto is all done by the app. I don't know if Palladium will work that way or not.) Third, if a document is "liberated" via this kind of hack, it can then be distributed everywhere, outside the "secure trust perimeter" enforced by TCPA/Palladium. We are still in a "break once read anywhere" situation with documents, and any attempt to make one disappear is not going to be very successful, even with TCPA in existence. In short, while TCPA could increase the effectiveness of global DRLs, they wouldn't be *that* much more effective. Most users will neither hack
Re: Seth on TCPA at Defcon/Usenix
On Mon, 12 Aug 2002, AARG! Anonymous wrote: > It is clear that software hacking is far from "almost trivial" and you > can't assume that every software-security feature can and will be broken. Anyone doing "security" had better assume software can and will be broken. That's where you *start*. > Furthermore, even when there is a break, it won't be available to > everyone. Ordinary people aren't clued in to the hacker community > and don't download all the latest patches and hacks to disable > security features in their software. Likewise for business customers. > In practice, if Microsoft wanted to implement a global, facist DRL, > while some people might be able to patch around it, probably 95%+ of > ordinary users would be stuck with it. Yes, this the problem with security today. That's why lots of people are advocating that the OS should be built from the ground up with security as the prime goal rather than ad hoc addons as it is now. Nobody wants to pay for it tho :-) > In short, while TCPA could increase the effectiveness of global DRLs, > they wouldn't be *that* much more effective. Most users will neither > hack their software nor their hardware, so the hardware doesn't make > any difference for them. Hackers will be able to liberate documents > completely from DRL controls, whether they use hardware or software > to do it. The only difference is that there will be fewer hackers, > if hardware is used, because it is more difficult. Depending on the > rate at which important documents go on DRLs, that may not make any > difference at all. So what's the point of TCPA if a few hackers can steal the most expensive data? Are you now admitting TCPA is broken? You've got me very confused now! I'm actually really confused about the whole DRM business anyway. It seems to me that any data available to human perceptions can be duplicated. Period. The idea of DRM (as I understand it) is that you can hand out data to people you don't trust, and they can't copy it. To me, DRM seems fundamentally impossible. Patience, persistence, truth, Dr. mike
Re: CDR: Re: Seth on TCPA at Defcon/Usenix
On Mon, 12 Aug 2002, AARG! Anonymous wrote: > His analysis actually applies to a wide range of security features, > such as the examples given earlier: secure games, improved P2P, > distributed computing as Adam Back suggested, DRM of course, etc.. > TCPA is a potentially very powerful security enhancement, so it does > make sense that it can strengthen all of these things, and DRLs as well. > But I don't see that it is fair to therefore link TCPA specifically with > DRLs, when there are any number of other security capabilities that are > also strengthened by TCPA. Sorry, but now you're just trolling. Acid is great for removing all manner of skin problems. It also happens to cause death, but linking fatalities to it is unfair, considering that's not what acid was _intended_ to do. Creating cheat-proof gaming at the cost of allowing document revoking enabled software sounds like a bad idea. -j
Re: Seth on TCPA at Defcon/Usenix
> It reminds me of an even better way for a word processor company to make > money: just scramble all your documents, then demand ONE MILLION DOLLARS > for the keys to decrypt them. The money must be sent to a numbered > Swiss account, and the software checks with a server to find out when > the money has arrived. Some of the proposals for what companies will > do with Palladium seem about as plausible as this one. Isn't this how Windows XP and Office XP work? They let you set up the system and fill it with your data for a while -- then lock up and won't let you access your locally stored data, until you put the computer on the Internet and "register" it with Microsoft. They charge less than a million dollars to unhand your data, but otherwise it looks to me like a very similar scheme. There's a first-person report about how Office XP made the computers donated for the 9/11 missing persons database useless after several days of data entry -- so the data was abandoned, and re-entered into a previous (non-DRM) Microsoft word processor. The report came through this very mailing list. See: http://www.mail-archive.com/cryptography@wasabisystems.com/msg02134.html This scenario of word processor vendors denying people access to their own documents until they do something to benefit the vendor is not just "plausible" -- it's happening here and now. John
Seth on TCPA at Defcon/Usenix
Seth Schoen of the EFF has a good blog entry about Palladium and TCPA at http://vitanuova.loyalty.org/2002-08-09.html. He attended Lucky's presentation at DEF CON and also sat on the TCPA/Palladium panel at the USENIX Security Symposium. Seth has a very balanced perspective on these issues compared to most people in the community. It makes me proud to be an EFF supporter (in fact I happen to be wearing my EFF T-shirt right now). His description of how the Document Revocation List could work is interesting as well. Basically you would have to connect to a server every time you wanted to read a document, in order to download a key to unlock it. Then if "someone" decided that the document needed to un-exist, they would arrange for the server no longer to download that key, and the document would effectively be deleted, everywhere. I think this clearly would not be a feature that most people would accept as an enforced property of their word processor. You'd be unable to read things unless you were online, for one thing. And any document you were relying on might be yanked away from you with no warning. Such a system would be so crippled that if Microsoft really did this for Word, sales of "vi" would go through the roof. It reminds me of an even better way for a word processor company to make money: just scramble all your documents, then demand ONE MILLION DOLLARS for the keys to decrypt them. The money must be sent to a numbered Swiss account, and the software checks with a server to find out when the money has arrived. Some of the proposals for what companies will do with Palladium seem about as plausible as this one. Seth draws an analogy with Acrobat, where the paying customers are actually the publishers, the reader being given away for free. So Adobe does have incentives to put in a lot of DRM features that let authors control publication and distribution. But he doesn't follow his reasoning to its logical conclusion when dealing with Microsoft Word. That program is sold to end users - people who create their own documents for the use of themselves and their associates. The paying customers of Microsoft Word are exactly the ones who would be screwed over royally by Seth's scheme. So if we "follow the money" as Seth in effect recommends, it becomes even more obvious that Microsoft would never force Word users to be burdened with a DRL feature. And furthermore, Seth's scheme doesn't rely on TCPA/Palladium. At the risk of aiding the fearmongers, I will explain that TCPA technology actually allows for a much easier implementation, just as it does in so many other areas. There is no need for the server to download a key; it only has to download an updated DRL, and the Word client software could be trusted to delete anything that was revoked. But the point is, Seth's scheme would work just as well today, without TCPA existing. As I quoted Ross Anderson saying earlier with regard to "serial number revocation lists", these features don't need TCPA technology. So while I have some quibbles with Seth's analysis, on the whole it is the most balanced that I have seen from someone who has no connection with the designers (other than my own writing, of course). A personal gripe is that he referred to Lucky's "critics", plural, when I feel all alone out here. I guess I'll have to start using the royal "we". But he redeemed himself by taking mild exception to Lucky's slide show, which is a lot farther than anyone else has been willing to go in public.
RE: Seth on TCPA at Defcon/Usenix
David wrote: > AARG! Anonymous wrote: > >His description of how the Document Revocation List could work is > >interesting as well. Basically you would have to connect to > a server > >every time you wanted to read a document, in order to > download a key to > >unlock it. Then if "someone" decided that the document needed to > >un-exist, they would arrange for the server no longer to > download that > >key, and the document would effectively be deleted, everywhere. > > Well, sure. It's certainly how I had always envisioned one > might build a secure Document Revocation List using TCPA or > Palladium. I didn't realize this sort of thing would need > explaining; I assumed it would be obvious to cypherpunk > types. But I'm glad this risk is now clear. To ensure priority for my Monday filings, I must point out at this time that while AARG and David's methods of implementing a DRL are certainly feasible, I believe a preferred method of implementing a DRL would be to utilize features offered by an infrastructure, such as Palladium, that supports time-limited documents: rather than requiring online access whenever the document is attempted to be displayed, the document's display permissions would be renewed periodically. If the display software misses one or more updates, the document display software will cease to display the document. BTW, does anybody here know if there is still an email time stamping server in operation? The references that I found to such servers appear to be dead. Thanks, --Lucky
Re: Seth on TCPA at Defcon/Usenix
- Original Message - From: "AARG! Anonymous" <[EMAIL PROTECTED]> [brief description of Document Revocation List] >Seth's scheme doesn't rely on TCPA/Palladium. Actually it does, in order to make it valuable. Without a hardware assist, the attack works like this: Hack your software (which is in many ways almost trivial) to reveal it's private key. Watch the protocol. Decrypt protocol Grab decryption key use decryption key problem solved With hardware assist, trusted software, and a trusted execution environment it (doesn't) work like this: Hack you software. DOH! the software won't run revert back to the stored software. Hack the hardware (extremely difficult). Virtualize the hardware at a second layer, using the grabbed private key Hack the software Watch the protocol. Decrypt protocol Grab decryption key use decryption key Once the file is released the server revokes all trust in your client, effectively removing all files from your computer that you have not decrypted yet problem solved? only for valuable files Of course if you could find some way to disguise which source was hacked, things change. Now about the claim that MS Word would not have this "feature." It almost certainly would. The reason being that business customers are of particular interest to MS, since they supply a large portion of the money for Word (and everything else). Businesses would want to be able to configure their network in such a way that critical business information couldn't be leaked to the outside world. Of course this removes the advertising path of conveniently leaking carefully constructed documents to the world, but for many companies that is a trivial loss. Joe
Re: Seth on TCPA at Defcon/Usenix
AARG! Anonymous wrote: >His description of how the Document Revocation List could work is >interesting as well. Basically you would have to connect to a server >every time you wanted to read a document, in order to download a key >to unlock it. Then if "someone" decided that the document needed >to un-exist, they would arrange for the server no longer to download >that key, and the document would effectively be deleted, everywhere. Well, sure. It's certainly how I had always envisioned one might build a secure Document Revocation List using TCPA or Palladium. I didn't realize this sort of thing would need explaining; I assumed it would be obvious to cypherpunk types. But I'm glad this risk is now clear. Note also that Document Revocation List functionality could arise without any intent to create it. Application developers might implement this "connect to a server" feature to enforce some seemingly innocuous function, like enforcing software licenses and preventing piracy. Then, after the application has been deployed with this innocuous feature, someone else might eventually notice that it could also be used for document revocation. Thus, Document Revocation List functionality could easily become widespread without anyone realizing it or intending it. This is a risk we should make think about now, rather than after it is too late.
