Technical, Business, and Legal Dimensions of Protecting Children from Pornography on the Internet: Proceedings of a Workshop (2002)

David Maher

I designed the secure telephone unit that first used the infamous Clipper chip—which further illustrated, to me, many of the issues involved with trusted third parties. I agree that there are major problems with trying to control what people do on their open-system PCs. But we should not give up just because we cannot design a perfect system to prevent a hacker from hacking PCs. There are techniques that can make hacking difficult, and in particular techniques that can allow business models to be supported in spite of security breakdowns. When I saw CSS several years ago, my colleagues and I in the secure systems world shook our heads and said, “As soon as it’s rolled out, it (the crack) will be on a T-shirt.” In fact, it was. But bad security design does not have to be the rule.

I agree that a lot of infrastructure will have to be rolled out to take advantage of some of the methods and techniques discussed here at these meetings, and many things will have to change. We will become more oriented to digital rights and responsibilities and policies. There will be motivation to roll out some of these techniques, methods, and standards, not only because of digital rights management for the control of copyrighted material in the media and entertainment industry, but also practically for asset management (in enterprises), where some of the challenges are not quite the same. There is a lot of movement and demand to set up the infrastructure for policy and control of the deployment of assets, both within an enterprise and among enterprises.

The context for digital rights management (DRM) has a lot to do with commerce automation, where you have a publisher who wants to publish information, which could be entertainment, pricing information, or a con-

tract, and the publisher wants to give access to the right people, who are allowed to exercise the provisions of the contract. Just about any piece of information that has some value that someone can exercise some right with regard to is the type of thing that you want to be able to control in this sort of system.

At InterTrust Technologies, we give the publishers tools that allow them to place the content in a container that provides any type of protection that the publisher wants. It can be encrypted or not; it can have integrity protection or not. There could be rules associated with the information placed in the container. There also could be other containers linked to that first container that contain additional rules, such as rules that the publisher thought of later on or rules that say that the previous rules are revoked.

Then you go through a distribution chain, which may have several tiers. According to the rules, people can do various things. They could change the unit price of an object that has commercial value, for example, or they could decide that you can forward it to someone else. Just about any action can be controlled at any level of the distribution chain.

Eventually, however, these things get back to the consumer. In our space, the consumer has to agree to rules, either implicitly or en masse. For example, if there is a license associated with something, then the user must agree to the license, which may make an implicit agreement for many other transactions that might happen down the road. But somehow or other, the consumer must be informed about the rules associated with the things that impinge on the consumer.

As an example, a rule might say that an audit record will be created if you engage in a specific transaction—an audit record that itself becomes protected content. This is done in a way such that the consumer is told, “You can have this piece of content for free. We will collect some unlinked, anonymous information about it, but we need to aggregate that information with information from other people.”

InterTrust’s role is to ensure that such things are done in a fair and accurate manner. For example, if someone says, “I will not collect data for an audit record about your use of this,” we can tell whether that statement is true, because we designed many of the mechanisms. The rules say that if an audit record is supposed to be created but instead an anomaly occurs, then the transaction will not go through. The idea is to have automation not just within the Web, but within any local area networks or personal area networks, such that the consumer could, for ex-

ample, have some of this content moved into various other types of devices.

Thus, the commerce network—at least in the way that we represent DRM—contains just about any type of digital information. There are also loosely coupled rules, meaning the rules do not have to be packed with the information in the same file. The file can be delivered in one space and the rules delivered in another. In addition, the rules can change; they can expire and things of that sort.

Another important concept is identity attributes, which are applied to principals who may use the information. Rules can refer to those identity attributes. There is a coding system for identity attributes, and a trust management system for determining which identity attributes are associated with what. The identity attributes also could be associated with pieces of information. For example, a rule might say that if you are a Book of the Month Club member, you get a 25 percent discount. There also has to be something, such as labels, that identifies Book of the Month Club selections. These labels are identity attributes in that space.

Events and consequences are an essential part of the DRM system. The content owner identifies the events; for example, if you want to play this particular game, then you have to pay for it. In such cases, content owners might want to see proof of authorization or payment, or they might prefer to say that a meter in some device is decremented or incremented. Or they may want to have, anonymously or explicitly, the identity-linked information or a record of what happened. Some of these events and consequences are practical. In the medical information arena, for example, people are resistant to hard-coded policies on access to medical records, because in emergency situations these policies would not be appropriate.

Therefore, you need exception mechanisms, which are difficult to implement. The exception mechanism might say, “You can have emergency access if you say who you are; then an audit record will be collected and will flow upstream to a clearinghouse, and later on someone may ask you why you did this.” At least this approach tends to ensure that the exception mechanism is not abused. Such a mechanism could be useful in the context of labeling content so that children can have access to something on which they are doing a report, even though something like P3P or some browsing policy enforcement software, or whatever, otherwise would deny them access. Creating an audit record is problematical, but at least the parent can say, “I understand that you exercise that exception in a fairly straightforward way and I am still monitoring what you are doing in absentia.” When these techniques are applied, the recording of

