palladium presentation - anyone going?
Would someone at MIT / in Boston area like to go to this and send a report to the list? Might help clear up some of the currently unexplained aspects about Palladium, such as: - why they think it couldn't be used to protect software copyright (as the subject of Lucky's patent) - are there plans to move SCP functions into processor? any relation to Intel Lagrange - isn't it quite weak as someone could send different information to the SCP and processor, thereby being able to forge remote attestation without having to tamper with the SCP; and hence being able to run different TOR, observe trusted agents etc. I notice at the bottom of the talk invite it says | "Palladium" is not designed to provide defenses against | hardware-based attacks that originate from someone in control of the | local machine. but in this case how does it meet the BORA prevention. Is it BORA prevention _presuming_ the local user is not interested to reconfigure his own hardware? Will it really make any significant difference to DRM enforcement rates? Wouldn't the subset of the file sharing community who produce DVD rips still produce Pd DRM rips if the only protection is the assumption that the user won't make simple hardware modifications. Adam -------- Original Message -------- Subject: LCS/CIS Talk, OCT 18, TOMORROW Date: Thu, 17 Oct 2002 12:49:01 -0400 From: Be Blackburn <be@theory.lcs.mit.edu> To: theory-seminars@theory.lcs.mit.edu CC: cis-seminars@theory.lcs.mit.edu Open to the Public Date: Friday, Oct 18, 2002 Time: 10:30 a.m.- 12:00 noon Place: NOTE: NE43-518, 200 Tech Square Title: Palladium Speaker: Brian LaMacchia, Microsoft Corp. Hosts: Ron Rivest and Hal Abelson Abstract: This talk will present a technical overview of the Microsoft "Palladium" Initiative. The "Palladium" code name refers to a set of hardware and software security features currently under development for a future version of the Windows operating system. "Palladium" adds four categories of security services to today's PCs: a. Curtained memory. The ability to wall off and hide pages of main memory so that each "Palladium" application can be assured that it is not modified or observed by any other application or even the operating system. b. Attestation. The ability for a piece of code to digitally sign or otherwise attest to a piece of data and further assure the signature recipient that the data was constructed by an unforgeable, cryptographically identified software stack. c. Sealed storage. The ability to securely store information so that a "Palladium" application or module can mandate that the information be accessible only to itself or to a set of other trusted components that can be identified in a cryptographically secure manner. d. Secure input and output. A secure path from the keyboard and mouse to "Palladium" applications, and a secure path from "Palladium" applications to an identifiable region of the screen. Together, these features provide a parallel execution environment to the "traditional" kernel- and user-mode stacks. The goal of "Palladium" is to help protect software from software; that is, to provide a set of features and services that a software application can use to defend against malicious software also running on the machine (viruses running in the main operating system, keyboard sniffers, frame grabbers, etc). "Palladium" is not designed to provide defenses against hardware-based attacks that originate from someone in control of the local machine. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
At 7:15 PM +0100 10/17/02, Adam Back wrote:
Would someone at MIT / in Boston area like to go to this [see end] and send a report to the list?
I went. It was a good talk. The room was jam packed. Brian is very forthright and sincere. After he finished speaking, Richard Stallman gave an uninvited rebuttal speech, saying Palladium was very dangerous and ought to be banned. His concerns are legitimate, but the net effect, I think, was to make the Q&A session that followed less hostile. Palladium sets up a separate trusted virtual computer inside the PC processor, with its own OS, called Nexus, and it own applications, called agents. The trusted computer communicates with a security co-processor on the mother board, and has a secure channel to your keyboard and mouse and to a selected window on your CRT screen. How to prevent the secure channel to the on-screen window from being spoofed is still an open problem. Brian suggested a secure mode LED that lights when that window has focus or having the secure window display a mother's-maden-name type code word that you only tell Nexus. Of course this doesn't matter for DRM since *your* trusting the window is not the issue. All disk and network I/O is done thru the untrusted Windows OS on the theory that the trusted machine will encrypt anything it wants to keep private. Windows even takes care of Nexus scheduling. A major design goal is that all existing software must run without change. Users are not required to boot Palladium at all, and are to be able to boot it long after Windows has booted.
Might help clear up some of the currently unexplained aspects about Palladium, such as:
- why they think it couldn't be used to protect software copyright (as the subject of Lucky's patent)
The specific question never came up. As Brain did say, Palladium is just a platform. People can built whatever they want on top of it. It seemed clear to me that the primary goal is DRM, but as someone else in the audience said (approximate quote) "We always hear that you can't do this or that without trusted hardware. Well, this is trusted hardware." I don't see why anyone would think protecting software copyright could not be done.
- are there plans to move SCP functions into processor? any relation to Intel Lagrange
No. The SCP is based on a smart card core and is to be a "light weight, low pin count chip" with a target cost of $1 in volume. I presume future deals between MS and Intel are always possible. The SCP will support several algorithms, including 2048-bit RSA, 128-bit AES, SHA1, an HMAC. They may include another cipher and another hash. There will also be a FIPS140-2 Random Number Generator and several monotonic counters, but no time of day clock. Each chip will have a unique RSA key pair, an AES key and a HMAC key. The only key that the SCP will reveal to the outside is the RSA public key and it will only do that once per power up cycle.
- isn't it quite weak as someone could send different information to the SCP and processor, thereby being able to forge remote attestation without having to tamper with the SCP; and hence being able to run different TOR, observe trusted agents etc.
There is also a change to the PC memory management to support a trusted bit for memory segments. Programs not in trusted mode can't access trusted memory. Also there will be three additional x86 instructions (in microcode) to support secure boot of the trusted kernel and present a SHA1 hash of the kernel code in a read only register. There may be a hole somewhere, but Microsoft is trying hard to get it right and Brian seemed quite competent.
I notice at the bottom of the talk invite it says
| "Palladium" is not designed to provide defenses against | hardware-based attacks that originate from someone in control of the | local machine.
but in this case how does it meet the BORA prevention. Is it BORA prevention _presuming_ the local user is not interested to reconfigure his own hardware?
Near as I can see, the real trust comes from the RSA key pair stored in the SCP and a cert on that key from the SCP manufacturer. There is no command to obtain the private key from the SCP. Presumably they leverage smart card technology plus what ever tricks they think of to make it hard to get that key. Differential power analysis or HNO3 might do the trick. We'll have to wait and see.
Will it really make any significant difference to DRM enforcement rates? Wouldn't the subset of the file sharing community who produce DVD rips still produce Pd DRM rips if the only protection is the assumption that the user won't make simple hardware modifications.
The real question from Microsoft's stand point is will the entertainment industry be satisfied with Palladium's level of security and release content that can play on Palladium equipped PCs? DVDs aren't Hollywood's main problem. Movies are becoming available online long before the DVD is released. Hollywood probably wants something that monitors ALL content for watermarks. Palladium as presented doesn't do this. But again it is a platform. Once it exists, a later version of Windows might require it to be up and would then verify all content displayed. If Hollywood doesn't convince Microsoft to do this, Sen. Hollings will be more than glad to introduce the necessary legislation. To paraphrase Stallman's rant, in the Palladium context Alice and Bob are corporations and Mallory is the PC owner. Arnold Reinhold
Adam
-------- Original Message -------- Subject: LCS/CIS Talk, OCT 18, TOMORROW Date: Thu, 17 Oct 2002 12:49:01 -0400 From: Be Blackburn <be@theory.lcs.mit.edu> To: theory-seminars@theory.lcs.mit.edu CC: cis-seminars@theory.lcs.mit.edu
Open to the Public
Date: Friday, Oct 18, 2002 Time: 10:30 a.m.- 12:00 noon Place: NOTE: NE43-518, 200 Tech Square Title: Palladium Speaker: Brian LaMacchia, Microsoft Corp. Hosts: Ron Rivest and Hal Abelson
Abstract:
This talk will present a technical overview of the Microsoft "Palladium" Initiative. The "Palladium" code name refers to a set of hardware and software security features currently under development for a future version of the Windows operating system. "Palladium" adds four categories of security services to today's PCs:
a. Curtained memory. The ability to wall off and hide pages of main memory so that each "Palladium" application can be assured that it is not modified or observed by any other application or even the operating system.
b. Attestation. The ability for a piece of code to digitally sign or otherwise attest to a piece of data and further assure the signature recipient that the data was constructed by an unforgeable, cryptographically identified software stack.
c. Sealed storage. The ability to securely store information so that a "Palladium" application or module can mandate that the information be accessible only to itself or to a set of other trusted components that can be identified in a cryptographically secure manner.
d. Secure input and output. A secure path from the keyboard and mouse to "Palladium" applications, and a secure path from "Palladium" applications to an identifiable region of the screen.
Together, these features provide a parallel execution environment to the "traditional" kernel- and user-mode stacks. The goal of "Palladium" is to help protect software from software; that is, to provide a set of features and services that a software application can use to defend against malicious software also running on the machine (viruses running in the main operating system, keyboard sniffers, frame grabbers, etc). "Palladium" is not designed to provide defenses against hardware-based attacks that originate from someone in control of the local machine.
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
On Sun, Oct 20, 2002 at 10:38:35PM -0400, Arnold G. Reinhold wrote:
There may be a hole somewhere, but Microsoft is trying hard to get it right and Brian seemed quite competent.
It doesn't sound breakable in pure software for the user, so this forces the user to use some hardware hacking. They disclaimed explicitly in the talk announce that: | "Palladium" is not designed to provide defenses against | hardware-based attacks that originate from someone in control of the | local machine. However I was interested to know exactly how easy it would be to defeat with simple hardware modifications or reconfiguration. You might ask why if there is no intent for Palladium to be secure against the local user, then why would the design it so that the local user has to use (simple) hardware attacks. Could they not, instead of just make these functions available with a user present test in the same way that the TOR and SCP functions can be configured by the user (but not by hostile software). For example why not a local user present function to lie about TOR hash to allow debugging (for example).
Adam Back wrote:
- isn't it quite weak as someone could send different information to the SCP and processor, thereby being able to forge remote attestation without having to tamper with the SCP; and hence being able to run different TOR, observe trusted agents etc.
There is also a change to the PC memory management to support a trusted bit for memory segments. Programs not in trusted mode can't access trusted memory.
A "trusted bit" in the segment register doesn't make it particularly hard to break if you have access to the hardware. For example you could: - replace your RAM with dual-ported video RAM (which can be read using alternate equipment on the 2nd port). - just keep RAM powered-up through a reboot so that you load a new TOR which lets you read the RAM.
Also there will be three additional x86 instructions (in microcode) to support secure boot of the trusted kernel and present a SHA1 hash of the kernel code in a read only register.
But how will the SCP know that the hash it reads comes from the processor (as opposed to being forged by the user)? Is there any authenticated communication between the processor and the SCP? Adam -- http://www.cypherspace.net/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
I've been trying to figure out whether the following attack will be feasible in a Pd system, and what would have to be incorporated to prevent against it. Alice runs "trusted" application T on her computer. This is some sort of media application, which acts on encoded data streamed over the internet. Mallory persuades Alice to stream data which causes a buffer overrun in T. The malicious code, running with all of T's privileges: - abducts choice valuable data protected by T (e.g. individual book keys for ebooks) - builds its own vault with its own key - installs a modified version of T, V, in that vault with access to the valuable data - trashes T's vault The viral application V is then in an interesting position. Alice has two choices: - nuke V and lose all her data (possibly including all backups, depending on how backup of vaults works) - allow V to act freely I haven't seen enough detail yet to be able to flesh this out, but it does highlight some areas of concern: - how do users back up vaults? - there really needs to be a master override to deal with misbehaving trusted apps. Pete -- Peter Clay | Campaign for _ _| .__ | Digital / / | | | Rights! \_ \_| | | http://uk.eurorights.org --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
At 10:52 PM +0100 10/21/02, Adam Back wrote:
On Sun, Oct 20, 2002 at 10:38:35PM -0400, Arnold G. Reinhold wrote:
There may be a hole somewhere, but Microsoft is trying hard to get it right and Brian seemed quite competent.
It doesn't sound breakable in pure software for the user, so this forces the user to use some hardware hacking.
They disclaimed explicitly in the talk announce that:
| "Palladium" is not designed to provide defenses against | hardware-based attacks that originate from someone in control of the | local machine.
However I was interested to know exactly how easy it would be to defeat with simple hardware modifications or reconfiguration.
You might ask why if there is no intent for Palladium to be secure against the local user, then why would the design it so that the local user has to use (simple) hardware attacks. Could they not, instead of just make these functions available with a user present test in the same way that the TOR and SCP functions can be configured by the user (but not by hostile software).
One of the services that Palladium offers, according to the talk announcement, is:
b. Attestation. The ability for a piece of code to digitally sign or otherwise attest to a piece of data and further assure the signature recipient that the data was constructed by an unforgeable, cryptographically identified software stack.
It seems to me such a service requires that Palladium be secure against the local user. I think that is the main goal of the product.
For example why not a local user present function to lie about TOR hash to allow debugging (for example).
Adam Back wrote:
- isn't it quite weak as someone could send different information to the SCP and processor, thereby being able to forge remote attestation without having to tamper with the SCP; and hence being able to run different TOR, observe trusted agents etc.
There is also a change to the PC memory management to support a trusted bit for memory segments. Programs not in trusted mode can't access trusted memory.
A "trusted bit" in the segment register doesn't make it particularly hard to break if you have access to the hardware.
For example you could:
- replace your RAM with dual-ported video RAM (which can be read using alternate equipment on the 2nd port).
- just keep RAM powered-up through a reboot so that you load a new TOR which lets you read the RAM.
Brian mentioned that the system will not be secure against someone who can access the memory bus. But I can see steps being taken in the future to make that mechanically difficult. The history of the Scanner laws is instructive. Originally one had the right to listen to any radio communication as long as you did not make use of the information received. Then Congress banned the sale of scanners that can receive cell phone frequencies. Subsequently the laws were tightened to require scanners be designed so that their frequency range cannot be modified. In practice this means the control chip must be potted in epoxy. I can see similar steps being taken with Palladium PCs. Memory expansion could be dealt with by finding a way to give Palladium preferred access to the first block of physical memory that is soldered on the mother board.
Also there will be three additional x86 instructions (in microcode) to support secure boot of the trusted kernel and present a SHA1 hash of the kernel code in a read only register.
But how will the SCP know that the hash it reads comes from the processor (as opposed to being forged by the user)? Is there any authenticated communication between the processor and the SCP?
Brian also mentioned that there would be changes to the Southbridge LCP bus, which I gather is a local I/O bus in PCs. SCP will sit on that and presumably the changes are to insure that the SCP can only be accessed in secure mode. At 12:27 AM +0100 10/22/02, Peter Clay wrote:
I've been trying to figure out whether the following attack will be feasible in a Pd system, and what would have to be incorporated to prevent against it.
Alice runs "trusted" application T on her computer. This is some sort of media application, which acts on encoded data streamed over the internet. Mallory persuades Alice to stream data which causes a buffer overrun in T. The malicious code, running with all of T's privileges:
- abducts choice valuable data protected by T (e.g. individual book keys for ebooks) - builds its own vault with its own key - installs a modified version of T, V, in that vault with access to the valuable data - trashes T's vault
The viral application V is then in an interesting position. Alice has two choices:
- nuke V and lose all her data (possibly including all backups, depending on how backup of vaults works) - allow V to act freely
There are two cases here. One is a buffer overflow in one of the trusted "agents" running in Palladium. Presumably an attack here will only be able to damage vaults associated with the product that contains that agent. The vendor that supplies the agent will have a strong incentive to avoid overflow opportunities. The more dangerous case is buffer overflow in Nexus. Brian admitted that this would be disastrous. Obviously QA will be intense. They plan to publish Nexus source code. Brian was even asked if they would publish source for their C compiler. He said they had thought of that, didn't think they could get the VisualC compiler published but are considering coming up with a stripped down C compiler they can release.
I haven't seen enough detail yet to be able to flesh this out, but it does highlight some areas of concern:
- how do users back up vaults?
They realize that the whole back up/upgrade issue is a big concern. Brian briefly presented some very complex schemes for doing this which I didn't grasp.
- there really needs to be a master override to deal with misbehaving trusted apps.
Presumably an intact Nexus can trash any trusted app. And I don't see how any data in the vault could prevent you from loading a clean nexus, say from CD-ROM, as long as the SCP isn't altered and there is supposed to be no way to do that from software.. Arnold Reinhold
Remote attestation does indeed require Palladium to be secure against the local user. However my point is while they seem to have done a good job of providing software security for the remote attestation function, it seems at this point that hardware security is laughable. So they disclaim in the talk announce that Palladium is not intended to be secure against hardware attacks: | "Palladium" is not designed to provide defenses against | hardware-based attacks that originate from someone in control of the | local machine. so one can't criticise the implementation of their threat model -- it indeed isn't secure against hardware based attacks. But I'm questioning the validity of the threat model as a realistic and sensible balance of practical security defenses. Providing almost no hardware defenses while going to extra-ordinary efforts to provide top notch software defenses doesn't make sense if the machine owner is a threat. The remote attestation function clearly is defined from the view that the owner is a threat. Without specifics and some knowledge of hardware hacking we can't quantify, but I suspect that hacking it would be pretty easy. Perhaps no soldering, $50 equipment and simple instructions anyone could follow. more inline below... On Mon, Oct 21, 2002 at 09:36:09PM -0400, Arnold G. Reinhold wrote:
[about improving palladium hw security...] Memory expansion could be dealt with by finding a way to give Palladium preferred access to the first block of physical memory that is soldered on the mother board.
I think standard memory could be used. I can think of simple processor modifications that could fix this problem with hardware tamper resistance assurance to the level of having to tamper with .13 micron processor. The processor is something that could be epoxyied inside a cartridge for example (with the cartridge design processor + L2 cache housings as used by some Intel pentium class processors), though probably having to tamper with a modern processor is plenty hard enough to match software security given software complexity issues. Adam -- http://www.cypherspace.net/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
On Tue, Oct 22, 2002 at 04:52:16PM +0100, Adam Back wrote:
So they disclaim in the talk announce that Palladium is not intended to be secure against hardware attacks:
| "Palladium" is not designed to provide defenses against | hardware-based attacks that originate from someone in control of the | local machine.
so one can't criticise the implementation of their threat model -- it indeed isn't secure against hardware based attacks.
But I'm questioning the validity of the threat model as a realistic and sensible balance of practical security defenses.
Providing almost no hardware defenses while going to extra-ordinary efforts to provide top notch software defenses doesn't make sense if the machine owner is a threat.
This depends. I would say this is an interesting threat model. It makes the attacks non-redistributable. Software-based attacks are redistributable. Once I write a program that hacks a computer, I can give that program to anyone to use. I can even give it to everyone, and then anyone could use it. The expertise necessary can be abstracted away into a program even my mother could use. Hardware-based attacks cannot be redistributed. If I figure out how to hack my system, I can post instructions on the web but it still requires techinical competence on your end if you want to hack your system too. While this doesn't help a whole lot for a DRM goal (once you get the non-DRM version of the media data, you can redistribute it all you want), it can be very useful for security. It can help to eliminate the 'script kiddie' style of attackers. Rick --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
On Tue, 22 Oct 2002, Rick Wash wrote:
Hardware-based attacks cannot be redistributed. If I figure out how to hack my system, I can post instructions on the web but it still requires techinical competence on your end if you want to hack your system too.
While this doesn't help a whole lot for a DRM goal (once you get the non-DRM version of the media data, you can redistribute it all you want), it can be very useful for security. It can help to eliminate the 'script kiddie' style of attackers.
Not really. It depends on what they are exploiting. Does every piece of code need to be validated all the time? Once a program is running, does something running in its code space get revalidated or soes it just run? I don't see how paladium stops buffer overflows or heap exploits or format bugs or any of the standard exploits that are in use today. (Not without crippling the entire system for bot the user and the programmer.) It seems to change little for script kiddies if the machines are going to communicate with other systems. (Unless the DRM holders will control who and how you can connect as well. And they just might do that as well...) The perveyors of this also claim it will stop spam and e-mail viruses. They only way it can do that is by making paladium based systems incompatable with every non-DRM machine on the planet. (So much for getting e-mail from your relatives!) The only problem this hardware seems to solve is shackling the user into what data they can see and use. If Microsoft follows their standard coding practices, the script kiddie problem will not go away with this technology. It will probably increase. And it will be illegal to effectivly stop them.
Software-based attacks are redistributable. Once I write a program that hacks a computer, I can give that program to anyone to use. I can even give it to everyone, and then anyone could use it. The expertise necessary can be abstracted away into a program even my mother could use.
Hardware-based attacks cannot be redistributed. If I figure out how to hack my system, I can post instructions on the web but it still requires technical competence on your end if you want to hack your system too.
While this doesn't help a whole lot for a DRM goal (once you get the non-DRM version of the media data, you can redistribute it all you want).
I think this assumption may be incorrect. In order for content providers to "win" the DRM fight it seems like they need to address two issues. First, put up a big enough barrier for most users that circumventing access controls is infeasible, or simply not worth it. Second, put up a big enough barrier for most users that gaining access to copies of media with the access controls removed is either infeasible, or simply not worth it. I believe tamper resistant hardware solves the first problem, even if, as Adam conjectures, all that is required to access media protected by Palladium is a $50 kit (which remember, you can't obtain legally) and some hardware hacking. This seems to rule out well over %99 of the media consuming public. The problem of obstructing the distribution of media is really a different topic. I think that solving this problem is easier than most folks think. Again, you don't have to totally stop it P2P, or that kid in the shopping mall selling copied CD's. All you have to do is put up big enough technical and legal barriers that the general public would rather just pay for the media. While it may be the case that Palladium is not a serious barrier to the average CS graduate student, Cypherpunk, or even the home user who has a modicum of hardware clue, I don't think this will kill it as an effective technology for supporting DRM, assuming that the software cannot be broken. --Tal --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
At 4:52 PM +0100 10/22/02, Adam Back wrote:
Remote attestation does indeed require Palladium to be secure against the local user.
However my point is while they seem to have done a good job of providing software security for the remote attestation function, it seems at this point that hardware security is laughable.
I think the most important phrase above is "at this point." Palladium is still being designed. I'd argue that the software/firmware portion is the trickiest to get right. It seems rational for Microsoft to let that design mature, then analyze the remaining hardware threats and turn the hardware engineers loose to try to plug them. Palladium has to be viewed in the larger context of a negotiation between Microsoft and Hollywood (I include here all the content owners: movie studios, recording industry, book publishers, etc. ). Hollywood would prefer a completely closed PC architecture, where consumers' use of the computer could be tightly monitored and controlled. They perceive general purpose computing as we know and love it to be a mortal threat to their continued existence. Keeping the content of DVDs and future media locked up is not enough in their eyes. They want all material displayed to be checked for watermarks and blocked or degraded if the PC owner hasn't paid for the content. Microsoft wants to preserve general purpose computing because it realizes that in a closed architecture, the OS would become a mere commodity component and the consumer electronics giants would eventually displace Microsoft. On the other hand, Microsoft needs Hollywood provide the kind of content that will drive PC sales and upgrades. The base line PC platform of today or even two years ago is powerful enough for most consumers and businesses. People are keeping their PCs longer and not upgrading them as often. Most everyone who wants a PC (at least in North America) already has one. Microsoft needs something new to drive sales. I expect Microsoft and Hollywood to haggle over the final specs for Palladium PCs and no doubt additional hardware protection measures will be included. The actual spec may well be kept secret, with NDA access only. Hollywood will hold two strong card at the table: its content and the threat of legislation. I'm sure Senator Hollings is watching developments closely. The big question in my mind is how to get PC consumers a place at the bargaining table. It seems to me that PC consumers have three tools: votes, wallets and technology. The Internet is well suited to political organizing. Remember the amount of mail generated by the modem tax hoax? Consumer boycotts are another powerful threat, given how powerful and upgradable existing computer already are. Technology can provide an alternative way to gain the benefits that will be touted for controlled computing. Anti-virus and anti-DDS techniques come to mind. Also, since I expect an eventual push to ban non-Palladium computers from the Internet, alternative networking technology will be important. The Palladium story is just beginning. Arnold Reinhold --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
participants (6)
-
Adam Back -
alan -
Arnold G. Reinhold -
Peter Clay -
Rick Wash -
Tal Garfinkel