Comments on the TCG Best Practices Committee Document

Recently, the Best Practices Committee of the TCG published a document entitled "Design, Implementation, and Usage Principles for TPM-Based Platforms". The document, which had been in the pipeline for numerous months, is a major contribution of TCG to the policy debate. In my opinion, TCG should be applauded for the document. It provides a rather balanced view of the policy problems surrounding TCG, points to some solutions, but also to the limitations these solutions suffer from. Some of the solutions will, ultimately, not prevent the problems raised, but given the existing organizational structure of TCG, this document was probably the best the TCG could do (and agree upon). I'll come back to this point at the end of my comments which attempt to highlight some of the underlying policy principles as well as to criticize certain aspects of the document.

1. TCG and human interface design

First, there are two issues which the TCG should be applauded for. On page 12 of the document, the TCG recommends to involve human interface experts early on in the process of designing TCG-enabled systems. I think this is a very important point which could avoid quite a lot of policy-related problems from the beginning.

2. Conflicts that are inherently unsolvable

Second, the document should also be applauded for not trying to solve conflicts that are inherently unsolvable. On pages 8-9, the document points to the conflict between the principle of data portability and the principle of security, which, in the TCG framework, is solved at the expense of ease-of-use. On page 12, the document points to the conflict between fine-grained control and ease-of-use. I think it's a real step forward that the TCG highlights these conflicts without pretending that it can ultimately resolve them. Such conflicts just exist and we have to find the best solution that minimizes the conflict.

3. Relying on terms that are not well defined

There are also quite a number of issues which I am not so happy about (but see my caveats at the end of these comments). One such issue is that the document frequently relies on terms that it does not define well:

• The most important term is "security". On page 5, the document states that the attestation of security properties should only be used "for such operations where security provided by attestation is necessary for security." On page 7, the document states that "service providers should not require users to have TCG-enabled technologies in order to obtain service unless the service requires such as level of security." On page 9, the document reommends that "TPM-protected keys should be designated as nonmigratable only where there is a clear security requirement for nonmigratability." Finally, on page 11, the document states that "the consequences of opting out should be made clear to the user and should not extend beyond the minimum required by the owner's security policy." Of course, such statements bear the question what the document means by the term security. It is very easy to hide anti-competitive reasons behind a "security" rationale. Indeed, that is one of the criticisms raised against the Microsoft consent decrees (I have written about this before, see here). Similarly, it is open to debate how to define what the "minimum required by the owner's security policy" really is.
• On page 8, the document demands that "applications using TCG-enabled capabilities to determine system configuration should base their decision to interoperate on the conformance of the measured configuration only for the purpose of clearly-disclosed and publicly-available security goals." In principle, this sounds like a good statement. In practice, as all lawyers know, it is very hard to define what clearly-disclosed and publicly-available mean. To what extent and in what granularity should the security goals be published? Where and in what format?
• On page 10, the document demands that "where any personal information concerning the user will be included in a remote attestation, the user should have effective means to control such inclusion". On page 11, the document requires that each user must have effective notice of the entity making certain security requirements. It goes on by noting that the form of the notice "will likely depend on specific implementation of the TCG technologies and the environment in which it will be used". Also on page 11, the document states that "the consequences of opting out should be made clear to the user". I fully agree that it is very hard and perhaps impossible to define in detailed terms what "effective means", "effective notice" and "making clear" should mean in these contexts. But it still is unsatisfactory that the document leaves us with no guidance what these terms should mean in practice.
• On page 11, in the context of remote attestation, the document states that the "TCG believes that such behaviors are inappropriate uses of the TCG technology. The use of coercion to effectively force the use of the TPM capabilities is not an appropriate use of the TCG technology." I'll comment on this approach further below. At this point, I just wanted to highlight the term "force". Given all the discussions about network effects, information asymmetries etc., it is extremely hard to define when exactly a user is "forced" to use some TPM capabilities and when it is his free decision to use them.

4. Relying on notice and opt-in scenarios

The document demonstrates in various parts that the TCG's solution to competition-related problems is strongly based on market forces. (I have written about this before.) In particular, TCG puts a lot of faith in the efficacy of notice requirements and opt-in solutions.

