Patent Application
20100037294
A portion of the disclosure of this patent document contains material to which the claim of copyright protection is made. The copyright owner has no objection to the facsimile reproduction by any person of the patent document or the patent disclosure, as it appears in the U.S. Patent and Trademark Office file or records, but reserves all other rights whatsoever. Copyright 2002 OpenTV, Inc.
1. Field of the Invention
This invention relates to security in interactive television and, more particularly, to hierarchical security profile management for programs, services and other applications transmitted in an interactive television environment.
2. Description of the Related Art
The latest forms of television broadcast communication include the possibility of interactive television in which not only does the broadcaster send its programs to the viewer, but the viewer may also send information back to the broadcast source or emitter. Content from the broadcaster typically includes network programs and commercials, as well as web pages, interactive televised programs, graphics and text, and other items. Without restriction, the viewer at the same time may request information from the broadcaster or send data via the television device. Users or viewers may interact with the systems in various ways including, for example, ordering advertised products or services, chatting with other viewers, requesting specialized information regarding particular programs, or navigating through pages of information.
Generally speaking, at one end of this broadcast communication stream is a client integrated receiver/decoder (IRD), such as a set-top box (STB), which receives the transmitted content from a server or head-end. The head-end, generally a network operator in an interactive television environment, collects the signals from various networks (e.g. CNN, ESPN, etc.) and transmits them to its clients (e.g. STBs) along with a variety of additional content including E-Commerce services and interactive programs. The STB connects to the television set and typically sits on top of it. This IRD operates computer programs referred to herein as middleware which controls the flow of transmitted programs, interactive programs and internet traffic transmitted from the server head-end as well as data sent/received by the viewer to the head-end via the IRD. The IRD is generally configured to handle the bi-directional flow of data. In an interactive environment some programs provide for strictly one-way communications, other programs provide for two-way communications, and still other programs provide optional modular programs through which the viewer might gain further information on a point of interest. Due to the integration of many different media formats, the IRD may also be able to recognize the different media formats of the content, such as the difference between the form and protocol of a web page, and that of a television commercial.
Furthermore, due to the fact that each type of communication for each program has its own level of interaction and/or its own protocol, it may be desirable to require a particular level of security in order to identify the allowed level of interaction for a program and maintain the integrity of the communication. Due to the interactive nature of the medium, it is desirable to define a security policy to regulate the type of access available to a viewer and the level at which viewer programs running on the IRD may interact with other entities, such as the head-end server, and other clients and with each other.
In the past, either the security policy was fixed, i.e., hardwired into the IRD, or the head-end server formulated and provided a security policy for controlling the access of programs (e.g. such as an XML declaration in a file associated with each program downloaded from the server to the client IRD). The security policy relating to programs running on the IRD was typically defined by a policy maker. A Security Manager, a program running on the IRD, then moderated the services that the IRD performed relative to the provided security policy.
Several security policies paradigms exist in prior art. One example of such a paradigm, the JAVA TV API, includes the JAVA 2 Platform Security Architecture, which defines a framework consisting of security related APIs for enforcing a security policy in a JAVA execution environment. The JAVA TV API does not dictate a particular security model or policy, but uses the JAVA development Kit (JDK) 1.2 security architecture to express the security policies that are provided by the application environment. This solution provides architects, such as network operators and standards organizations, the freedom to redefine their security models as future needs change. The JAVA 2 Platform Security Architecture does not mandate a format for the Security Policy though it does provide an example/default implementation. This example implementation provides a system-wide security policy and a user-specific policy file. In the digital television environment, Digital Video Broadcasting's (DVB's) Multimedia Home Platform (MHP) and the Advanced Television Systems Committee's (ATSC) Digital Television Application Software Environment (DASE) are both based on JAVA TV technology.
Another example of a prior art security policy implementation paradigm may be found in the Multimedia Home Platform (MHP) 1.0 and 1.1 specifications (which are specific instantiations of the JAVA 2 Platform Security Architecture discussed above). The resource access policy for MHP is derived from the access rights requested by the broadcaster or head-end and access rights granted by the user. This method defines a format for a security policy on a per application basis via a “permission request file”. The permission request file defines those resources that the associated application can access.
Yet another method for designating security permissions is the Digital TV Application Software Environment (DASE). The DASE Level 1 draft specification defines two policy files, one being a broadcaster's permissions file and the other applying specifically to the individual applications. The broadcaster permissions file applies to all downloaded applications executed and typically defines those operations the broadcaster will permit an application to execute. The application's permission file defines specifically which resources to which an application can request access. The actual security policy implemented by the IRD is the intersection of the broadcaster and application's permission files. The overall security profile consists of the broadcaster's policy and of the specific policy associated with the application. This approach provides a two-level security implementation wherein both files are transmitted and are specifically associated with each individual application or program by the Security Manager.
In the interactive television environment, communication bandwidth and processing capability are limited in the typical client. In addition, there are numerous different types of applications, each of these types potentially requiring their own distinct set of security permissions. Thus, there is a need for an efficient and flexible method and apparatus for implementing a security policy that enables customized security policies for different applications.
A broadcaster security policy that may be imposed by a policy maker upon a class of entities in an interactive television environment is disclosed. A general policy is defined for a class of entities. A specific policy may also be defined for any subclass of entities, such as the grouping of advertisements or programs. A specific policy may be defined for any given entity, such as a specific television program as an exception to a class. Thus, the hierarchical security program object described herein may be more efficient and more general than known security specifications which define security and security permissions separately in a file provided along with each individual application.
While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims.
In a typical program structure for interactive television, the presentation of network programs and interactive applications and events are controlled by computer. Television shows and advertisements are specific instances of data and computer applications. The television shows themselves are typically encoded in MPEG format. In addition, the broadcaster may also insert computer programs into the transmitted stream for download to the client IRD through which the viewer may interact with the application and/or make viewing decisions. Given that the client IRD may execute a transmitted program, the network must consider the risk of sabotage and both intentional and unintentional mischief. It is necessary to be careful not to inadvertently transmit or enable transmission of either a TV or computer virus. Each inserted program or application has different levels of required or permissible interaction with the viewer and the hosting client (i.e. IRD). It is generally preferable to disable capabilities that may be not needed or desired during an application's execution, but which, if otherwise allowed could be disruptive to communications or to the integrity of the operating environment and data at both the head-end server and/or the client.
In one embodiment, a server transmits the security restrictions or permissions to a receiver client (e.g. STB) that the server wishes to impose on the client by transmitting a hierarchical security policy object (HSPO) to the client. The HSPO provides a security inheritance structure. In one embodiment, the HSPO may be one object (e.g. a single file) but may alternatively be distributed across many such objects. In one embodiment, the HSPO may be organized as a tree with one root. The root of the HSPO tree contains the most general and universal security restrictions and exceptions such as the security restrictions for the head-end which are enforced on all networks and content transmitted by the server, for example. Successive nodes branching off of the HSPO root contain more specific security requirements, the level of specificity increasing with the increasing distance or “order” of the nodes away from the root.
Each node of the HSPO tree represents a class or subclass of applications and the additional restrictions, or additional privileges, which the client receiver is to impose or grant to entities such as applications in the corresponding class or subclass. The final set of restrictions/privileges that is imposed/granted to a given application are derived (typically by a security manager with a receiving IRD) from this HSPO by following a defined procedure for combining the appropriate nodes of the HSPO tree along with any additional restrictions imposed by the client (i.e. IRD). Thus, an application inherits the security attributes of the class to which it belongs and all the security attributes of predecessor nodes in the HSPO tree. For example, in one embodiment, the lowest node in the tree corresponding to the application is identified and a union of all the restrictions/privileges of this node's ancestor nodes is performed. This structure may prove efficient in that the implementation of a new application, by design, requires the specification of a smaller set of security requirements at the time of implementation. That is, only exceptions to the existing security policy need be specified for a group of applications or an individual application. Accordingly, arbitrary types of applications may have a uniform set of security requirements automatically imposed.
Nodes branching off of the HSPO root node may represent a network or a class of applications, such as advertisements or network programs, and nodes subordinate to these nodes segment these security classes into further subclasses. Generally, the security level at one class level is more or less restrictive than its parent class. Security levels can also vary at the same class level.
Turning now to
System information provided to the set top box 28 also includes a list of services (e.g. CNN, MTV, ESPN) available to a viewer, event names (e.g. Dateline, Star Trek), and a schedule of the events (e.g. start time/date and duration). The service gateway 246 provides a communication link between the client (e.g. STB 28) and service platform (head-end server) 50 of
Using a hierarchical security policy object (HSPO) to impose security restrictions or permissions on a receiver client (e.g. STB 28 of
Turning now to
In one embodiment, the HSPO creation and policy maker functionality may exist in the service manager 238. In an alternative embodiment, the HSPO policy maker functionality may be located in the client. Service content may be retrieved and converted into a SP suitable format by H2O 248. For example, H2O 248 may be configured to convert HTML content into SP/client readable content. The converted content is formatted into a data carousel and multiplexed by the Open Streamer 256 for broadcast to the client 212. Client 212 interacts with the services and, if necessary and permitted by the HSPO, communicates with the SP 50 and the services 200. Point to Point (PTP) communication between the STB and SP goes through service gateway (SGW) 246.
Turning now to
Generally speaking, the security policies at the NBS level 302 are to be applied to all members of the same class and subordinate classes. Thus for the NBS network level 302 which would be below the head-end level, the security policy set by the policy maker is defined by NBS. At this level, a high degree of security is imposed. Typically, each group level of application type imposes different security based on the specific desired and selected security requirements for each group. For example, due to their trustworthy nature, applications within the “OTV App Policy” 310 class, which in one embodiment are written in “C” code, are permitted a less restrictive security policy than those within the “Ad Policy” 312 class. This is because the OTV applications come from a trustworthy source and are deemed less risky. Thus, OTV applications may be afforded a more permissive, less restrictive set of security restrictions. Similarly, applications at the same class level may have differing levels of security. For instance, the “Weather App Policy” 316 application might be allowed more capabilities, due to its trustworthy character from a known source, than the “Gilligan's Island App Policy” 318 application, which may originate from a syndicated external source and thus deemed less trustworthy.
In this example, we assume the receiver/client STB already has a copy of the HSPO 300 either previously transmitted from the head-end, downloaded from the internet or programmed into client memory. When the TV station requests that the receiver start up the application associated with, for example, the “Coca Cola™” advertisement, the IRD/receiver must first determine what security restrictions to enforce upon the application. The IRD/receiver takes those restrictions defined by the highest level or “Root” policy 302, for example, “no-lifecycle-control”, adds any additional restrictions defined by the “Ad” policy 312, for example “no-modem-access”, and finally includes restrictions defined specifically for the “Coca Cola™ App policy” 320, for example “no-cookies.” The resulting broadcaster's security policy for the “Coca Cola™” application could, for example, be the union of these policies defined in the HSPO: “no-lifecycle-control, no-modem-access, no-cookies”, that is, the node inherits the security attributes of its class and all preceding nodes in the HSPO tree.
As is shown in
Returning to
Using the HSPO security restrictions may prevent the necessity of transmitting a set of broadcaster security restrictions along with each broadcast program. The HSPO may be more efficient in that an HSPO need be transmitted only once, or programmed into a client/STB. Thereafter, only exceptions to the established HSPO may need to be transmitted for an application. Once an exception is established in the HSPO, it becomes part of the HSPO tree and need not be transmitted again.
HSPO security restrictions may be useful to prevent programs broadcast or downloaded to a client from a server head-end from performing actions considered risky by that server, such as contracting a virus by interaction with the outside world (i.e. the Internet, email or other programs internal or external to the client (e.g., STB)).
HSPO security restrictions may also disable capabilities or access to memory locations and data, which, may be inadvertently accessed due to programming error. The HSPO may also enable access or deny access to encrypted and/or protected data.
In one embodiment, each level of a HSPO structure may be specified by a different entity. For example, at the top level, a head-end, defines a top-level security restriction, such as “no JAVASCRIPT execution” during a program. In addition, a network (e.g., HBO, NBC, ABC, CBS, ESPN, etc.) may add additional security restrictions to the program, (e.g., no modem access to the next network node level in the HSPO). At the next HSPO node level, a program producer may specify an additional security restriction for the program. At the next level, an advertisement producer can specify an additional security restriction for the program or even a more permissive policy for the program than inherited from the HSPO hierarchical structure and so on.
Depending on the existing HSPO and security policy—a more permissive advertisement policy may or may not be honored. In one embodiment, a lower level security object may override an inherited security restriction from a higher level HSPO node.
It is noted that although the embodiments described above have been described as residing in an interactive television environment, it is contemplated that other embodiments may reside in and/or operate in any distributed computer system including a server and a client device. The client device may be a hand held computer, cell phone, personal digital assistant or any device capable of receiving and/or transmitting an electronic signal. The server may be any device capable of transmitting and/or receiving an electronic signal. Further, the embodiments described above may be implemented as a set of instructions conveyed via a carrier medium such as a broadcast signal, or on a computer readable medium, comprising ROM, RAM, CD ROM, Flash or any other computer readable medium, now known or unknown such that when executed cause a computer to implement the embodiments described above.
Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.
This application claims benefit of priority to Provisional Application Ser. No. 60/360,100 filed Feb. 27, 2002.
| Number | Date | Country | |
|---|---|---|---|
| 60360100 | Feb 2002 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10375860 | Feb 2003 | US |
| Child | 12603323 | US |
