Niels Ferguson wrote:

At 16:04 16/09/02 -0700, AARG! Anonymous wrote:

...

Nothing done purely in software will be as effective as what can be done when you have secure hardware as the foundation. I discuss this in more detail below.

But I am not suggesting to do it purely in software. Read the Intel manuals for their CPUs. There are loads of CPU features for process separation, securing the operating system, etc. The hardware is all there!

Maybe I have to explain the obvious. On boot you boot first to a secure kernel, much like the Pd kernel but running on the main CPU. This kernel then creates a virtual machine to run the existing Windows in, much like VMware does. The virus is caught inside this virtual machine. All you need to do is make sure the virtual machine cannot write to the part of the disk that contains your security kernel.

Thanks for the explanation. Essentially you can create a virtualized Palladium, where you emulate the functionality of the secure hardware. The kernel normally has access to all of memory, for example, but you can virtualize the MMU as VmWare does, so that some memory is inaccessible even to the kernel, while the kernel can still run pretty much the same. Similarly your virtualizing software could comput a hash of code that loads into this secure area and even mimic the Palladium functionality to seal and unseal data based on that hash. All this would be done at a level which was inaccessible to ordinary Windows code, so it would be basically as secure as Palladium is with hardware. The one thing that you don't get with this method is secure attestation. There is no way your software can prove to a remote system that it is running a particular piece of code, as is possible with Pd hardware. However I believe you see this as not a security problem, since in your view the only use for such functionality is for DRM. I do think there are some issues with this approach to creating a secure system, even independent of the attestation issue. One is performance. According to a presentation by the VMWare chief scientist [1], VMWare sees slowdowns of from 8 to 30 percent on CPU-bound processes, with graphics-intensive applications even worse, perhaps a factor of 2 slower. Maybe Windows could do better than this, but users aren't going to be happy about giving up 10 percent or more of their CPU performance. Also, Palladium hardware provides protection against DMA devices: "Even PCI DMA can't read or write memory which has been reserved to a nub's or TA's use (including the nub's or TA's code). This memory is completely inaccessible and can only be accessed indirectly through API calls. The chipset on the motherboard is modified to enforces this sort of restriction." [2] It's conceivable that without this hardware protection, a virus could exploit a security flaw in an external device and get access to the secure memory provided by a virtualized Palladium. But these are not necessarily major problems. Generally I now agree with your comments, and those of others, that the security benefits of Palladium - except for secure remote attestation - can be provided using existing and standard PC hardware, and that the software changes necessary are much like what would be necessary for the current Palladium design, plus the work to provide VMWare-type functionality. However that still leaves the issue of remote attestation...

Who are you protecting against? If the system protects the interests of the user, then you don't need to protect the system from the user. The security chip is only useful if you try to take control away from the user.

