Stanford Center for Internet and Society

In the latest Indicare monitor, several articles on policy-related aspects of TC have been published. See here (on TC and DRM), here (on OpenTC), here (on DRM in OpenTC) and here (summarizing some of my writings).

In December 2005, the TCG published an updated version of its Best Practices document. It is available here.

On March 7, I gave talk on trusted computing at the Berkman Center at Harvard Law School. An audio recording is available here. It is also available on iTunes.

Vivek Haldar has recently started a blog with some interesting postings on P2P and TC, Seth's owner override proposal, and my questions concerning semantic remote attestation.

For those of you who understand German, I have written an article (in German) on legal and policy problems of trusted computing. It is available online here. It is based on a TC talk I gave a few months ago in Stanford, but is much more detailed than the talk, of course.

Seth Schoen has posted a very interesting blog entry about some trends in the trusted computing research community according to which educating users about computer security risks does not work and, therefore, one needs TC to protect the users from risks they cannot assess or are not even aware of. Here are four comments:

• As Seth acknowledges, this paternalistic approach may mean that TC features become implemented in security-sensitive areas only. You could have, e.g., a compartmentalized computer architecture where, "on the left side", you can do anything you want, whereas, "on the right side", a paternalistic TC system controls what you can do with your computer. At the end of his entry, Seth is concerned that, if one accepts this approach, it is tempting, over time, to broaden the "right side" up to a point where the "paternalistic" TC takes over the whole architecture. Some time ago, Eugene Volokh has written an interesting article analyzing these kinds of "slippery slope" arguments. While Seth may be right in warning of the slippery slope, I think it is important to point out why exactly such slippery slope is likely to occur in this context. Furthermore, there are many other policy areas where the mere fact that a slippery slope exists does not prevent us from making a decision that opens this slippery slope a bit.
  

Bruce Schneier has written an interesting and widely-circulated blog entry about TCG's Best Practices document. He is wondering why the document applies to hardware-based TC architectures only, but not to Trusted Network Connect (TNC) and TC architectures that are purely software-based. While I generally agree with his comments, here are three slight qualifications:

• TNC is not necessarily purely software-based. Under TNC, the use of TPMs offers some advantages, but is optional. Therefore, TNC does not require TPMs, but if they are available, it makes use of them.
  

Although much of the policy discussion has focused on the problems created by TCG's remote attestation feature, people like Ross Anderson and, to some extent, Seth Schoen have repeatedly argued that the possibility to seal data to particular platform states is problematic as well, because it may complicate updates and other hardware/software changes, thereby locking consumers into particular hardware/software vendors.

In the area of remote attestation, a few months ago, two papers proposed mechanisms for property-based remote attestation that could solve some of the policy-related problems of remote attestation (see here and the IBM research report called "Property Attestation" available in the literature section below).

Over the last year or so, computer science research on code attestation has increased considerably. I have blogged about current research to overcome the policy problems created by TCG's remote attestation before (e.g., here and here). Recently, researchers from Carnegie Mellon & IBM Watson have published an interesting paper about a fine-grained attestation service called "BIND" (not to be confused with the DNS-related bind program maintained by Paul Vixie). While other approaches attempt to solve the policy problems by attesting a program's behavior or properties (rather than its identity) to a third party, this paper proposes a fine-grained attestation mechanism in which only those parts of a program are attested to a remote challenger that are really crucial for the remote challenger.

In the near future, I'll add a category to this page listing all weblogs that deal with trusted computing. In the mean time, here is a list of the weblogs I am aware of:

• Jesus Molina
• Seth Schoen from the EFF (occasionally)
• Unlimited Freedom (hasn't posted for about a year)

If you are aware of any other TC-related blogs, please send me an email.