events, logging, and especially exception mechanisms are absolutely required.

An audit mechanism can be defeated by an attack on the communication between the auditor and desktop. The mechanism that we use assumes that you are not always online (most people are not). We can tell whether or not people tamper with the protected database, up to certain limits. There are thresholds that say, “I must deliver my cache of audit records to wherever their destination is.” The audit server could be part of an enterprise, or you could contract with an ISP to host the clearinghouse for the audit records. Or it could be part of a home network or part of the same machine such that the parent has access to the audit records but the children do not. It is difficult to implement but conceptually straightforward.

We have a network of protected processing environments. We work directly with chipmakers—such as Texas Instruments, and chip platform makers, such as ARM, and other companies making chips that go in settop boxes, cell phones, or personal digital assistants—to put in security mechanisms (e.g., trust management) so that we can have a protected processing environment. This is highly problematic for a PC, as observed by others earlier. The mechanisms that we use for the PC are quite different; they have to do with the concept of renewability, also alluded to earlier.

Trust management, or delegation of trust, involves who and what are trusted to do what, and who determines policy. This has do with, for example, those things you delegate to a parent versus a child, and how you arrange the user interface so that people actually understand the policy on what might be delegated to them—a difficult problem in this space. A couple of years ago, AT&T Labs did a demonstration of P3P policy with a user interface, which I thought was the most crucial aspect of the research done at AT&T labs on P3P. A user interface is how you make all of this material understandable. They made a few policies visible. But these were not granular policies, which are difficult to make people understand. Straightforward policies might be difficult to change on a daily basis, but they can at least be tuned, perhaps when installed, using a somewhat more complicated user interface.

There is also the distribution of policies and rules, which can be broken up into three areas of intent: what you want to do with the content, under what conditions you are allowed to do those things, and what the consequences are. Another important concept is action inquiries, that state the conditions under which I even ask the question, “Am I allowed to do this?” There is also governance of transactions, the overseer that ensures that a transaction is carried out. When the answer to an action inquiry is, “Yes, this is allowed, but . . . ,” then often it is allowed if you pay or if an audit record is created or whatever. This is the concept of a transaction.

Concurrent events either all occur or do not occur together. There are two-phase approaches to ensuring that governance is enforced that are part of the DRM system but distinct from the trust management system.