This is a simplistic view. There are many situations in which it is in the interests of the user to be able to prove to third parties that he is unable to commit certain actions. A simple example is possession of a third-party cryptographic certificate. The only reason that is valuable is because the user can't create it himself. Any time someone shows a cert, they are giving up some control in order to get something. They can't modify that certificate without rendering it useless. They are limited in what they can do with it. But it is these very limitations that make the cert valuable. But let me cut to the chase and provide some examples where remote attestation, allowing the user to prove that he is running a particular program and that it is unmolested, is useful. These will hopefully encourage you to modify your belief that "The 'secure chip' in Pd is only needed for DRM. All other claimed benefits of Pd can be achieved using existing hardware. To me this is an objectively verifyable truth." I don't think any of these examples could be solved with software plus existing hardware alone. The first example is a secure online game client. Rampant cheating in the online gaming industry is a major problem which has gotten much attention in the past few months. Players can load hacks to let them see through walls, automate targetting and fire control, and employ other methods that give them an overwhelming advantage. The game industry is big business and is growing rapidly. Unless they can get a handle on this problem it could hurt the success of the industry. Remote attestation will allow game servers to be confident that users are playing on a level playing field, without the hacked and modified clients that allow cheating. Another example is a P2P file sharing network client. Faced with the threat from these file sharing networks, content industries are attacking them in various ways, including flooding them with bogus queries and lying about file hashes and contents. Also, some users are switching to clients that give them unfair priority, at the expense of the rest of the network. Recently a Salon article [3] reported that Gnutella developers are considering methods to check client integrity in order to avoid these problems. But this is not really possible today, especially with open source clients. What they need is secure attestation. That way they can be confident that client software is using the protocol fairly and appropriately. Of course, the Gnutella developers have no idea that the evil bogeyman of Palladium could actually help them out - no one in the security field is willing to say anything favorable about the technology. This conspiracy of silence is what I am trying to overcome. Online distributed computations can also benefit. Recently there was a comment on cypherpunks that pointed out that the RC5 keysearch effort has gone through 85% of the key space without success, raising the possibility that it somehow skipped the key. This particular search has gone on for almost five years, and all that work may come to nothing! Being able to check that users are running valid clients will eliminate one possible source of problems in these efforts. Remote attestation will be an easy way to improve the chances that if someone says that the key is not in a particular region, it really isn't. Turning to banking and e-commerce, there are many cases where it is not enough to be running a secure client; you must also be able to prove that you are doing so. According to Perry Metzger's earlier message, if a user is defrauded in a banking transaction due to a virus, he is supposed to be protected. It's not clear who has to pay him back, but let's suppose it is the bank. Now the bank has a very real economic interest in making sure that its clients are using the approved software. If there is third-party software out there, the bank can't be sure of its reliability and security. Secure attestation can improve the security of the entire system by making sure that third-party clients are not allowed to participate in transactions. The bank has control over its liability and its risk. The same reasoning applies to credit card purchases. If you've got a virtual-Palladium-based secure system, that's great; you're protected against a virus somehow getting your card number and using it. But actually it is the banks who eat the charges when cards are misused, at least in the U.S. It could make a great deal of sense for acceptors of credit cards to be able to check what software the user is running, make sure it is a secure system and that it is an approved client. This will give users incentives to move to secure systems, which will benefit everyone as the amount of fraud decreases. Secure attestation could even provide a way for commercial companies to prove to customers that they are running particular accounting software to hold data on their customers. Eventually, accounting software could be developed which is oriented around protecting the privacy of consumer data; for example, it could prevent wholesale exporting of the database into some format that could be easily copied or transferred. User agents could refuse to upload their personal data unless the company can prove that it is running one of these privacy-protecting software packages. Adam Back (who opposes Palladium) described several other possible applications all of which rely on secure attestation [4]. He listed: : - general Application Service Providers (ASPs) that you don't have to : trust to read your data : : - less traceable peer-to-peer applications : : - DRM applications that make a general purpose computer secure against : BORA (Break Once Run Anywhere), though of course not secure against : ROCA (Rip Once Copy Everywhere) -- which will surely continue to : happen with ripping shifting to hardware hackers. : : - general purpose unreadable sandboxes to run general purpose : CPU-for-rent computing farms for hire, where the sender knows you : can't read his code, you can't read his input data, or his output : data, or tamper with the computation. : : - file-sharing while robustly hiding knowledge and traceability of : content even to the node serving it -- previously research question, : now easy coding problem with efficient : : - anonymous remailers where you have more assurance that a given node : is not logging and analysing the traffic being mixed by it Of course, one of these is indeed DRM, and no one (least of all Microsoft) denies that DRM will be facilitated by Palladium or that it was one of the motivations for creating the technology. But the rest are all different, and hopefully they provide further evidence that Palladium, in its full form, is good for more than DRM. In particular, the idea of CPU-for-rent farms has been stymied for years because of concerns about sensitive corporate data. Secure attestation could be a breakthrough that will put the incredible power of idle machines to productive economic use, for tremendous benefits to society. The virtualized Palladium can't do any of the applications above, as far as I can see. These are all benefits of Palladium which rely on the secure hardware chip, and they go far beyond DRM. Many of these applications actually serve to enhance the user's security and privacy. I understand you aren't going to reply, but hopefully in your own mind you will see that there are far more benefits to the full version of Palladium, including its security chip, than just DRM. === [1] http://www.hotchips.org/pubs/hc99/hc11_pdf/hc99.s6.1.Rosenblum.pdf [2] http://vitanuova.loyalty.org/2002-07-05.html [3] http://www.salon.com/tech/feature/2002/08/08/gnutella_developers/print.html [4] http://www.mail-archive.com/cryptography@wasabisystems.com/msg02526.html