• On page 6, the document requires that explicit notice of the collection and retention of personal data should be provided. On page 9, the document states that "any application that uses TCG technology to bind data to the platform or application should ... provide appropriate, effective, and timley notice". On page 11, the document requires that appropriate notice should be given to the user by the entity implementing some security policy.
• On page 11, the document states that "TPM is opt-in. The decision for a platform owner to use TCG-enabled capabilities should be one of possitive assent." (see also page 5: the owner's participation must be opt-in). On page 10, the document states that it is important that TCG technology is not used to coerce the use of the technology.

The idea behind this philosophy is the following: If users are provided with adequate notices, they can decide themselves whether they want to use TCG technology. Thereby, TCG imagines that a user-driven competition emerges in which those solutions win which meet the user demands most closely.

It is unfortunate that the document does only write very little about the limitations of this approach. As I have written before on this blog, TCG's philosophy about the beneficial forces of competition rest upon the assumption that such competition will actually occur - which is doubtful due to various market failures. I would have expected that the TCG at least addresses this problem in its document. Unfortunately, the relationship between IT security and economics is still an underdeveloped field, and this is one example where one sees the effects of this.

5. Raising problems without going into details

The document raises many important problems. Unfortunately, it does not go deep into all of them:

• One example is privacy. On page 6, the document provides a good overview of the different principles that TCG-enabled infrastructures should adhere to in regards to privacy protection. It stresses, e.g., the principle of purpose limitation which is an important building block in European privacy legislation. It also appropriately differentiates between private information about the owner and the user of a platform: private information about the user should be under the user's, not the owner's control. On p. 7, the document raises the problem that the endorsement key could, in principle, be used to uniquely identify individual platforms. The document mentions different solutions to this problem (Privacy Certification Authorities, zero-knowledge protocols (which seems to hint to Direct Anonymous Attestation, although DAA is not a zero-knowledge protocol in the strict sense) and some combination of both approaches). It is interesting and perhaps surprising that the document does not adopt a specific viewpoint on whether one of these solutions is preferable over others. From a policy perspective, e.g., the Privacy-CA approach has quite some different implications than DAA. And the DAA approach has its own problems (more on this in a later posting). It would have been nice if the document would have elaborated on this issue more. Of course, it is hard to make any general statements in this area, because the degree of anonymity than can be provided in a given situation crucially depends on the service that is provided, the user accessing the service and so on. But it would have been possible to point out the inherent advantages and disadvantages which the different solutions offered by TCG provide.
• Another example is the policy implications of remote attestation, which has been the focus of much of the policy debate surrounding trusted computing. Although the document raises the issue on pages 10-11, it doesn't go into much detail. In particular, it doesn't address the question whether there are any better solutions to the problem than merely stating that such the use of remote attestation for anti-competitive reasons are deemed inappropriate by the TCG.
• Finally, a small point regarding the data ownership. On two occasions, the paper mentions that principles and practices of data ownership "vary by geography" (on page 4 and on page 9 footnote 7). I can imagine how these statements found their way into the document which was ultimately driven by the attempt to find a compromise upon which the TCG members could agree. However, I don't fully understand how this reference relates to the main statements of the document sections and how important it is.
• From the beginning, the document notes that the separation of the roles of the owner and the user are fundamental to the TCG design (see pages 3-4). According to the document, "the TCG specifications use 'owner' to mean the owner of the system whose policy is being implemented with the aid of TCG-enabled capabilities, while 'user' denotes the individual who is currently making use of the system" (page 4). The document regularly stresses the importance of the autonomy of the owner: the reporting mechanisms are under the control of the owner (pages 4, 5), the owner should have control and choice over the use and operation of TCG-enabled capabilities (pages 5 and 10), TCG provides strong support for the platform owner's security policy (p. 5), and so on. In many cases, this separation between owner and user is unproblematic: In the corporate setting, the owner is the corporation and the user is an employee. In the normal home environment, the owner and user are the same person (page 4). There are, however, cases where this separation becomes blurred (or, more precisely, where there are business interests to blur this separation). The most important case is the mobile sector. Mobile network operators have strong business- and security-related interests in conceptualizing cell phones as an integral part of their networks (one can observe this trend by the increasing branding of cell phones by network operators). While, traditionally, the consumer would be the owner of the cell phone, under this perspective, he is only the user, while the network operator is the owner. Such an allocation of the roles of the owner and user may become problematic as the TCG architecture grants considerably more autonomy to the owner than to the user. The user, e.g., is allowed to disable TCG functionality, but only as long as this does not violate the owner's policy (pages 5, 10; on the problem of using such vague terms as "the owner's policy", see above). The document views such instances as a problem of split ownership (page 10). As a solution, it proposes to modularize ownership ("... each owner should have control only over those functions that are appropriate for their ownership ... the best solution for controllability in the situation of multiple ownership is segmenting TPM functionality", page 10). Although this solution may work, unfortunately, the document again does not go into the details. Who determines what is "appropriate" for an owner to control? What are the limitations to modularizing ownership?

6. Policy principles underlying the TCG architecture

This leads to the question what the policy principles underlying the TCG architecture are.

• Modularization: In the case of split ownership, the document alludes to modularizing ownership as a solution to potential policy problems (see above). In fact, modularization is a general policy principle underlying the TCG architecture. On page 10, the document states that "designers of TPM systems should not reduce the owner's effective control to a single all-or-nothing participation. Such a modificaiton that effectively removes owner control is contrary to the TCG principles. The TCG specifications have been developed to permit the owner to delegate arbitrary subsets of owner capabilities to the user hoewer." On pages 11-12, the document states that the "TCG specifications provide for fine-grained control of the use of TCG-enabled capabilities."
• Biased technology design: It is very interesting to note that the document does not view TCG technology as a neutral technology. On page 3, the document states that the TCG specifications include features that "favor a principled usage of the technology" and contintues by stating the TCG publishes "positively biased technical specifications". On page 9, the document states that "TCG technologies and mechanisms were designed with a strong bias towards supporting implementations that follow the design principles discussed in this document." This statement is interesting because it raises the more general question about value-centered technology design (my own $ .02 about this in the area of DRM and trusted computing can be found here). It is also interesting because many critics would agree with TCG that the technology is biased, but would argue that it is biased in the other direction...
• Relying on market forces: I have written about this quite a lot before on this blog. So I just want to mention some instances where the document relies on this rationale. On page 8, the document states that "solution designers are encouraged to use and create technical and market mechanisms for open, objective certification of relevant properties of TCG-measured components" In footnote 6 on the same page, the document views the "deliberate abscence of a single TCG root" as an example of adherence to this principle. The footnote continutes: "... the specifications foresee self-certification of conformance by component manufacturers, possibly backed by independent certification organizations. The acceptability of any certifications to the bodies that produce platform aliases on demand, and the acceptability of those bodies to particular application environments, is a matter deliberately left to those bodies and their clients." While it is comforting to hear that TCG did not decide to create a single TCG root and wants to leave this issue to market forces, it is at least questionable whether these market forces will not, in the end, lead to a single root which the TCG deliberately did not choose to integrate into the architecture.

7. Inherent limitations of the TCG approach

This leads to some comments about the inherent limitations of the approach adopted by TCG in general and the document in particular.

• Lack of enforcement: On page 13, the document states: "TCG realizes that market forces, coercive behavior, and poor implementations can do much to weaken these principles and that there is little the TCG organization can do to prevent a manufacturer or system designer from subverting the goals of privacy and control, if they are determined to do so. What TCG can do, however, is to say that such implementations fit neither the spirit of the TCG organization nor the letter of the TCG Principles." On page 7, the document states: "Using TCG technology to create barriers to interoperability would violate the interoperability principle and the TCG best practices." On page 3, footnote 1, the document explains that it serves as "guidance rather than as legally binding terms of use". Also according to page 3, "TCG expects that public review, or perhaps independent auditors will check whether companies comply with the TCG best practices." "Preventing potentially coercive and anticompetitive behavioris outside the scope of TCG" (page 11). "TCG anticipates the development of infrastructure to support the privacy functionality designed into the TCG module" (page 5). This all leads to the conclusion that, while TCG has nice words to say about the policy problems of trusted computing, it does not offer any sanctioning mechanisms that help to to prevent such problems. Rather, TCG relies on market forces, self regulation, nice words and positively biased technology design (see page 9 where the document states, in the context of DRM: "TCG technologies may be used to significantly alter the balanceof power in current practices in the usage of information. But, TCG was designed with a strong bias towards implementations that follow the design principles of this document."). From this perspective, TCG can be criticized for providing some nice features that enhance IT security, but leaving the problems these features create to others to solve. The architecture is dependent on certain preconditions being fulfilled which the architecture itself is unable to guarantee (which probably reminds the German readers of the much-quoted cite by Ernst-Wolfgang Böckenförde, a former judge at the German Constitutional Court, that a secular state is dependent on certain preconditions being fulfilled which the state itself is unable to guarantee). It is a challenging question whether the architecture could be designed in a way so that it could guarantee these preconditions on its own. According to the document, TCG is trying to do this by creating "positively biased technologies" and publishing guidelines. Whether that is enough, is another question.
• About the uncontrollability of open infrastructures: However, one should not jump to conclusions too fast. First, it is questionable whether it is possible at all to define an infrastructure that is both open and controllable. If TCG would introduce more control points into its architecture, this could lead to other side effects that could be undesirable from a policy perspective. I don't have a full answer to this question, but just want to note that before one should criticize TCG for what they are doing, one should think about how a better solution to the problem should look like.
• Organizational choices: The lack of efficient enforcement of the TCG policy principles is rooted in the decision by TCG to organize itself as a standard setting organization rather than as an intellectual property owner and licensor. On page 3, the document notes that "there are inherent limitations that a specification setting organization has with respect to enforcement" and, in footnote 1, that "TCG does not own or license any patents or other intellectual property necessary to implement these specifications". This has led Ross Anderson to criticize, at the 3rd DRM conference this January in Berlin, that TCG should have adopted a different organizational structure under which it could have, through IP licensing agreements, controlled more throughoughly for what purposes TCG technology is used. Despite an earlier blog entry , I am somewhat skeptical whether this would be a workable solution. First, it is at least an open question whether IP licenses could be used to create an open and competition-friendly infrastructure (see above). Second, from what one hears, it was and is unlikely that TCG member companies would agree on pooling their IP rights into a single entity. Considering all these constraints, it might be that what the TCG has done with this document is the best it could do.

8. Conclusion

In conclusion, I think it is fair to say that the document can be criticized, in certain cases, for not providing clear definitions of the terms it uses. It is hard to say whether, as the document states on page 2, "every effort has been made to write TCG specifications such that only a clear and single interpretation is possible." The document can also be criticized for not going into details in some areas where this would have been desirable.

On the other hand, I think the TCG should be applauded for this document. Given the current organizational framework in which TCG operates, TCG did quite a lot to point to policy-related problems and some potential solutions. And despite the long history of the creation of this document, it is encouraging to see that TCG could finally agree upon a paper that does not only contain pleasant truths which are easy to market.