Another part of DRM is renewability, which I think is key to trying to defeat someone who is determined to circumvent the system. I have been involved in the design of protection for satellite entertainment systems, and the sophistication of attacks on these systems might astound some people. One of the best books on defeating these systems is The Black Book, which has a skeleton and crossbones on the cover. You can order it on the Internet and it is freely available, published by a charming Irishman named John McCormac. It is humorous, but it also has a lot of code and diagrams of how to defeat various satellite receivers. He also publishes a Web site, the Hack Watch News (at <http://www.iol.ie/~kooltek/>), which has been up for years and is probably still there. At one time this site was filled with hacks and boasts of hacks, but now the hacking is uninteresting, and the hackers seem to be having far less fun.

A number of these satellite systems—the predecessors of DirecTV, for example—were mercilessly attacked. I asked them how they designed systems that could be attacked so easily. The answer was something like the following: “Our contract with the service provider just says to keep the pirates’ success rate below a certain level.” This is all they really needed to do. More aggressive approaches were either more expensive or more intrusive to the legitimate consumers. For years, they have been playing that game of keeping the piracy below a certain level while ensuring that the protection measures are not that expensive in a generalized sense, and that includes intrusion on legitimate rights.

The Hack Watch News, which I used to monitor quite a bit, covered what happened when the purveyors of one of these protection systems tried using a renewal technique. As described in an exercise recently with DirecTV, some people had businesses selling hacker versions of smart cards, which were better designed than some of the legitimate smart cards. They gave you access to material that you should not have been allowed to access.¹ Then the algorithms were changed, and the hackers defeated the countermeasure. The algorithms were changed again the second month.² After the third time, the Hack Watch News said there was a pall of defeat. The hackers basically gave up.

I taught a course on some of these things, and I had a cartoon in which a little kid is crying, “Mommy, mommy, I can’t get the Cartoon Channel any more.” The mother says, “Well, we’ll just have to wait until next month when the solution to the next countermeasure is available.” The idea is to keep the legitimate service level, for most people, better than that available from the pirate. There are things that we can learn from that approach, although this problem was different from the one at hand here.³ The satellite pirates were commandeering part of the legitimate system, either for their own benefit as individuals or, in some cases, as part of a business selling smart cards.

We use a secured virtual machine that is independent of the browser.⁴ We keep changing it to defeat the hackers. This method is problematic because we have to get that thing on the desktop. We are arranging to get that capability in all of the forward-looking systems, but we do not have a deal with Microsoft so it is problematic within Internet Explorer. There is reasonably good technology such that, as long as you are connected intermittently, it will allow you to do that. Marimba’s Castanet software does a good job; you tune in to an upgrade channel. I think Real Network uses either Castanet or something similar. It tells you if an upgrade is available, and then gives you an option, which is the standard way of dealing with this. To make our system effective, you would not allow the option for the upgrade. The problem is raising the stakes on who gets the update, so renewability and tamper resistance are essential.

Napster is having a problem now with legacy content. They are trying to put together a system that will use name tagging to prevent distribution of copyrighted material through Napster. Of course, there are already dozens of ways to counteract that approach. But there is also the concept of requiring proof of origination. There are sophisticated systems that check for proof using cryptography techniques. (Hackers do not target these techniques, but rather try to turn off the structure of the secure system, the key management and things like that.) In the case of something like proof of origination, you must have a policy that says, “This system will not read or present any data that lacks proof of origination.” In which case you would have secure labels and so on. You will still have

the issue of what to do about unlabeled content, whether legacy material or not. You need a policy that deals with unlabeled content.

People believe they should get satellite programming or music from Napster for free⁵ because the data are not stored in any encrypted way when someone buys it. This is a fundamental issue. For new things, you can use the lack of an “in the clear” distribution path as the exclusion mechanism; this is the issue with the record industry. But from the perspective of media, do you believe that this type of structure, which, in essence, rents content or distributes rights according to content, will be any more successful outside of the commerce space, where you can basically say, “If you want to do this, then you have to do it this way”? Do you believe that this will ever be successful given all the history?

I am making an actual personal bet that it will. But the path to getting there will not be easy. I look at the forces that resist success and wonder whether they can be overcome. I have spent a lot of time thinking about privacy because of the issue of collecting information about events in distributed systems. I do not think we will have a truly productive distributed computing system unless we know how we can collect information about those events. We are dealing with that in the embedded systems committee. At my company, we say, “Collected information about those things is protected, and we have techniques and policy mechanisms to do that.” How effective we can make them and how can we use distributed trust mechanisms? We know that we cannot do it perfectly, but this does not mean we do not try.

There is also interplay between law enforcement and policy at the government level. In the DRM field, we depend on things such as the Digital Millennium Copyright Act, with which I was not completely happy because of its impact on research. But certain aspects of it are reasonable. Its provisions are important—addressing issues associated with countermeasures, and what risks you take when you try to defeat a countermeasure. If we could get the research aspect right, then I would be happy. There are also other things, such as copyright and patent law.

If you are a purveyor of mechanisms that defeat countermeasures, what consequences do you face? What are the risks? My house does not

have a lot of security systems. Many other people have all types of security systems on their houses. Yet it is very simple to deal with them; you could level a house with a bulldozer, for example, and grab the jewelry. This does not happen because we have laws and law enforcement. The same type of situation will occur here. The cost of the systems clearly has to fall,⁶ and you need a shared infrastructure so that, instead of just a few people paying for it, a lot of people pay a much smaller per-person price for it. This is why the techniques will not be rolled out just yet.

There are solutions coming in a couple of years that will use more sophisticated distributed trust management techniques to increase the barriers to unauthorized redistribution of content.⁷ This will be done on the basis of actions that firms can insist that you do as a condition of receiving their material. I believe this to be true because many larger publishers—including entertainment publishers, such as Time Warner, Universal, Bertelsmann, and Reuters—are funding the establishment of some of these mechanisms.

Carrying out the concepts of trust and policy management is not trivial. We need languages and ways in which we can identify principals. In some of this space, we need to identify principals in an anonymous way. P3P addresses some of this, but I am not sure whether it will do everything that we want without things like exception mechanisms. We need credentials and an artificial intelligence compliance checker. These are not universally available, but there is a drive to make them more available because of their usefulness in commerce. Until these things are embedded in such a way that people interact with automated systems in a natural fashion, it is difficult to believe that the mechanisms will have widespread effectiveness. Some of the research needs to focus on how people interact with these systems.

InterTrust has embedded a trust management system that adheres to these principles into the systems deployed on behalf of its partners. We also play another important role. There must be an administrator; someone has to be copyrighted as the root source of trust. This must be a utility-like function, that is, carried out by someone who specializes in doing these types of things and does not compete with the people for whom these mechanisms are deployed, because there could be bias.

Do we have competitors? Yes, we have competitors. In spaces such as music, our main competitor is Microsoft, which, interestingly enough, does not have the utility-like attribute. Microsoft competes with many service providers, which is what they (the service providers) are afraid of (in making Microsoft a gatekeeper, through their DRM). People expect InterTrust, as an impartial trusted party, not to compete with them as we deploy these types of mechanisms. We are putting legal structures in place to ensure that this happens. DRM is all that we do. We charge a utility fee, which I think is 60 basis points on transactions that use the technology. The reason the Universal music group, Bertelsmann, and a few others have looked kindly on us is because of our impartiality in that we do not compete with them. But we have also heard that they think that 60 basis points is a “cheap date.”