Re: DMCA Still Faces Its First Criminal Test
R. A. Hettinga writes: http://www.law.com/cgi-bin/gx.cgi/AppLogic+FTContentServer?pagename=law/Viewc=Articlecid=ZZZU66KQBZClive=truecst=1pc=0pa=0s=NewsExpIgnore=trueshowsummary=0 March 28, 2002 DMCA Still Faces Its First Criminal Test Criminal case will test Digital Copyright Act The article by Elinor Mills Abreu at http://biz.yahoo.com/rf/020328/crime_bootleg_2.html claims that _two_ people have already been convicted of, or pleaded guilty to, criminal DMCA violations -- one unnamed person in Nebraska and one person just recently in California. My colleague Robin Gross is quoted as saying that the Mohsin Mynaf case is the first time the DMCA has been used to go after someone who is actually infringing copyright. Mynaf was apparently prosecuted for using a Macrovision corrector in the course of infringing the copyright on movies (presumably an act-of-circumvention case rather than a tools case). The first _civil_ case brought under the DMCA's anticircumvention provisions is probably the little-known _RealNetworks v. Streambox_, in Federal court in Washington state, which came to an unhappy end in 2000. The Elcomsoft case might have the distinction of being the first criminal case involving a _challenge_ to the anticircumvention provisions, but it isn't the first criminal case in which they've been used. Another colleague of mine is compiling a list of all court cases in which anticircumvention claims were brought under the DMCA. If you know of any -- other than the ones EFF has been involved in -- please let me know. -- Seth Schoen Staff Technologist[EMAIL PROTECTED] Electronic Frontier Foundationhttp://www.eff.org/ 454 Shotwell Street, San Francisco, CA 94110 1 415 436 9333 x107 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Pact Reached to Stop Pirating Of Digital TV Over the Internet
R. A. Hettinga writes: http://online.wsj.com/article_print/0,4287,SB1019779375174781800,00.html April 26, 2002 NEW MEDIA Pact Is Reached to Stop Pirating Of Digital TV Over the Internet By YOCHI J. DREAZEN and STEPHANIE STEITZER Staff Reporters of THE WALL STREET JOURNAL WASHINGTON -- Representatives from the entertainment and consumer-electronics industries told lawmakers that they have agreed on a system to keep digital television broadcasts from being pirated over the Internet. The agreement resolves a dispute that has contributed to the slow rollout of digital television. Top executives from content companies, including AOL Time Warner Inc., and TV makers such as Panasonic/Matsushita Electric Corp. of America told a House Energy and Commerce Committee panel that they had agreed on technical standards for a new watermark. The watermark would be embedded in all digital TV broadcasts, and TVs, computers and other devices would be designed to play only materials with the watermark. It's not a watermark. It's a single bit. All the technical people involved in the process know that it isn't a watermark. Perhaps these reporters are just using watermark because they're used to applications of watermarking along these lines, or perhaps someone used watermarking as a metaphor. But there's no watermark here, just a redistribution control bit. This proposal is a government mandate to ban digital TV receivers unless they are robust (non-user-serviceable) and provide only Approved Outputs and Approved Recording Methods for broadcasts in which that bit is present. The executives said they planned to release the technical details of the agreement on May 17, at which time they would ask Congress to pass legislation ratifying the standards. That's still true. We are working with many organizations which oppose this legislation to make it clear that there is no broad consensus here. (The agreement on which this article is reporting is an agreement between the MPAA, two DRM consortia, and several computer manufacturers. That's hardly all the affected industries -- never mind consulting consumers!) You don't have to wait until May 17 to read the technical details, though. The very latest draft of the rules proposed by this group: http://www.eff.org/IP/Video/HDTV/20020510_bpdg_compliance_rules.pdf It doesn't make sense unless you also have an enforcement mechanism which makes it illegal to sell a device which doesn't comply with this standard: http://www.eff.org/IP/Video/HDVT/20020215_bpdg_ce_it_rider.html http://www.eff.org/IP/Video/HDTV/20020215_bpdg_mpaa_rider.html (Software is included too.) Again, the idea here is that digital terrestrial broadcast TV, which uses an open standard called ATSC, is insufficiently secure for Hollywood studios. Therefore, they have proposed that legislation require DRM for the digital outputs of TV receivers, and they have proposed that all existing products which record these broadcasts in open formats, or merely output them in open formats, be banned. So, under these rules, you can't have an ATSC tuner card for your PC unless the card and all its software are robust against your accessing the TV signal itself. This has a great deal in common with SCMS, the copy-control system mandated under the Audio Home Recording Act, but this mandate draws on lessons learned since then and includes computer products and software. The most significant thing about this legislative proposal is that it's the first of three compromises intended to replace the CBDTPA, according to no less an authority than Jack Valenti: But we want to narrow the focus of the bill as the legislative process moves forward. What needs to happen is we all sit down together in good-faith negotiations and come to some conclusions on how we can construct a broadcast flag (for keeping digital TV content off the Internet), on how we plug the analog hole (allowing people to record digital content off older televisions and other devices), and how we deal with the persistent and devilish problem of peer-to-peer. http://news.com.com/2008-1082-875394.html If your organization is interested in helping fight this proposal, please contact us, and quickly. -- Seth Schoen Staff Technologist[EMAIL PROTECTED] Electronic Frontier Foundationhttp://www.eff.org/ 454 Shotwell Street, San Francisco, CA 94110 1 415 436 9333 x107 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Pact Reached to Stop Pirating Of Digital TV Over the Internet
bear writes: But you know, I really don't give much of a crap about commercial content anymore. Will this system get in my way if I try to make and distribute (and play and copy on standard hardware) a nice digital-video, digital-audio recording of a family wedding, or an original computer-generated movie, or a demo video for my buddy's band? 'Cause really, that's the problem as far as I'm concerned; if the system prevents people from making and distributing our *own* content with compatible hardware, then it has to be destroyed. Interfering with that use isn't a design feature of the current BPDG proposal. There is an effort to use legislation like this to begin to eradicate open-standards-only equipment from the market (Hollywood executives are calling CE equipment without DRM legacy equipment!), but there is no current clear proposal to ban support for open standards. There is the general risk that hardware could be required to assume by default that input data is copyrighted and being copied without permission (a guilty until proven innocent policy). A rule like that is not part of the current Hollywood-supported mandate, but might be at issue in the next round, which is meant to involve regulating analog-to-digital convertors. -- Seth Schoen Staff Technologist[EMAIL PROTECTED] Electronic Frontier Foundationhttp://www.eff.org/ 454 Shotwell Street, San Francisco, CA 94110 1 415 436 9333 x107 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: dangers of TCPA/palladium
R. Hirschfeld writes: From: Peter N. Biddle [EMAIL PROTECTED] Date: Mon, 5 Aug 2002 16:35:46 -0700 You can know this to be true because the TOR will be made available for review and thus you can read the source and decide for yourself if it behaves this way. This may be a silly question, but how do you know that the source code provided really describes the binary? It seems too much to hope for that if you compile the source code then the hash of the resulting binary will be the same, as the binary would seem to depend somewhat on the compiler and the hardware you compile on. I heard a suggestion that Microsoft could develop (for this purpose) a provably-correct minimal compiler which always produced identical output for any given input. If you believe the proof of correctness, then you can trust the compiler; the compiler, in turn, should produce precisely the same nub when you run it on Microsoft's source code as it did when Microsoft ran it on Microsoft's source code (and you can check the nub's hash, just as the SCP can). I don't know for sure whether Microsoft is going to do this, or is even capable of doing this. It would be a cool idea. It also isn't sufficient to address all questions about deliberate malfeasance. Back in the Clipper days, one question about Clipper's security was how do we know the Clipper spec is secure? (and the answer actually turned out to be it's not). But a different question was how do we know that this tamper-resistant chip produced by Mykotronix even implements the Clipper spec correctly?. The corresponding questions in Palladium are how do we know that the Palladium specs (and Microsoft's nub implementation) are secure? and how do we know that this tamper-resistant chip produced by a Microsoft contractor even implements the Palladium specs correctly?. In that sense, TCPA or Palladium can _reduce_ the size of the hardware trust problem (you only have to trust a small number of components, such as the SCP), and nearly eliminate the software trust problem, but you still don't have an independent means of verifying that the logic in the tamper-resistant chip performs according to its specifications. (In fact, publishing the plans for the chip would hardly help there.) This is a sobering thought, and it's consistent with ordinary security practice, where security engineers try to _reduce_ the number of trusted system components. They do not assume that they can eliminate trusted components entirely. In fact, any demonstration of the effectiveness of a security system must make some assumptions, explicit or implicit. As in other reasoning, when the assumptions are undermined, the demonstration may go astray. The chip fabricator can still -- for example -- find a covert channel within a protocol supported by the chip, and use that covert channel to leak your keys, or to leak your serial number, or to accept secret, undocumented commands. This problem is actually not any _worse_ in Palladium than it is in existing hardware. I am typing this in an ssh window on a Mac laptop. I can read the MacSSH source code (my client) and the OpenSSH source code (the server listening at the other end), and I can read specs for most of the software and most of the parts which make up this laptop, but I can't independently verify that they actually implement the specs, the whole specs, and nothing but the specs. As Ken Thompson pointed out in Reflections on Trusting Trust, the opportunities for introducing backdoors in hardware or software run deep, and can conceivably survive multiple generations, as though they were viruses capable of causing Lamarckian mutations which cause the cells of future generations to produce fresh virus copies. Even if I have a Motorola databook for the CPU in this iBook, I won't know whether the microcode inside that CPU is compliant with the spec, or whether it might contain back doors which can be used against me somehow. It's technically conceivable that the CPU microcode on this machine understands MacOS, ssh, vt100, and vi, and is programmed to detect BWA HA HA! arguments about trusted computing and invisibly insert errors into them. I would never know. This problem exists with or without Palladium. Palladium would provide a new place where a particular vendor could put security-critical (trusted) logic without direct end-user accountability. But there are already several such places in the PC. I don't think that trust-bootstrapping problem can ever be overcome, although maybe it's possible to chip away at it. There is a much larger conversation about trusted computing in general, which we ought to be having: What would make you want to enter sensitive information into a complicated device, built by people you don't know, which you can't take apart under a microscope? That device doesn't have to be a computer. -- Seth David Schoen [EMAIL PROTECTED] | Reading is a right, not a feature! http
Re: Microsoft: Palladium will not limit what you can run
Bill Stewart writes: On Thursday, Mar 13, 2003, at 21:45 US/Eastern, Jay Sulzberger wrote: The Xbox will not boot any free kernel without hardware modification. The Xbox is an IBM style peecee with some feeble hardware and software DRM. But is the Xbox running Nag-Scab or whatever Palladium was renamed? Or is it running something of its own, perhaps using some similar components? The Xbox is definitely not based on NGSCB; Microsoft told EFF very clearly last year that Palladium was still being designed and hadn't gone into manufacturing. The Xbox was certainly being sold then. The Xbox was analyzed by Andrew bunnie Huang, who found that it was using a sui generis security system. ftp://publications.ai.mit.edu/ai-publications/2002/AIM-2002-008.pdf -- Seth David Schoen [EMAIL PROTECTED] | Very frankly, I am opposed to people http://www.loyalty.org/~schoen/ | being programmed by others. http://vitanuova.loyalty.org/ | -- Fred Rogers (1928-2003), |464 U.S. 417, 445 (1984) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
