RE: Ross's TCPA paper
Mike wrote quoting Lucky: trusted here means that the members of the TCPA trust that the TPM will make it near impossible for the owner of that motherboard to access supervisor mode on the CPU without their knowledge, they trust that the TPM will enable them to determine remotely if the customer has a kernel-level debugger loaded, and they trust that the TPM will prevent a user from bypassing OS protections by installing custom PCI cards to read out memory directly via DMA without going through the CPU. I don't see how they expect this to work. We've already got cheap rip off motherboards, who's gonna stop cheap rip off TPM's that ain't really T? I think it moves the game into a smaller field where the players all have some bucks to begin with, but somebody will create a TPM that looks like the real thing, but runs cypherpunk code just fine. I agree with your assertion that TPM's can't prevent DRM from being broken. Nor is this the intent of introducing TPM's. The vendors have realized that they have to raise the technical bar only so high to keep those most inclined to break their systems (i.e. 16-year old Norwegians) from doing so. Those that have the knowledge and resources to break TCPA systems either won't have the time because they are engaged in gainful employment, won't be willing to take the risk, because they have accumulated sufficient material possessions to be unwilling to risk losing their possessions, not to mention their freedom, in litigation, or will break the security for their own gain, but won't release the crack to the public. Criminal enterprise falls into the latter category. The content vendors, which in this case includes the operating system and application vendors, dislike, but can live with, major criminal enterprise being the only other party to have unfettered access, since criminal enterprise is just another competitor in the market place. Most business models can survive another competitor. Where business models threaten to collapse is when the marginal cost of an illegal copy goes to zero and the public at large can obtain your goods without payment. I don't know if the TCPA's efforts will prevent this, but in the process of trying to achieve this objective, the average computers users, and even many advanced computer users, will find themselves in a new relationship with their PC: that of a pure consumer, with only the choices available to them the what the 180 TCPA's members digital signatures permit. Cloning TPM's is difficult, though not impossible. Note that all TPM's unique initial internal device keys are signed at time of manufacture by a derivative of the TCPA master key. Unless you are one of the well-known chipset or BIOS manufacturers, you can't get your TPM products signed. It is theoretically possible, though far from easy, to clone an entire TPM, keys and all. However, the moment those fake TPM's show up in the market place, their keys will simply be listed in the next CRL update. And if your OS and TPM's miss a few CRL updates, your commercial OS and all your applications will stop working. As might in the future your video card, your PCI cards, your hard drive, and your peripherals. You can try to hack around the code in the OS or firmware that performs the checks, as long as you are willing to operate your machine permanently off the Net from then on, because your system will fail the remote integrity checks, but given that this and other security relevant code inside the OS and applications are 3DES encrypted and are only decrypted inside the TPM, you can't just read the object code from disk, but get to first microprobe the decrypted op codes off the bus before taking a debugger to the code. Not a trivial task at today's PC bus speeds. Nor can you get too aggressive with the hacks, since your Fritz may simply flush the keys and leave you with a bunch of 3DES encrypted op codes and no corresponding decryption keys. Reverse engineering turns pretty dim at that point. None of these obstacles are impossible to overcome, but not by Joe Computer User, not by even the most talented 16-year old hacker, and not even by many folks in the field. Sure, I know some that could overcome it, but they may not be willing to do the time for what by then will be a crime. Come to think of it, doing so already is a crime. --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Shortcut digital signature verification failure
David Wagner wrote: Bill Frantz wrote: If there is a digital signature algorithm which has the property that most invalid signatures can be detected with a small amount of processing, then I can force the attacker to start expending his CPU to present signatures which will cause my server to expend it's CPU. My 800MHz PIII can do about 2800 512-bit RSA verifies per second. Dan Bernstein has a signature algorithm where verification is significantly faster still [1], and his ideas could probably be used to quickly reject most invalid signatures with even better efficiency. What David left out here is that this should be about 10 times as fast as signing. 20 times for 1024 bit, 30 for 2048 and 60 for 4096 - so the answer is use bigger keys. Note that even using 4096 bit keys my (totally non-optimal debugging build of) OpenSSL can do over 80 verifies a second on a PIII of average speed (and less than two signs). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Secure mail relays [was:RE: DOJ proposes US data-rententionlaw. ]
Lucky Green wrote: I share John's dislike for the (thoroughly ineffective, except in making the lives of legitimate users more difficult) anti-spam zealots ... Actually I'm not sure it has been completely ineffective. Cutting the numbers of open relays won't be an effective anti-spam measure until there are almost none left. I saw figures implying that the proportion of open relays is now well below 10%, from nearly 100% a few years ago. Pretty soon open relays will become unusable for legitimate users, not because of anti-spam campaigners, but because they will be relaying so much spam! This may cause the decline to accelerate in the near future. If you want to run an open relay, why not make it ask for hashcash before it accepts mail? ... cypherpunks.to of course supports IPSec under both IPv4 and IPv6 in addition to higher-level encryption protocols such as smtp's STARTTLS). I don't know if it's still like it, but I remember years ago, to post to alt.hackers you had to forge an Approved: header line. I've sometimes thought that it would be nice to do the same thing with IPsec or IPv6. Imagine a clone of Kuro5hin or Slashdot, but with the extra hurdle that you have to use IPv6 (probably using 6 over 4 encapsulation) or opportunistic IPsec. You would automatically exclude non-hackers. More importantly, such a development would encourage deployment of those technologies across the Internet. As more content emerges that is inaccessible to people using only plain IPv4, it creates an incentive to switch. The more people that switch, especially to IPv6, the more likely it is that more similar content will emerge. -- Pete - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Steven Levy buys Microsoft's bullshit hook, line, and sinker
http://www.msnbc.com/news/770511.asp?cp1=1 Of course, the TCPA has nothing to do with security or privacy, since those are OS-level things. All it can really do is ensure you're running a particular OS. It's amazing the TCPA isn't raising all kinds of red flags at the justice department already - it's the most flagrant attempt to stifle competition I've ever seen. -Bram Cohen Markets can remain irrational longer than you can remain solvent -- John Maynard Keynes - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Ross's TCPA paper
Lucky Green writes regarding Ross Anderson's paper at: http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/toulouse.pdf I must confess that after reading the paper I am quite relieved to finally have solid confirmation that at least one other person has realized (outside the authors and proponents of the bill) that the Hollings bill, while failing to mention TCPA anywhere in the text of the bill, was written with the specific technology provided by the TCPA in mind for the purpose of mandating the inclusion of this technology in all future general-purpose computing platforms, now that the technology has been tested, is ready to ship, and the BIOS vendors are on side. It's an interesting claim, but there is only one small problem. Neither Ross Anderson nor Lucky Green offers any evidence that the TCPA (http://www.trustedcomputing.org) is being designed for the support of digital rights management (DRM) applications. In fact if you look at the documents on the TCPA web site you see much discussion of applications such as platform-based ecommerce (so that even if a user's keys get stolen they can't be used on another PC), securing corporate networks (assuring that each workstation is running an IT-approved configuration), detecting viruses, and enhancing the security of VPNs. DRM is not mentioned. Is the claim by Ross and Lucky that the TCPA is a fraud, secretly designed for the purpose of supporting DRM while using the applications above merely as a cover to hide their true purposes? If so, shouldn't we expect to see the media content companies as supporters of this effort? But the membership list at http://www.trustedcomputing.org/tcpaasp4/members.asp shows none of the usual suspects. Disney's not there. Sony's not there. No Viacom, no AOL/Time/Warner, no News Corp. The members are all technology companies, including crypto companies like RSA, Verisign and nCipher. Contrast this for example with the Brodcast Protection Discussion Group whose ongoing efforts are being monitored by the EFF at http://www.eff.org/IP/Video/HDTV/. There you do find the big media companies. That effort is plainly aimed at protecting information and supporting DRM, so it makes sense that the companies most interested in those goals are involved. But with the TCPA, the players are completely different. And unlike with the BPDG, the rationale being offered is not based on DRM but on improving the trustworthiness of software for many applications. Ross and Lucky should justify their claims to the community in general and to the members of the TCPA in particular. If you're going to make accusations, you are obliged to offer evidence. Is the TCPA really, as they claim, a secretive effort to get DRM hardware into consumer PCs? Or is it, as the documents on the web site claim, a general effort to improve the security in systems and to provide new capabilities for improving the trustworthiness of computing platforms? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Ross's TCPA paper
Anonymous writes: Lucky Green writes regarding Ross Anderson's paper at: Ross and Lucky should justify their claims to the community in general and to the members of the TCPA in particular. If you're going to make accusations, you are obliged to offer evidence. Is the TCPA really, as they claim, a secretive effort to get DRM hardware into consumer PCs? Or is it, as the documents on the web site claim, a general effort to improve the security in systems and to provide new capabilities for improving the trustworthiness of computing platforms? Anonymous raises a valid question. To hand Anonymous additional rope, I will even assure the reader that when questioned directly, the members of the TCPA will insist that their efforts in the context of TCPA are concerned with increasing platform security in general and are not targeted at providing a DRM solution. Unfortunately, and I apologize for having to disappoint the reader, I do not feel at liberty to provide the proof Anonymous is requesting myself, though perhaps Ross might. (I have no first-hand knowledge of what Ross may or may not be able to provide). I however encourage readers familiar with the state of the art in PC platform security to read the TCPA specifications, read the TCPA's membership list, read the Hollings bill, and then ask themselves if they are aware of, or can locate somebody who is aware of, any other technical solution that enjoys a similar level of PC platform industry support, is anywhere as near to wide-spread production as TPM's, and is of sufficient integration into the platform to be able to form the platform basis for meeting the requirements of the Hollings bill. Would Anonymous perhaps like to take this question? --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
