Stanford Center for Internet and Society

Jesus Molina (of Fujitsu Labs)

Seth Schoen (from the EFF) (occasionally).

Unlimited Freedom (anonymous blogger) (hasn't posted for a while).

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.
  

Tony McFadden, TPM Matrix. List of known TPM manufacturers and implementations. 2005.

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.
  

Siani Pearson, Trusted Computing: Strenghts, Weaknesses and Further Opportunities for Enhancing Privacy, in: Herrmann et al. (eds.), iTrust 2005, Proceedings, Springer 2005, LNCS 3477, pp. 305-320.

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).

Ulrich Kühn, Klaus Kursawe, Stefan Lucks, Ahmad-Reza Sadeghi & Christian Stüble: Secure Data Management in Trusted Computing. In: Proceedings of the Workshop on Cryptographic Hardware and Embedded Systems (CHES), Springer 2005, LNCS 3659, pp. 324-338. For more information, see here.