It's a question of trust. The trust of the content owner in this case. If the content owner is to trust the h/w (which has been called a varient of a media player elsewhere on this list) then it will require a signature from a trusted third party. As has been noted before in the smart card case, trusted third parties need to know that the private key, for which they issue a cert, is well protected. I believe we all agree that the best place to protect a private key is h/w. If you want a cert from a 3rd party with that level of asertion, then YOU need to prove that YOU have provide that level of protection. Both smart cards (see FINREAD specs.) and similar h/w can provide this level of protection. (Pls note that I did not claim that all do, only that they can do it if they chose.) hth ..tom
I have one gap in the picture:
In a previous message in this Peter Biddle said:
In Palladium, SW can actually know that it is running on a given platform and not being lied to by software. [...] (Pd can always be lied to by HW - we move the problem to HW, but we can't make it go away completely).
But what feature of Palladium stops someone taking a Palladium enabled application and running it in a virtualized environment. ie They write software to emulate the SCP, sealing and attestation APIs.
Any API calls in the code to verify non-virtualization can be broken by putting a different endoresment root CA public key in the virtualized SCP.
The Palladium application (without the remote attestation feature) has no way to determine that it is not virtualized. If the Palladium application contains the endoresement root CA key that can be changed. If the application relies on the SCP to contain the endoresmenet key but doesn't verify it that can be virtualized with a replacement fake endoresment root CA public key using the existing SCP APIs.
Then Palladiumized application could be debugged and it's features used without the Palladium non-virtualization guarantee.
Am I free to do this as the owner of palladium compatible hardware running a version of windows with the proposed palladium feature set?
If so how does this reconcile with your earlier statement that:
In Palladium, SW can actually know that it is running on a given platform and not being lied to by software
Then we also have the remote attestation feature which can't be so fooled, but for local attestation does the above break work, or is there some other function preventing that?
Does that imply that the BORA protections only apply to:
- applications which call home to use remote attestation before functioning
- and even here the remote attestation has to be enforced to data separation levels -- ie it has to be that the server provides a required and central part of the application -- like providing the content, or keys to the content -- otherwise the remote attestation call can also be nopped out with no ill-effect (much as calls to dongles with no other effect than to check for existance of a dongle could be nopped)
- applications which are encrypted to a machine key which is buried in the SCP and endorsed by the hardware manufacturer
- however you said in your previous mail that this is not planned
* now about my attempts to provide a concise, representative and readily understandable summary of what the essence of palladium is:
my previous attempt which you point out some flaws in:
Adam Back wrote:
Effectively I think the best succinct description of the platforms motivation and function is that:
"TCPA/Palladium is an extensible, general purpose programmable dongle soldered to your mother board with centralised points belonging to Microsoft/IBM/Intel/".
The Pd SCP isn't extensible or programable.
OK that is true. I presume you focussed on SCP because you took the dongle to mean literally the SCP component alone.
Let's me try to construct an improved succint Palladium motivation and function description. We need to make clear the distinction that the programmability comes from the hardware/firmware/software ensble provided by:
hardware: the SCP, new ring0 and code compartmentatlization
(btw what are the Palladium terms for the new ring0 that the TOR runs in, and what is the palladium term for the code compartment that Trusted Agents run in -- I'd like to use consistent terminology)
super-kernel: TOR operating in new ring0
software: palladium enabled applications using the features such as software attestation, and sealing with control rooted in hardware and the TOR
So would it be fair to characterize the negative aspects of Palladium as follows:
"Palladium provides an extensible, general purpose programmable dongle-like functionality implemented by an ensemble of hardware and software which provides functionality which can, and likely will be used to expand centralised control points by OS vendors, Content Distrbuters and Governments."
So I think that statement though obviously less possitively spun than Microsoft would like perhaps addresses your technical objections with the previous characterization.
btw I readily concede of course that Palladium platform offers the security compartmentalization and software assurance aspects anonymous and Peter Biddle have described; I am just mostly examining the flip-side of the new boundary of applications buildable to data separation standards of security with this platform. One could perhaps construct a more balanced characterization covering both positive features and negative risks, but I'll let Palladium proponents work on the former.
So to discuss your objections to the previous version of my attempted Palladium characterization:
- as you say the hardware platform does not itself provide control points (I agree)
- as you say, the TOR being publicly auditable does not itself provide control points
however the platform can, and surely you can admit the risk, and even the likelihood that it will in fact be used to continue and further the existing business strategies of software companies, the content industry and governments.
The dongle soldered to your motherboard can conspire with the CPU and memory management unit to lock the user out of selected processes running on their own machine.
If you focus on the subset of buildable applications which operate in the users interests you can call this a good thing. If you look at the risks of buildable applications which can be used to act against the users interests it can equally be a very dangerous thing. Also if you look at historic business practices, legal trends, and the wishes of the RIAA/MPAA there are risks that these bad practices and trends will be futher accelerated, exarcerbated and more strongly enforced.
I'd be interested to see you face and comment on these negative aspects rather than keep your comments solely on beneficial user functions, claim neutrality of low level features, and disclaim negative aspects by claiming at a low level user choice. The low level user choice may in the long run prove impractical or almost impossible for novice users, or even advanced users without hardware hacking tools, to technically exercise. (I elaborated on the possiblities for robust format compatibility prevention, and related possibilities a previous mail.)
I wouldn't say that it is "general purpose" either, but I am not sure what you mean by this.
I mean it is programmable in the sense that software attestation, certification and the endoresed new privileged ring0 code, together with the hardware enforced code compartments allow the protections of the firmware and hardware running in the SCP to be extended up to complete applications -- the Trusted Agents running in code compartments.
That makes it general purpse because it is programmable. It could be used to build many classes of application across a spectrum of good, debatable and evil:
- more flexibile and secure anonymity systems (clear user self-interest as anonymous suggested)
- DRM (mixed positive and negative, debatable depends on your point of view)
- and for example key-escrow of SCP support crypto functions implemented in the TOR accessed with say CAPI (very negative)
From my current understanding, the worst problem is the centralised control of this platform. If it were completely open, and possible to fix it's potential dangers, it would bring about a new framework of secured computing and could be a net positive. In it's current form with centralised control and other problems it could be a big net negative.
There isn't centralized control in Pd. Users are in control. It is up to whomever cares about the trust on a given system to decide if they trust it, and this obviously must start with the user.
You're focussing on the low level platform specifics, not on the bigger implications of the overall hardware, TOR, OS and software ensemble which I was talking about. Yes you can run different TORS. But using a specific (and audited published) TOR which the user may find himself choosing to run in order to run Palladium-enabled applications, all the applications, file formats, services and content which are tied to doing that -- control points could and likely will be built.
It is my opinion that the directions and business pressures are such that meaningful distributed control is unlikely to be the long term result of the things that will be built using the Palladium hardware/software ensemble.
This seems a fairly clearly consistent and predictable outcome, unless the software, IP law, RIAA/DMCA and legal systems all make an _astounding_ complete U-turn in policy and tacitcs coincident with the deployment of Palladium.
Can you defend the arguement that Palladium and TCPA don't change the balance of control against the user and against personal control in our current balance between technical feasibility of building software systems enforcing third party control and law?
(btw I'll stop nagging about documentation now, previous mail crossed with your reply on the topic).
Adam -- "You do not examine legislation in the light of the benefits it will convey if properly administered, but in the light of the wrongs it would do and the harms it would cause if improperly administered." -- Lyndon Johnson
--------------------------------------------------------------------- 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