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
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
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
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.
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