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 <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] 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.
