DE69936344T2

DE69936344T2 - Dynamischer schutz für digitale fernsehempfänger

Info

Publication number: DE69936344T2
Application number: DE69936344T
Authority: DE
Inventors: Petr San Diego Peterka
Original assignee: Arris Technology Inc; General Instrument Corp
Current assignee: Arris Technology Inc
Priority date: 1998-06-18
Filing date: 1999-05-14
Publication date: 2008-02-28
Anticipated expiration: 2019-05-15
Also published as: ATE365422T1; WO1999066714A1; EP1088446B1; NO20006437D0; EP1088446A1; DE69936344D1; AU3904699A; NO20006437L

Description

Die vorliegende Erfindung stellt ein System zum Steuern des Zugriffs auf die Empfängerfunktionalität und auf Daten von heruntergeladenen Anwendungen in einem Empfänger für digitales Fernsehen bereit.
Die vorliegende Erfindung wendet sich dem Thema der Sicherheit und der Sicherheitsrichtlinien in dem Anwendungsumfeld von digitalem Fernsehen (DTV) zu. Insbesondere erweitert die Erfindung die Java (tm) Sicherheitsarchitektur, ein Produkt von Sun Microsystems. Die Erfindung ist jedoch nicht auf eine Implementierung der Programmiersprache Java beschränkt.
Der Artikel „The Multimedia Home Platform – an overview" von J. P. Evain, veröffentlicht auf den Seiten 4-10 in EBU Technical Review am 21. März 1998, bietet eine Einführung in MHP-Empfänger und ihre Sicherheitsfunktionen. Der Artikel „JTV – Java-enabled Television" von P. Thrift und T. Killian, veröffentlicht unter den Berichten von SPIE, Bd. 3228, Seiten 117-122, am 4. November 1997, gibt einen allgemeinen Überblick einer Erweiterung von Java für Fernsehgeräte.
Java ermöglicht Programmierern, interaktive Multimedia-Anwendungen für das WWW zu erzeugen. Zum Beispiel können Java-Anwendungen, die als „Applets" bekannt sind, eine Animation, einen Videoclip, ein interaktives Spiel oder andere unterhaltsame oder bildungserzieherische Werkzeuge beinhalten.
Die Applets werden heruntergeladen und ablaufen gelassen unter der Verwendung eines Browsers auf einem Computer eines Benutzers. Der Computer kann mit einem Empfänger für digitales Fernsehen, welcher die Applets z. B. von einem Kabel- oder Satelliten-Fernsehleitungsnetz oder von einer separaten Telefonverbindung empfängt, verbunden sein.
Ein Applet wird in Java geschrieben, dann in ein Byte-Code-Format kompiliert. Eine HTML-Marke „<APPLET>" kann dann verwendet werden, um das kompilierte Applet von einer gegenwärtigen Website zu holen. Oder das Applet kann von einer bestimmten URL unter der Verwendung des HTML-Begriffs „CODEBASE" geholt werden.
Sicherheit ist ein wichtiges Thema, wenn Applets auf einen Computer eines Benutzers heruntergeladen und ausgeführt werden. Es ist zum Beispiel wünschenswert, zu verhindern, dass ein Applet auf bestimmte Ressourcen des Computers zugreift. Ein Applet, das von einem Angreifer produziert wurde, könnte Informationen, die bereits auf dem Computer gespeichert sind, auslesen und sie über ein Netz an den Angreifer zurückschicken, Dateien, die bereits auf dem Computer gespeichert sind, zerstören oder Ressourcen aufbrauchen, wie etwa die Computerplatte voll machen.
Es wäre wünschenswert, einen Mechanismus bereitzustellen, um lediglich bestimmten Benutzern Zugriff auf die Empfängerfunktionalität und/oder die Applets z. B. in einem Teilnehmer-Fernsehleitungsnetz zu ermöglichen. Zum Beispiel können die Applets verwendet werden, um verbesserte Merkmale bereitzustellen, wie etwa Kanalführer am Bildschirm, Börsentickerinformationen, Wetterinformationen, Sperrfähigkeit durch ein Elternteil und Programmklassifizierungssteuerungsdurchführung. Zugriff sollte nur bestimmten Benutzern gewährt werden, z. B. bei Bezahlung zusätzlicher Gebühren.
Die vorhandenen Sicherheitsmechanismen sind jedoch nicht ausreichend flexibel, um diese Herausforderungen zu erfüllen.
Sicherheitsschemata des Stands der Technik analysieren die Quelle einer Anwendung (einheitliche Quellenangabe oder URL, von woher sie ist) und/oder eine Reihe von Signaturen (Schlüssel), die die Anwendung authentifizieren, und weisen sie einer Sicherheitsdomäne zu, auf der Basis der lokalen Richtlinieneinstellungen, die wiederum durch eine Anwendungsquelle, einen Signatar und eine Reihe von Erlaubnissen definiert sind. Sobald die Sicherheitsdomäne entschieden ist, ändert sie sich nicht mehr.
Die gegenwärtige Java-Sicherheitsarchitektur ist um Sicherheitsdomänen zentriert, auf der Basis der Anwendungsquelle, ihrer Signatare/ihres Signatars und einer Reihe von Erlaubnissen, welche den Anwendungen gewährt wurden. Sobald die Erlaubnisse entschieden sind, sind die Erlaubnisse, die einer Anwendung gewährt wurden, statisch und ändern sich während der Dauer der Anwendung nicht (außer die Richtlinienkonfiguration ändert sich).
Dementsprechend wäre es wünschenswert, eine Sicherheitsrichtlinie bereitzustellen, die dynamische Erlaubnisse gewährt, z. B. auf der Basis einer Bestimmung, ob das gegenwärtige Umfeld die Zustände der Erlaubnis, welche die gegenwärtige Situation des Empfängers betreffen, befriedigt (d. h. zu der Zeit, wenn die Erlaubnis geprüft wird, nicht zu der Zeit, wenn die Erlaubnis gewährt wird).
Es wird die folgende Terminologie verwendet:
Anwendungsquelle – Standort, von wo die Anwendung heruntergeladen wurde, meist in einem URL-Format. Für Rundfunkumfelder wird das URL-Format auf der Basis des Internets erweitert, um ein MPEG-2-Netz, einen Transportstrom und -dienst, eine Ereignisidentifikation und einen Karusselldatendateinamen abzudecken. Die Anwendungsquelle wird in der Java-Sprache auch als „CodeSource" bezeichnet;
Empfänger für digitales Fernsehen (DTV) – eine Vorrichtung, die fähig ist, digitale Fernsehsignale, einschließlich Video-, Ton- und Datenkomponenten, zu empfangen;
Erlaubnis – macht den Zugriff auf Systemressourcen, Empfängerfunktionen, private Daten des Benutzers und andere sensible Ressourcen, welche Schutz verdienen können, möglich;
Richtlinie – stellt eine Verbindung zwischen den Erlaubnissen, den Anwendungsquellen und den Signataren bereit; und
Signatar – stellt eine Identifizierung einer Entität bereit, welche die Anwendungsquelle digital signiert hat.
Für weitere Terminologie kann auf Folgendes verwiesen werden: ATSC Program and System Information for Terrestrial Broadcast and Cable, (PSIP), A65, Dez. 1997, und Java Security Architecture, Li Gong, 2. Oktober, 1998, DRAFT DOCUMENT (Revision 1.0), verfügbar unter
http://java.sun.com/products/jdk/1.2/docs/guide/security/spec/security-spec.doc.html.
In einem Rundfunkumfeld für Digital-TV sind die Umstände komplexer als das, was die gegenwärtige Java-Sicherheitsarchitektur anspricht. Anwendungen werden oftmals mit virtuellen Videokanälen, die ein Benutzer schaut, verbunden. Eine Anwendung, die mit diesem Kanal oder einer Reihe von verwandten Kanälen verbunden ist (PSIP-Hauptkanalnummer kann die Gruppierungsfunktion sein), sollte mehr Zugriffssteuerungserlaubnisse bekommen als eine Anwendung, die mit einem Kanal von einer anderen Gruppe verbunden ist, welche in diesem Moment nicht geschaut wird. Dies bedeutet, dass, falls eine Anwendung immer noch ablaufen gelassen wird, nachdem der Benutzer einen anderen Kanal einstellt, z. B. möglicherweise außerhalb der virtuellen Hauptkanalnummer oder eines DVB-Bouquets (Digital Video Broadcast Bouquet), sollte sie manche oder alle ihre Erlaubnisse verlieren.
Ein DVB-Bouquet ist ein Konzept der Gruppierung von Diensten (Kanälen), die zusammen auf unterschiedlichen Transportströmen und/oder Netzen rundgesendet werden, auf der Basis eines Anbieters oder einer Inhaltsart oder dergleichen. Es wird durch eine BAT (Bouquet Association Table) in dem DVB-Diensteinformations-Protokoll (SI-Protokoll) dargestellt.
Ebenso wäre es wünschenswert, dass die Erlaubnisse einer Anwendung durch die Privilegien des gegenwärtigen Benutzers, die Situation des Empfängers und/oder die momentane Zeit beschränkt werden. Dies erfordert, dass die Sicherheitsrichtlinie dynamisch ist.
Es sollte beachtet werden, dass manche Anwendungen nach einem Kanalwechsel automatisch beendet werden, jedoch können die Anwendungen, die nicht direkt mit dem Video, welches angesehen wird, verbunden sind, über Kanalwechsel hinweg fortdauern.
Dementsprechend wäre es wünschenswert, eine Sicherheitsrichtlinie bereitzustellen, die die oben erwähnten Bedenken angeht. Eine derartige Sicherheitsrichtlinie sollte es ermöglichen, dass eine Anwendung, die mit einer Gruppe von Kanälen (z. B. der ABC Hauptkanalnummer 10) verbunden ist, unter der Verwendung einer Reihe von Erlaubnissen über Kanalwechsel hinweg innerhalb dieser Gruppe fortdauert. Sobald der Benutzer etwas anderes als die ABC-Domäne einstellt, sollten der Anwendung manche oder alle ihre Erlaubnisse verwehrt oder sie vollständig beendet werden.
Darüber hinaus wäre es wünschenswert, eine flexible Sicherheitsrichtlinie bereitzustellen, die Anwendungen, wie etwa ein Navigations-/Kanalführer innerhalb eines Verteilnetzes (wie etwa ABC) erlaubt, jedoch verhindert, dass derartige Anwendungen Benutzer von einem anderen Netz (wie etwa NBC) lenkt, wobei der Zugriff auf andere Netzte oder andere Arten der Attacke verhindert werden. Die Sicherheitsrichtlinie sollte die widersprüchlichen Erfordernisse lösen, die auf der einen Seite erzwingen, dass eine Anwendung bei einem Kanalwechsel beendet wird, um zu verhindern, dass das Logo von ABC oder andere Nachrichten auf dem Kanal von NBC auftauchen, und auf der anderen Seite ermöglichen, dass Anwendungen, wie etwa Börsenticker oder Navigations-/Kanalführer nach Kanalwechseln fortdauern.
Des Weiteren wäre es wünschenswert, ein System bereitzustellen, das es ermöglicht, dass Diensteanbieter, Hersteller von Konsumelektronik (CE), Endbenutzer oder Normungsorganisationen (wie etwa ATSC – Advanced Television System Committee) flexible Sicherheitsrichtlinien für die Ausführung von heruntergeladenen Anwendungen auf DTV-Empfängern definieren.
Es wäre wünschenswert, dass die Sicherheitsrichtlinie für die Verwendung mit Sperrfunktionen durch ein Elternteil, Klassifizierungssteuerungen und Kreisgegend-Ausfall (circular blackout) geeignet ist.
Es wäre wünschenswert, dass die Sicherheitsrichtlinie, falls gewünscht, unabhängig von der Benutzer-Interaktion ist. Die Sicherheitsrichtlinie sollte mehrere gleichzeitige Anwendungen unterstützen und die gegenwärtige Situation einer Set-Top-Box verwenden, die sich zu jeder Zeit ändern kann (z. B. die gegenwärtige Kanalnummer, die gegenwärtige Berechtigungssituation, der gegenwärtige Benutzer etc.), um das Resultat einer Sicherheitsrichtlinienerlaubnisprüfung zu bestimmen.
Es wäre ebenfalls wünschenswert, der Sicherheitsrichtlinie die Fähigkeit bereitzustellen, eine Benutzereingabe zu akzeptieren.
Die vorliegende Erfindung stellt ein System mit den oben erwähnten und weiteren Vorteilen bereit.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung stellt ein System zum Steuern des Zugriffs auf die DTV-Empfängerfunktionalität, Ressourcen und Benutzerdaten von heruntergeladenen Anwendungen in einem Empfänger für digitales Fernsehen (DTV-Empfänger) bereit.
Ein Sicherheitsverfahren zum Steuern des Zugriffs auf eine Funktion eines Empfängers für digitales Fernsehen umfasst die folgenden Schritte:

(a) Bereitstellen einer Software-Anwendung an dem Empfänger (wie etwa einen Java-Code); wobei die Software-Anwendung mit einer verbundenen Sicherheitsrichtlinie verbunden ist und als Antwort auf einen Ausführungsbefehl ausführbar ist;
(b) Bereitstellen von Zustandsdaten, die einen Zustand des Empfängers definieren, bei dem der Zugriff auf die Empfängerfunktion durch die Software-Anwendung erlaubt wird (z. B. kann der Zustand der gegenwärtig eingestellte Kanal, die Zeit des Tages, der gegenwärtige Zuschauer, der Sperrstatus durch ein Elternteil und dergleichen sein);
(c) Bereitstellen eines Steuersignals zum Anfordern des Zugriffs auf die Empfängerfunktion nach der Ausführung der Software-Anwendung;
(d) Bestimmen, als Antwort auf das Steuersignal, ob die verbundene Sicherheitsrichtlinie der Software-Anwendung eine Erlaubnis für die Software-Anwendung, auf die Empfängerfunktion zuzugreifen, enthält;
(e) wenn die Sicherheitsrichtlinie die Erlaubnis enthält: (i) Bestimmen, ob der Zustand des Empfängers erfüllt wird, indem Situationsdaten, die eine gegenwärtige Situation des Empfängers anzeigen, evaluiert werden; (ii) Ermöglichen, dass die Software-Anwendung auf die Empfängerfunktion zugreift, wenn der Zustand erfüllt wird; und (iii) Verhindern, dass die Software-Anwendung auf die Empfängerfunktion zugreift, wenn der Zustand nicht erfüllt wird; und
(f) Verhindern, dass die Software-Anwendung auf die Empfängerfunktion zugreift, wenn die Sicherheitsrichtlinie die Erlaubnis nicht enthält.

Beispiele der Anwendung, der Erlaubnis und des Zustands umfassen Folgendes:

1. Anwendung: Bouquet-EPG (Electronic Program Guide; elektronische Programmzeitschrift), Erlaubnis: ausführen, Zustand: der gegenwärtige Kanal befindet sich innerhalb derselben Gruppe von Kanälen (z. B. definiert durch eine Hauptkanalnummer oder durch einen Bouquet-Anbieter), von der die Anwendung heruntergeladen wurde;
2. Anwendung: Kinder-EPG, Erlaubnis: fernsehen (Kanäle einstellen), Zustand 1: die momentane Zeit liegt zwischen 8 Uhr morgens und 8 Uhr abends, Zustand 2: der Kanal, welcher geschaut oder eingestellt werden soll, muss als Inhalt für Kinder gekennzeichnet sein;
3. Anwendung: interaktiver TV-Einkauf, Erlaubnis: Zugriff auf (Lesen) von Kreditkartennummern, Zustand: der gegenwärtige Benutzer muss „ein Elternteil" sein;
4. Anwendung: Kanäle anschauen mit einer Klassifizierung über der Klassifizierungsobergrenze, Erlaubnis: Überschreiben der Programmklassifizierungsobergrenze, Zustand: der Benutzer muss einen gültigen PIN-Code bereitstellen;
5. Anwendung: Werbung mit einem Bestellformular, Erlaubnis: ausführen über die angesetzte (zugewiesene) Zeit hinaus, Zustand: der Benutzer muss die Aktion bestätigen.

Der Zustand kann eine bedingte Zugriffssituation des Empfängers anzeigen.
Die bedingte Zugriffssituation kann eine Ausfallsituation (z. B. ist ein Ausfall gewisser Programme in Kraft?), eine Per-Sendung-Bezahl-Situation (z. B. ist ein Per-Sendung-Bezahl-Programm bestellt worden?) oder eine Berechtigungssituation (z. B. ist der Empfänger berechtigt, bestimmte Kanäle zu verarbeiten, wie etwa Premium- Kanäle?) umfassen.
Der Zustand kann eine Benutzersituation des Empfängers anzeigen. Die Benutzersituation kann Benutzerpräferenzen (z. B. beliebte Kanäle oder Arten von Programmen), ein Benutzerpasswort oder eine Benutzeridentifizierung (z. B. einen Code oder einen Namen, welcher den speziellen Benutzer identifiziert) umfassen.
Der Zustand kann mindestens eines von Zeit, Datum und Tag anzeigen. Zum Beispiel kann der Zugriff auf das Programmieren auf gewisse Stunden am Tag beschränkt sein, z. B. 8 Uhr morgens bis 8 Uhr abends für Kinder.
Der Zustand kann mindestens zum Teil durch die Software-Anwendung definiert werden.
Der Zustand kann anzeigen, dass ein Kanal oder eine Gruppe von Kanälen von dem Empfänger eingestellt wird.
Die Software-Anwendung kann über ein Breitband-Fernsehleitungsnetz, wie etwa ein Kabel- oder Satelliten-Fernsehleitungsnetz, auf den Empfänger herunterladbar sein.
Das Verfahren kann den weiteren Schritt des Bereitstellens einer Benutzerschnittstelle umfassen, um einem Benutzer zu ermöglichen, die Erlaubnis der Sicherheitsrichtlinie zu definieren.
Die Software-Anwendung kann einen Java-Code umfassen, obwohl die Erfindung nicht auf diese Art von Code beschränkt ist.
Der Ausführungsbefehl kann durch einen Benutzer ausgelöst werden, z. B. durch eine korrekte Benutzerschnittstelle.
Die Erlaubnis kann mit einem Benutzer des Empfängers verbunden sein.
Der Zustand kann in dem Code, der die Erlaubnis definiert, verschachtelt sein.
Die Software-Anwendung kann an einen Empfänger-Gerätepark, einschließlich des Empfängers, sammelgesendet werden, z. B. über einen Kabel- oder Satellitenweg.
Es kann eine Benutzerschnittstelle bereitgestellt werden, um einem Benutzer zu ermöglichen, die Daten, die den Zustand definieren, zu definieren.
Es wird auch ein entsprechendes Empfängergerät geboten.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 stellt ein Verteilnetz für digitales Fernsehen gemäß der vorliegenden Erfindung dar.
2 stellt einen Empfänger gemäß der vorliegenden Erfindung dar.
3 stellt ein Zugriffssteuerungsverfahren gemäß der vorliegenden Erfindung dar.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
Die vorliegende Erfindung stellt ein System zum Steuern des Zugriffs auf die DTV-Empfängerfunktionalität, Ressourcen und Benutzerdaten von heruntergeladenen Anwendungen in einem Empfänger für digitales Fernsehen bereit.
1 stellt ein Verteilnetz für digitales Fernsehen gemäß der vorliegenden Erfindung dar. Eine Kopfstelle 100 des Netzes umfasst eine Sicherheitsrichtliniendatenfunktion 110, eine Funktion 115 für die Programmierdienste und eine Funktion 120 für die Software-Anwendung. Es können Daten von jeder der Funktionen 110, 115 und 120 bei einem Multiplexer 125 multiplexiert und zu einem Gerätepark an Teilehmer-Decodierern (z. B. Set-Top-Box) rundgesendet werden. Es sind ein Satellitensendegerät 130, ein Satellit 135 und ein Empfänger (z. B. auch als eine Set-Top-Box, ein Decodierer oder ein Teilnehmerendgerät bekannt) 140 für diesen Zweck bereitgestellt.
Ein Satellitennetz ist jedoch lediglich ein Beispiel für ein Verteilnetz. Es kann jedes bekannte Sendeschema verwendet werden, einschließlich Kabel, terrestrischer Rundfunk und/oder das Internet. Es kann zum Beispiel das Sammelsenden an einen Empfänger-Gerätepark über das Internet verwendet werden.
Die Daten von den Funktionen 110, 115 und 120 müssen nicht multiplexiert werden, können jedoch über separate Kommunikationswege bereitgestellt werden. Zum Beispiel können die Sicherheitsrichtliniendaten und die Software-Anwendung manuell an dem Empfänger 160 geladen werden, z. B. unter der Verwendung einer Mikroprozessor-Chipkarte, oder können über eine Telefonverbindung an den Empfänger 160 gesendet werden. Die Sicherheitsrichtliniendaten und/oder die Software-Anwendung können auch zu der Zeit der Herstellung in dem Empfänger installiert werden.
Bei unerwarteten Implementierungen müssen sich die Sicherheitsrichtliniendaten nicht oft ändern, wobei in diesem Fall die Fähigkeit, die Sicherheitsrichtliniendaten auf den Empfänger herunterzuladen, nicht so wichtig ist. Es wird erwartet, dass sich die Daten der Software-Anwendung öfter ändern und folglich wird angenommen, dass die Fähigkeit zum Fernherunterladen neuer Software auf den Empfänger wichtig ist.
Es wird ein Kabelnetz 145, z. B. mit einer Zentralstation 150, verwendet, um dem Empfänger 160 die gesendeten Daten bereitzustellen.
Es kann ein Kommunikationspfad in Senderichtung bereitgestellt werden, um dem Empfänger 160 zu ermöglichen, mit der Kopfstelle 100 zu kommunizieren. Dies kann zum Beispiel durch einen Pfad in Senderichtung in einem Kabelnetz oder über eine Telefonverbindung erzielt werden.
Die Software-Anwendungen, wie etwa Applets oder eine neue Art von Applet, die als ein Xlet (tm) (Sun Microsystems) bekannt ist, von der Funktion 120 für die Software-Anwendung werden zu jedem der Empfänger in dem Teilnehmernetz rundgesendet. Die Anwendungen können heruntergeladen und bei den Empfängern für nachfolgende Ausführung unter der Verwendung bekannter Techniken gespeichert werden. Es sollte beachtet werden, dass, obwohl auf Anwendungscodes, die einem Applet ähnlich sind, Bezug genommen wird, die Erfindung für die Verwendung mit anderen Arten von Codes angepasst werden kann.
Die Sicherheitsrichtliniendaten können allen Empfängern bereitgestellt werden oder auf bestimmte Empfänger gerichtet werden, z. B. gemäß bekannten adressierbaren Empfängertechniken. Die Sicherheitsrichtliniendaten ermöglichen, dass die herunterladbaren Anwendungen der Funktion 120 für die Software-Anwendung auf gewisse Empfängerfunktionalität, Ressourcen und/oder Benutzerdaten zugreift. Dieser Zugriff wird in Form von Erlaubnissen gestattet, wie unten erörtert wird.
Zum Beispiel stellt die Funktion 115 für die Programmierdienste herkömmliche Fernsehprogramme bereit, obwohl andere Dienste, wie etwa Programme für den Einkauf von zu Hause aus, bildungserzieherischer Zugriff, interaktive Spielsendungen, Umfrageverfahren und dergleichen, ebenfalls bereitgestellt werden können.
Der Empfänger ist als eine Empfängerfunktion 161, eine Zentraleinheit (CPU) 162, einen Speicher 164, eine Benutzerschnittstelle 166 und einen Sicherheitsprozessor 168 aufweisend gezeigt. Der Sicherheitsprozessor 168 ist als ein klares Element gezeigt, obwohl anerkannt werden sollte, dass die vorgeschlagene Sicherheitsarchitektur ohne eine spezielle Sicherheits-Hardware implementiert werden kann, z. B. wie bei gegenwärtigen Personalcomputers, die die vorhandene Java-Sicherheitsarchitektur ohne einen zugeordneten Sicherheitsprozessor implementieren. Der Sicherheitsprozessor 168 kann als ein Funktionsblock angesehen werden. Der Empfänger 160 kann unter der Verwendung jeglicher bekannter Hardware, Firmware und/oder Software implementiert werden. Darüber hinaus können sich die unterschiedlichen Funktionen, die hier und in 2 erörtert werden, einen gemeinsamen Schaltkreis teilen.
Zum Beispiel verarbeitet der Empfänger 160 die empfangenen Daten, um Signale für die Anzeige 170 (z. B. Fernsehbildschirm), die Tonfunktion 180 (z. B. Lautsprecher) und/oder einen Personalcomputer (PC) 190 bereitzustellen. Es können auch andere Ausgabeeinheiten bereitgestellt sein.
Der Sicherheitsprozessor 168, welcher in Hardware oder Software implementiert werden kann, empfängt und verarbeitet die Sicherheitsrichtliniendaten von der Sicherheitsrichtliniendatenfunktion 110.
Die Benutzerschnittstelle 166 ermöglicht es, dass ein Benutzer unter der Verwendung einer herkömmlichen Schnittstellenvorrichtung, wie etwa einer tragbaren Fernsteuerung, Befehle eingibt, z. B. um die Programmierdienste von der Funktion 115 und die Anwendungen von der Funktion 120 anzusehen. Es kann eine geeignete grafische Benutzerschnittstelle (GUI) für diesen Zweck bereitgestellt sein. Der Benutzer kann auch Parameter (z. B. die Sicherheitsrichtliniendaten) des Sicherheitsprozessors 168 definieren oder modifizieren, erneut vorzugsweise durch eine geeignete benutzerfreundliche Schnittstelle.
Die Empfängerfunktion 161 bezieht sich auf beliebige von einer Anzahl an Funktionen, die der Empfänger 160 implementieren kann, wie etwa das Anzeigen spezieller Fernsehprogramme oder -kanäle, das Wechseln von Kanälen (d. h. Einstellen), das Zugreifen auf private Benutzerdaten (z. B. Kreditkartennummern, persönliche Präferenzen etc.), das Bestellen von Per-Sendung-Bezahl-Programmen, das Einschalten einer Sperrfähigkeit durch ein Elternteil, das Wählen eines Modems für den Tele-Einkauf und dergleichen. Ein allgemeines Kennzeichen der Empfängerfunktionen ist, dass es wünschenswert ist, diese Funktionen vor unberechtigtem Zugriff zu schützen.
Die Empfängerfunktion 161 kann in verschiedene Kategorien eingeteilt werden, z. B.: (1) Zugriff oder Verwendung einer Empfängervorrichtung (z. B. Modem, Kanalwähler etc.); (2) Empfängerfunktionalität, wie etwa das Vollziehen eines IPPV-Kaufs, das Überschreiben der Sperre durch ein Elternteil, das Starten und Stoppen einer Anwendung, das Bereitstellen des Zugriffs auf andere Anwendungen etc.; und (3) Lesen und/oder Schreiben des Zugriffs auf Benutzerdaten, wie etwa Benutzerpräferenzen (bevorzugte Sprache, Liste der beliebten Kanäle), Benutzerstatistiken (Kanäle, welche am häufigsten geschaut werden), private Benutzerdaten (wirklicher Name des Benutzers, Kreditkartennummer, Adressen Telefonnummer, Alter etc.).
2 stellt einen Empfänger gemäß der vorliegenden Erfindung dar. Mit gleichen Zahlen gekennzeichnete Elemente in den Figuren entsprechen einander. Der Sicherheitsprozessor 168 umfasst eine Vielfalt an funktionalen Elementen, die als diskrete Module gezeigt sind. Es sollte jedoch anerkannt werden, dass die Modulfunktionen unter der Verwendung jeglicher bekannter Hardware, Firmware und oder Software implementiert werden können und sich einen gemeinsamen Schaltkreis teilen können. Die gezeigte Einrichtung ist somit diagrammatisch und bei der Schaltkreisebene nicht nötig.
Ein Anwendungscodemodul 210 empfängt den Software-Anwendungscode, z. B. von dem Software-Anwendungsmodul 120 aus 1. Demgemäß kann der Code wie gewünscht durch den Netzbetreiber oder eine andere Entität aktualisiert werden. Es kann ein neuer Anwendungscode heruntergeladen werden, um den vorhandenen Code an dem Codemodul 210 zu ersetzen, zu modifizieren oder zu ergänzen.
Ein Anwendungsausführungsmodul 230 (z. B. virtuelle Java-Maschine – JVM) kann den Anwendungscode unter Zuständen, die unten erörtert werden, ausführen. Als Antwort auf den Anwendungscode versucht das Anwendungsausführungsmodul 230, die Empfängerfunktion 161 aufzurufen, z. B. um jegliche von einer Anzahl an verfügbaren Empfängerfunktionen, einschließlich des Zugriffs auf private Benutzerdaten, zu implementieren. Es sollte beachtet werden, dass lediglich ein Empfängerfunktionsmodul 161 gezeigt ist, um eine beliebige Anzahl an verfügbaren Empfängerfunktionen darzustellen. Darüber hinaus kann das Anwendungsausführungsmodul 230 versuchen, zu einer festgelegten Zeit mehr als eine Funktion aufzurufen.
Die herunterladbare Anwendung kann unter mehreren Bedingungen ausgeführt werden, zum Beispiel: (1) das Protokoll, das sie liefert, signalisiert einen Befehl „auto-start" (z. B. wie durch den ATSC T3/S13-Standard spezifiziert), (2) eine Benutzeraktion startet die Anwendung (z. B. von einer EPG, welche verfügbare Anwendungen auflistet, oder durch das Anklicken eines Piktogramms auf dem TV-Bildschirm, das die Anwendungen aufruft) oder (3) durch das Aktivieren einer Anwendung auf der Basis der Zeit (z. B. kann ein Benutzer eine Schaltuhr stellen, um eine spezielle Anwendung zu einer gewissen Zeit aufzurufen). Der Befehl Autostart, die Benutzeraktion oder eine beliebige andere Aktivität, die die Ausführung der Anwendung verursacht, wird als ein „execution command" betrachtet.
Herkömmliche Techniken zum Kompilieren, Interpretieren und Ausführen des Codes an dem Anwendungsausführungsmodul 230 werden als bekannt erachtet und werden folglich hier nicht im Detail erörtert.
Es wird eine „permission" für jede Empfängerfunktion 161 bei einem Erlaubniscodemodul 220, das ein Zustandscodemodul 225 umfasst, bereitgestellt. Die Empfängerfunktion 161 signalisiert einem Zugriffssteuergerät 240 über die CPU 162, dass eine spezielle Anwendung versucht, eine spezielle Empfängerfunktion aufzurufen. Jede Erlaubnis und/oder Anwendung kann einen damit verbundenen Namen, Index oder eine andere Identifizierung aufweisen, die z. B. durch die Kopfstelle 100 bereitgestellt wird und von ihr aktualisiert werden kann.
Das Zugriffssteuergerät kann unter der Verwendung eines „AccessController" implementiert werden, das gegenwärtig in Java eingebaut ist.
Das Zugriffssteuergerät wird somit indirekt durch die ausführende Anwendung ausgelöst. Wenn die Anwendung versucht, eine Empfängerfunktion aufzurufen, die durch eine Sicherheitsrichtlinie geschützt ist, löst die Empfängerimplementierung dieser Funktion die Prüfung nach dem Vorhandensein der Erlaubnis sowie des Zustands aus, indem das Zugriffssteuergerät 240 abgerufen wird.
Als Antwort auf das Signal von der Empfängerfunktion 161 erhält das Zugriffssteuergerät 240 die entsprechende Erlaubnis von dem Erlaubniscodemodul 220 und den entsprechenden Zustand von dem Zustandscodemodul 225.
Das Zugriffssteuergerät 240 kann ein Modul sein, das in eine virtuelle Java-Maschine eingebaut ist.
Die Empfängerfunktion 161 kann über das Anwendungsausführungsmodul 230 mit dem Zugriffssteuergerät 240 und dem Erlaubniscodemodul 220 kommunizieren.
Das Zugriffssteuergerät 240 bestimmt, welches das abrufende Programm der Empfängerfunktion ist (z. B. durch das Identifizieren des Anwendungscodes in 210) und prüft, um zu bestimmen, ob das abrufende Programm die geeignete Erlaubnis aufweist, um die Empfängerfunktion 161 aufzurufen, indem das Sicherheitsrichtlinienmodul 250 durchsucht wird. Falls das abrufende Programm die erforderliche Erlaubnis nicht aufweist, schlägt der Abruf fehl und die ursprüngliche Anforderung wird verwehrt.
Somit werden sowohl das Vorhandensein der Erlaubnis als auch die Zustände durch das Zugriffssteuergerät 240 untersucht. Der Zustand ist physikalisch ein Teil der Erlaubnis, ist konzeptionell jedoch als ein separates Modul 225 gezeigt. Der Zustandscode wird im Allgemeinen nicht von dem Netz geliefert. Der Erlaubniscode, welcher den Zustand umfasst, ist physikalisch auf dem Empfänger 160. Der Name der Erlaubnis und eine Verbindung zu einer speziellen Anwendung werden von dem Netz an den Empfänger geliefert oder lokal bereitgestellt und in dem Sicherheitsrichtlinienmodul 250 gespeichert. Der tatsächliche Code (z. B. Java-Code), der die Erlaubnis und den Zustand darstellt, ist in der Implementierung des Empfängers vorhanden.
Das Sicherheitsrichtlinienmodul 250 listen (z. B. enthält) die Namen der damit verbundenen Erlaubnisse (z. B. als eine Zeichenkette) auf. Die Implementierung der Empfängerfunktion 161 erstellt das physikalische Erlaubnisobjekt (z. B. den realen Java-Code in dem Erlaubniscodemodul 220), das erforderlich ist, um auf diese Funktion zuzugreifen, und gibt die Erlaubnis an das AccessController 240 ab. Das AccessController 240 wiederum bestimmt, welches das abrufende Programm (z. B. das Anwendungscodemodul 210) ist und den Namen der Erlaubnis, und vergleicht dies mit der Sicherheitsrichtlinie 250, die die Paare der Anwendungserlaubnisnamen auflistet.
Gemäß der vorliegenden Erfindung wird, selbst wenn das abrufende Programm die erforderliche Erlaubnis aufweist, eine weitere Prüfung gemacht, um zu bestimmen, ob ein „condition" des Empfängers 160 befriedigt wird. Dies wird an dem Zugriffssteuergerät 240 bestimmt, indem das gegenwärtige Umfeld des Empfängers 160 analysiert wird. Die Implementierung, die den Zustand prüft, ist in dem Erlaubniscode selbst enthalten (z. B. das Verfahren checkCondition ()), um die Implementierung des AccessControllers von den Erlaubnissen und Zuständen unabhängig zu machen. Dies wird es dem AccessController ermöglichen, Erlaubnisse und Zustände, die in der Zukunft definiert werden, zu unterstützen, ohne einen Wechsel in der Implementierung des AccessControllers zu erfordern.
Daten, die das gegenwärtige Umfeld des Empfängers anzeigen, wie etwa die Zeit des Tages oder das Datum, den Sperrstatus durch ein Elternteil, den Per-Sendung-Bezahl-Status, den gegenwärtigen Zuschauer, die gegenwärtige ausgewählte Kanalnummer, die gegenwärtige Berechtigungssituation des Empfängers, den Ausfallstatus, Klassifizierungsgrenze aktiv und so weiter können dem Zugriffssteuergerät durch die CPU 162 bereitgestellt werden. Das gegenwärtige Umfeld kann irgendetwas sein, das für den Empfänger 160 relevant ist und ändert sich möglicherweise mit der Zeit.
Die Zustände können in vier allgemeine Kategorien eingeteilt werden: (1) alle Zustände, die die CA-Situationen (bedingte Zugriffssituationen) betreffen, wie etwa die Berechtigungssituation, die Ausfallsituation, die IPPV-Situation etc.; (2) Zustände, die den Benutzer betreffen, wie etwa Benutzerpräferenzen (z. B. die Klassifizierungsobergrenze, die Fähigkeit, IPPV zu kaufen oder jedwede Fähigkeiten, die den elektronischen Handel betreffen), die Personen-Kennzeichennummer/das Passwort des Benutzers etc.; (3) Zustände, die die Zeit betreffen (z. B. Kinder können lediglich zwischen 8 Uhr morgens und 8 Uhr abends fernsehen, das Modem kann lediglich nach Mitternacht verwendet werden etc.); und (4) Zustände, die den Ursprung der Anwendung betreffen (z. B. eine Anwendung weist unterschiedliche Fähigkeiten auf dem Kanal, von dem sie kam, als auf anderen Kanälen auf).
Mit Bezug auf Punkt (4) ermöglicht ein bestimmtes Erlaubnis- /Zustandsverhältnis, das als besonders nützlich angesehen wird, dass eine Anwendung auf einem Kanal, mit dem sie verbunden ist (oder einer Gruppe von Kanälen, die durch die Hauptkanalnummer definiert werden, oder einem Bouquet) ablaufen gelassen wird, jedoch nicht auf anderen Kanälen. Die Erfindung ermöglicht es, dass eine ABC-Anwendung (z. B. ein animiertes ABC-Logo) zum Beispiel auf allen ABC-Kanälen ablaufen gelassen wird, schützt jedoch NBC (oder eine beliebige andere Rundfunkanstalt) davor, dass eine derartige Anwendung auf ihren Kanälen erscheint.
Die CPU 162 kann die gegenwärtigen Umfeldsdaten von dem Speicher 162 oder einem anderen geeigneten Standort erhalten. Die Bereitstellung und die Kommunikation derartiger gegenwärtiger Umfeldsdaten an das Zugriffssteuergerät 240 kann unter der Verwendung herkömmlicher Kommunikationstechniken realisiert werden und wird folglich nicht detaillierter erörtert.
Falls das Zugriffssteuergerät 240 bestimmt, dass der Zustand, welcher durch den Zustandscode 225 definiert wurde, durch die gegenwärtigen Umfeldsdaten befriedigt wird, wird die angeforderte Empfängerfunktion ermöglicht. Das Zugriffssteuergerät 240 kann ein entsprechendes Signal an die Empfängerfunktion 161 senden, z. B. über die CPU 162, um möglich zu machen, dass die Empfängerfunktion weiterläuft. Falls das Zugriffssteuergerät 240 bestimmt, dass der Zustand nicht befriedigt wird, schlägt der Abruf fehl und die ursprüngliche Anforderung, die Empfängerfunktion aufzurufen, wird verwehrt.
Das Zugriffssteuergerät 240 kann ein entsprechendes Signal an die Empfängerfunktion 161 senden, um zu verhindern, dass sie die angeforderte Aktion ausübt. Der Zustand kann in der Tat eine Anzahl an separaten Zuständen umfassen.

Das Zugriffssteuergerät 240 kann unter der Verwendung einer Verweistabelle wie folgt implementiert werden:

Anwendung	Erlaubnis	Zustand
A	Modem verwenden	nur wenn es der Benutzer erlaubt
A	Kanäle einstellen	nur innerhalb eines Hauptkanals #
B	Zugriff auf Kreditkarte #	nur wenn Benutzer = ein Elternteil
B	IPPV-Filme bestellen	nur wenn Benutzer = ein Elternteil
C	fernsehen zwischen 8 Uhr morgens – 8 Uhr abends	Benutzer = ein Kind und die Zeit liegt zwischen 8 Uhr morgens und 8 Uhr abends

Zum Beispiel kann Anwendung „A" eine interaktive Werbung sein, die einen Dauerwerbesendungskanal einstellen und ein Bestellformular für einen Katalog verarbeiten kann, Anwendung „B" kann eine Anwendung für den elektronischen Handel sein und Anwendung „C" kann eine Navigations-Anwendung für Kinder sein, wie etwa eine Anwendung der Art elektronische Programmzeitschrift (EPG), welche nur Kinderprogramme zeigt.
Das gegenwärtige Umfeld muss zu dem Zustand passen, damit die entsprechende Empfängerfunktion erlaubt wird. Es sollte beachtet werden, dass die Anwendung weiterhin andere Funktionen als die, die nicht erlaubt werden, ohne Probleme aufrufen und weiterhin ausführen kann.
Es ist möglich, ein Signal an den Benutzer zu führen, z. B. über die Anzeige 170, um den Benutzer über den Status einer Anwendung zu informieren, z. B. ob die Anwendung gestattet oder verwehrt wird. Abhängig von der speziellen Implementierung des Empfängers und/oder der Anwendung kann es wünschenswert sein oder nicht, dem Benutzer derartige Nachrichten bereitzustellen.
Darüber hinaus kann der Anwendungscode an dem Anwendungsausführungsmodul 230 ausgeführt werden oder nicht, falls die angeforderte Empfängerfunktion von dem Zugriffssteuergerät 240 nicht gestattet wird. Dies hängt davon ab, welche die aufgerufene Funktion ist. Falls zum Beispiel die angeforderte Empfängerfunktion ist, auf ein Modem, das mit dem Empfänger 160 verbunden ist, zuzugreifen und der Zugriff verwehrt wird, weil die Anwendung nicht die Erlaubnis „modem" aufwies, kann die Anwendung weiterhin ausgeführt werden, sie kann jedoch das Modem nicht verwenden. Falls die angeforderte Funktion die Grundanforderung ist, ausgeführt zu werden und falls sie verwehrt wird, dann beendet die Anwendung das Ausführen.
Es sollte beachtet werden, dass das „caller" der Empfängerfunktion 161 eine Anwendung ist, die z. B. auf den Empfänger heruntergeladen wurde. Der Zweck einer Sicherheitsrichtlinie für derartige Empfänger (z. B. Set-Top-Boxen) ist, eine gewisse Steuerung über Anwendungen bereitzustellen, die, manchmal ohne dem Wissen des Benutzers (z. B. TV-Zuschauer), auf den Empfänger heruntergeladen werden können. Die heruntergeladene Anwendung ruft eine gewisse Funktion des Empfängers ab (wie etwa das Wählen eines Modems, das Einstellen eines neuen Kanals, das Ändern des Werts der Benutzerpräferenzen, das Zugreifen auf Informationen über die Kreditkartennummer etc.).
Die Implementierung dieser Funktion ist typischerweise für jeden Empfänger spezifisch, ständig in dem Empfänger anwesend und wird nicht mit der Anwendung heruntergeladen. Es muss eine Art von Mechanismus verwendet werden, um bestimmen zu können, ob der abrufenden Anwendung erlaubt werden sollte, die angeforderte Funktion zu vollziehen.
Dies wird erzielt, indem die Erlaubnisse, die der abrufenden Anwendung (dem abrufenden Programm) gewährt werden, geprüft werden. Die Erlaubnisse werden üblicherweise in einem Sicherheitsrichtlinienmodul 250 gespeichert. Bei dem Internet-Modell ist dies eine Datei, die auf einem PC gespeichert ist, und ein Benutzer kann die Richtliniendatei modifizieren. Bei der TV-Domäne kann die Richtliniendatei von dem Benutzer (z. B. dem Besitzer des Empfängers), wobei angenommen wird, dass der Empfänger eine geeignete Benutzerschnittstelle aufweist, oder von dem Netzbetreiber in dem Fall eines Kabelnetzes oder eines Satellitennetzes eines einzigen Anbieters oder von Anbietern/Rundfunkanstalten einzelner Inhalte für ihre Kanäle oder von jeglicher Kombination aus dem Obenstehenden festgesetzt werden.
Die Lieferung der Richtlinie an den Empfänger kann jedwede herkömmliche Mittel verwenden.
Die Erlaubnisse werden im Allgemeinen einer herunterladbaren Anwendung gewährt, die entweder signiert ist oder von einer eindeutig definierten Quelle kommt (wie etwa einer URL oder einem bestimmten TV-Kanal etc.). Es ist möglich, dass der Benutzer die Erlaubnisse definiert. Es ist beabsichtigt, dass die Erlaubnisse dem Empfänger Sicherheit bereitstellen, um tückische Anwendungen zu verhindern (wie etwa eine Anwendung, die auf den Empfänger heruntergeladen wird und die ganze Nacht hindurch gebührenpflichtige Nummern wählt, oder eine Anwendung, die verhindert, dass der Zuschauer den Kanal über eine spezielle Gruppe von Kanälen hinaus wechselt oder das Fernsehbild oder den Ton für gewisse Kanäle verschlechtert und so weiter).
Folglich wird die Anwendung, die anfordert, eine Empfängerfunktion aufzurufen, zuerst von dem Zugriffssteuergerät 240 geprüft, um zu bestimmen, ob sie eine derartige Erlaubnis aufweist (z. B. um ein Modem zu verwenden oder um gebührenpflichtige Nummern zu wählen etc. in dem oben erwähnten Beispiel).
Die vorliegende Erfindung erweitert diesen Sicherheitsmechanismus, um nicht nur das Vorhandensein einer derartigen Erlaubnis zu prüfen, sondern um auch die gegenwärtigen Zustände des Empfängers zu prüfen, wie etwa den gegenwärtigen Kanal, den Ausfallstatus, die berechtigte Situation, den gegenwärtigen Zuschauer und so weiter. Die Anwendung kann zum Beispiel eine Erlaubnis aufweisen, um elektronische Handelstransaktionen (E-Commerce-Transaktionen), wobei der Tele-Einkauf umschlossen ist, lediglich dann auszulösen, wenn der gegenwärtige Benutzer eine derartige Erlaubnis aufweist.
Falls zum Beispiel der gegenwärtige Benutzer ein Elternteil ist, dann kann die Anwendung für den elektronischen Handel fortfahren. Falls der gegenwärtige Benutzer ein Kind ist, dann kann die Anwendung für den elektronischen Handel nicht fortfahren.
Die Erlaubnisse können auch mit einem Benutzer verbunden sein, wie etwa in dem oben erwähnten Fall, wo einige Benutzer den elektronischen Handel, IPPV etc. vollziehen können und andere nicht. Die Anwendungen können somit im Namen gewisser Benutzer laufen gelassen werden. Der gegenwärtige Zuschauer kann bestimmt werden, indem der Zuschauer eine Personen-Kennzeichennummer (PIN) oder ein anderes Passwort eingeben muss wenn der Benutzer z. B. zum ersten Mal den Fernsehapparat anschaltet. Der Empfänger kann dann eine Entscheidung treffen, einer gewissen Anwendung nicht nur auf der Basis einer Erlaubnis, die der Anwendung selbst gewährt wurde, sondern auch auf der Basis von Erlaubnissen die dem gegenwärtigen Benutzer gewährt wurden, zu erlauben, eine gewisse Tätigkeit zu vollziehen.
Der Zustand einer Erlaubnis, die mit einem Benutzer verbunden wird, kann sein, dass der gegenwärtige Benutzer die Erlaubnis aufweisen muss (wie auch die Anwendung die Erlaubnis aufweisen muss). Es kann zum Beispiel eine Anwendung in Betracht gezogen werden, die eine Erlaubnis aufweist, Filme in Begleitung von personensorgeberechtigten Erwachsenen anzuschauen. Des Weiteren kann angenommen werden, dass es zwei Benutzer des TV-Empfängers gibt: einer davon weist eine Erlaubnis auf, lediglich Filme ohne Altersbeschränkung anzuschauen; der andere weist eine Erlaubnis auf, Filme ohne Altersbeschränkung und Filme in Begleitung personensorgeberechtigter Erwachsener anzuschauen.
Wenn die Anwendung ausgeführt wird, wird ihre Erlaubnis geprüft und sie wird genehmigt (da die Anwendung eine Erlaubnis für die Begleitung personensorgeberechtigter Erwachsener aufweist). Der Code, der den Zustand prüft, muss jedoch bestimmen, wer der gegenwärtige Benutzer ist und bestimmt seine/ihre Erlaubnis. Der Benutzer muss die geeignete Erlaubnis aufweisen, das Programm zu schauen.
Die Verbindung einer Erlaubnis mit einem Benutzer kann auf verschiedene Weisen erzielt werden, z. B.: (1) das Access Controller bestimmt, wer der gegenwärtige Benutzer ist und prüft sowohl seine Erlaubnisse als auch die Anwendungserlaubnisse (sie müssen beide eine Erlaubnis aufweisen, um fortzufahren) oder (2) der Benutzer wird als ein Zustand der Erlaubnis bestimmt – in diesem Fall bestimmt das Zugriffssteuergerät, als Teil des Prüfens des Zustands, wer der gegenwärtige Benutzer ist und ob der Benutzer eine gegebene Erlaubnis aufweist (nicht notwendigerweise dieselbe, die die Anwendung aufweist – z. B. kann die Anwendung eine Erlaubnis aufweisen, ein Modem zu verwenden, während der Benutzer eine Erlaubnis brauchen kann, um elektronische Handelstransaktionen zu vollziehen und folglich das Modem zu verwenden).
Wie erwähnt wurde, können Erlaubnisse sowohl mit herunterladbaren Anwendungen als auch mit bestimmten Benutzern verbunden sein. Es kann lediglich eine Richtlinie auf dem Empfänger sein, die mehrere Benutzer des Empfängers erkennt.
Darüber hinaus kann der Zustand mit der Erlaubnis verbunden sein und von dem Access Controller geprüft werden, um dem Zustand Sicherheit bereitzustellen. Die Tatsache, dass der Zustand in dem Erlaubniscode verschachtelt ist und gleichzeitig von dem Access Controller geprüft wird, macht ihn sicherer (nicht nur die Tatsache, dass diese beiden auf eine Art und Weise verbunden sind).
Des Weiteren kann ein Benutzer mit einer geeigneten Schnittstelle den Zustand des Empfängers definieren, bei dem der Zugriff auf die Empfängerfunktion durch die Software-Anwendung erlaubt wird. Ein Benutzer könnte zum Beispiel einen Zeitrahmen für Kinder zum Fernsehen definieren (z. B. zwischen 8 Uhr morgens und 8 Uhr abends). Der Zustand könnte erfordern, dass die momentane Zeit zwischen dem Beginn und dem Ende des Zeitfensters, das Kindern erlaubt wird, liegt. Dieses Fenster kann durch den Benutzer über eine Benutzerpräferenzenfunktion auf eine Art und Weise, die dem Fachmann bekannt ist, definiert werden.
Der Benutzer kann nicht wissen, dass er Erlaubnisse oder Zustände für die Sicherheitsrichtlinie festsetzt – er setzt nur seine Benutzerpräferenzen fest, die verwendet werden, um die Zuständen zu evaluieren.
Mit Bezug auf die Art der Anwendungen, die auf dem Empfänger ablaufen gelassen werden, kann der Empfänger Applets ablaufen lassen, falls er internetfähig ist, und kann Applets aus dem Internet herunterladen oder bekommt sie in dem Rundfunkstrom geliefert, allerdings ist die gegenwärtige Richtung, in die sich einige Normungsorganisationen (wie etwa ATSC, DVB) und Sun bewegen zu der Verwendung des zuvor erwähnten Xlets hin, das einem Applet ähnlich ist, jedoch für die Rundfunk-/TV-Domäne gedacht ist.
Die vorliegende Erfindung ist für Anwendungen, die durch Applets und Xlets definiert werden, geeignet, ist jedoch nicht darauf beschränkt.
Während das Netz, das mit dem Empfänger 160 verbunden ist, ein Satelliten-, Kabel- oder ein terrestrisches Netz sein kann, ist darüber hinaus die Erfindung auch für die Verwendung mit Anwendungen geeignet, die über das traditionelle Internet oder jegliche andere Mittel geliefert werden. Die Sicherheitsrichtlinie selbst ist auf dem Empfänger 160 anwesend, kann jedoch von unterschiedlichen Quellen, wie etwa von dem PC 190, geliefert oder aktualisiert oder erweitert werden, oder sie kann zu der Zeit der Herstellung in dem Empfänger vorinstalliert werden. Darüber hinaus kann der Benutzer z. B. über die Benutzerschnittstelle 166 die Richtlinie festsetzen oder modifizieren.
3 stellt ein Zugriffssteuerungsverfahren gemäß der vorliegenden Erfindung dar. An dem Block 310 wird die Software-Anwendung an den Empfänger geliefert (typischerweise an einen Empfänger-Gerätepark). An dem Block 320 werden die Anwendungserlaubnisse an den Empfänger geliefert. Es sollte beachtet werden, dass die Reihenfolge der Lieferung der Anwendung und der Anwendungserlaubnis nicht wichtig ist, obwohl die Erlaubnisse geliefert werden müssen, bevor die Anwendung ausgeführt werden kann.
An dem Block 330 fordert die Anwendung das Aufrufen einer Empfängerfunktion an, die durch eine Sicherheitsrichtlinie geschützt wird. An dem Block 340 erzeugt die Implementierung der Empfängerfunktion, die aufgerufen wird, die erforderliche Erlaubnis, die fest in dem Implementierungscode eingebaut sein kann. An dem Block 345 wird die Erlaubnis an das Zugriffssteuergerät geführt. An dem Block 350 identifiziert das Zugriffssteuergerät das ursprüngliche abrufende Programm (z. B. die Anwendung). An dem Block 360 bestimmt das Zugriffssteuergerät, ob das abrufende Programm die geeignete Erlaubnis aufweist (wie an dem Block 345 weitergeführt). Falls das abrufende Programm die Erlaubnis (Block 370) nicht aufweist, schlägt der Abruf fehl und die ursprüngliche Anforderung, die Empfängerfunktion aufzurufen, wird verwehrt.
Falls das abrufende Programm die Erlaubnis (Block 380) aufweist, wird der Zustand von dem Zugriffssteuergerät geprüft. Falls der Zustand nicht befriedigt wird (Block 370), schlägt der Abruf fehl und die ursprüngliche Anforderung wird verwehrt. Falls der Zustand befriedigt wird (Block 390), wird die angeforderte Empfängerfunktion erlaubt.
Vorteilhafterweise verwendet die vorliegende Erfindung einen dynamischen Ansatz, um den Software-Anwendungen Zugriffssteuerung bereitzustellen. Im Gegensatz dazu sind traditionelle Zugriffssteuerungsmechanismen statisch. Bei traditionellen Lösungen wird erfordert, dass der Benutzer einen Schlüssel (Stufe) besitzt, um auf einen gewissen Kanal (z. B. ein Programm) zuzugreifen. Dieser Mechanismus kann über eine Personen-Kennzeichennummer (PIN) erweitert werden, z. B. um die Fähigkeit bereitzustellen, interaktive Per-Sendung-Bezahl-Programme (IPPV-Programme) zu kaufen oder um eine Sperrfunktion durch ein Elternteil zu erwirken. Die PIN fügt folglich Zustände zu der ursprünglichen Berechtigung hinzu. Darüber hinaus erfordern diese Erweiterungen Benutzer-Interaktion und werden auf das gesamte Umfeld angewendet, das heißt, dass z. B. der Benutzer die Sperre durch ein Elternteil auf einem beliebigen Kanal überschreiben kann, falls die Sperr-PIN durch ein Elternteil bereitgestellt wird.
Mit Bezug auf Klassifizierungssteuerungsschemata ist der Zweck der Klassifizierungssteuerungsschemata des Stands der Technik, im Gegensatz zu der vorliegenden Erfindung, bei der sowohl der Endbenutzer als auch der Inhaltsanbieter geschützt werden, lediglich den Endbenutzer zu schützen. Bei einer derartigen Klassifizierungssteuerung ist der Endbenutzer dafür verantwortlich, die Sicherheitsrichtlinie, die angewendet wird, zu definieren (z. B. Festsetzen der Zustände, der Klassifizierungsobergrenze und des Passworts). Im Gegensatz dazu ist bei der vorliegenden Erfindung der Diensteanbieter des Netzes dafür verantwortlich, die Richtlinie zu definieren, um die Anbieter unterschiedlicher Inhalte, die in dem Netz sind, zu schützen. Das Klassifizierungssteuerungsschema des Stands der Technik ist nicht dynamisch in dem Sinne, dass der Kanal entweder immer gesperrt (der Benutzer weist das Passwort nicht auf) oder immer zugänglich (der Benutzer weist das Passwort auf) ist.
Bei der vorliegenden Erfindung wird dieselbe Anwendung auf gewissen Kanälen ablaufen gelassen, wird jedoch auf anderen nicht ablaufen gelassen, z. B. wenn der Benutzer einen anderen Kanal einstellt besteht die Anwendung manchmal fort und manchmal wird sie beendet, abhängig von der Definition der Richtlinie. Bei dem Klassifizierungsmechanismus des Stands der Technik bedeutet das Wechseln von Kanälen in der Tat das Umschalten von Anwendungen (bei Betrachtung eines Videokanals als eine Anwendung). Die vorliegende Erfindung kann mehrere gleichzeitige Anwendungen unterbringen (z. B. eine Daten-Anwendung, die zusätzlich zu einem Videokanal ablaufen gelassen wird), wobei das Wechseln von Kanälen, basierend auf der Sicherheitsrichtlinie und der gegenwärtigen Situation des Empfängers, manchmal dieselbe Daten-Anwendung beibehält und manchmal nicht.
Ein weiteres Beispiel eines vorhandenen statischen Mechanismus ist der Kreisgegend-Ausfall, der auf dem Standort der Set-Top-Box basiert, welcher durch die Postleitzahl (ZIP-Code) definiert wird. Unter der Verwendung eines Kreisgegend-Ausfall-Schemas wird für einen Benutzer (z. B. einen Fernsehzuschauer) jedweder Kanal, welcher den lokalen ZIP-Code in der Ausfallliste umfasst, verdunkelt. Die vorliegende Erfindung beseitigt die inhärenten Beschränkungen vorheriger Kreisgegend-Ausfall-Schemata, indem der Sicherheitsrichtlinienmechanismus von der Benutzer-Interaktion unabhängig gemacht wird. Insbesondere unterstützt die vorliegende Erfindung mehrere gleichlaufende Anwendungen und verwendet den gegenwärtigen Zustand (z. B. die gegenwärtige Kanalnummer) der Set-Top-Box, welcher sich zu jeder Zeit ändern kann, um das Resultat der Sicherheitsrichtlinienerlaubnisprüfung (z. B. ob es dem Benutzer erlaubt sein sollte, auf eine Anwendung zuzugreifen) zu bestimmen.
Die oben beschriebenen Beispiele sind ganz speziell auf ein ATSC-, DVB- und DAVIC-DTV-Umfeld unter der Verwendung von Java als die virtuelle Maschine für die Implementierung abgezielt. Die Erfindung kann jedoch auch auf Implementierungen, die nicht auf Java basieren, sowie auf beliebige andere Nicht-DTV-Vorrichtungen, die für herunterladbare Software-Anwendungen eine flexible Sicherheitsrichtlinie implementieren müssen, angewendet werden. Darüber hinaus können die hier beschriebenen Algorithmen auf jedwede dynamische Evaluierung des Software-Zugriffs auf sichere Ressourcen auf der Basis statischer Erlaubniszuweisungen angewendet werden, um die Quellen und den gegenwärtigen (zu der Zeit des Machens der Zugriffsanforderung) Zustand der Vorrichtung zu codieren.
Ein Schema zum Entscheiden der Zugriffsrechte gemäß der vorliegenden Erfindung evaluiert die gegenwärtigen Zustände (z. B. das Umfeld) des DTV-Empfängers, wie etwa den Kanal, der eingestellt ist, bevor die Erlaubnis gewährt wird. Die Sicherheitsdomäne kann weiterhin bei der Ladezeit der Klasse definiert werden, jedoch basieren die Erlaubnisse (oder eine Teilmenge der Erlaubnisse), die dieser Domäne gewährt wurden, bedingt auf der unmittelbaren Situation der Vorrichtung.
„Class Loading" ist ein Java-Begriff für den Prozess des Bereitstellens von Java-Klassendateien von einem Netz (z. B. dem Internet) oder wo auch immer die Klassendateien gespeichert sind (z. B. Kopfstelle) an den Speicher eines Computers oder insbesondere an einen Empfänger, der fähig ist, Java-Anwendungen ablaufen zu lassen, so dass die Klassendateien ausgeführt werden können.
Ein Beispiel könnte eine Erlaubnis sein, die einer Anwendung ermöglicht, über eine Kanaländerung hinaus fortzudauern, wobei der Zustand ist, dass die Kanaländerungen lediglich innerhalb des virtuellen Hauptkanals der Quelle der Anwendung sind. Das Konzept von virtuellen Haupt- und Nebenkanälen ist in ATSC Program and System Information Protocol, (PSIP), A65, im Detail beschrieben. Ein virtueller Hauptkanal ist typischerweise mit einem speziellen nationalen Netz (z. B. ABC) verbunden, während der virtuelle Nebenkanal zum Beispiel lokale Tochtergesellschaften sein kann. Es kann ein Kanalnummerierungsschema eingesetzt werden, das die Zugehörigkeit anzeigt, um dabei zu helfen, ein Wohlwollen der Konsumenten gegenüber einer bestimmten „Familie" an virtuellen Haupt- und Nebenkanälen aufzubauen.
Als ein weiteres Beispiel kann angenommen werden, dass das ABC-Fernsehleitungsnetz eine virtuelle Hauptkanalnummer 10 und drei virtuelle Nebenkanalnummern .1,.2 und .3 aufweist. Die Kanäle 10.1 und 10.2 können zum Beispiel Ton-/Video-TV-Kanäle sein und der Kanal 10.3 kann einen Nachrichtenticker übertragen. Der Nachrichtenticker kann gemäß Java oder einer anderen Sprache bereitgestellt werden. Falls gewünscht, kann der Zuschauer den Nachrichtenticker aufrufen (z. B. auswählen), welcher kontinuierlich entlang einem Abschnitt des Bildschirms rollt, selbst wenn der Zuschauer zwischen den Kanälen 10.1 und 10.2 umschaltet.
Das Sicherheitsrichtlinienschema der vorliegenden Erfindung kann verwendet werden, um die Ausführung der Nachrichtenticker-Anwendung automatisch zu beenden, wann immer der Zuschauer etwas anderes als die Hauptkanalnummer 10 einstellt, und um die Anwendung wiederherzustellen, wenn der Zuschauer wieder die Hauptkanalnummer 10 einstellt.
Bei einer Ausführungsform erweitert die vorliegende Erfindung einen herkömmlichen Erlaubnisevaluierungsalgorithmus, wie etwa den JDK (Java Development Kit, erhältlich von Sun Microsystems JavaSoft Division) 1.2 Basisalgorithmus. Dieser Algorithmus wird zum Prüfen der Erlaubnisse verwendet, um zu bestimmen, ob der Zugriff durch eine Anwendung gewährt oder verwehrt wird, berücksichtigt jedoch keine Empfängerzustände, wie hier erklärt wurde.
Zwei beispielhafte Ausführungsformen des erweiterten Algorithmus gemäß der vorliegenden Ausführung sind unten gezeigt. Die Ausführungsformen sind unter der Verwendung eines Pseudocodes, welcher Java ähnlich ist, veranschaulicht. Schema 1 – Basisalgorithmus zum Prüfen der Erlaubnis unter der Verwendung bedingter Erlaubnisse:
Der oben erwähnte Pseudocode „else if (current environment does not satisfy the permission's conditions) throw AccessControlException" wird gemäß der vorliegenden Erfindung hinzugefügt. „Throw" ist eine Java-Steuerungsanweisung, die sich mit dem Umgang von Ausnahmen beschäftigt, wie etwa dem Versuch, durch null zu teilen oder dem Versuch, auf unberechtigte Informationen zuzugreifen.
Wie zuvor im Detail erörtert wurde, kann die „current environment" Faktoren anzeigen, wie etwa den Kanal, welcher gegenwärtig ausgewählt ist, die Identität des gegenwärtigen TV-Benutzers, die gegenwärtige Berechtigungssituation des Empfängers, die momentane Zeit etc.
Der komplette Algorithmus, welcher von dem Verfahren JDK 1.2 AccessController checkPermission benutzt wird, verwendet auch die Konzepte „context" und „inherited context". Diese Konzepte sind in Java Security Architecture, Li Gong, 2. Oktober, 1998, DRAFT DOCUMENT (Revision 1.0) definiert.
Im Allgemeinen umfasst ein Java-Programm ein oder mehrere Pakete, wobei jedes davon Klassendefinitionen enthält. Eine Klassendefinition ist ein Muster zum Produzieren von Objektinstanzen. In einer gewöhnlichen Klasse weist jede Objektinstanz dieselben Situationsvariablen und -verfahren auf. Jede Klasse basiert auf einer anderen Klasse (Superklasse). Eine Subklasse erbt die Verfahren ihrer Superklasse basierend auf den Eigenschaften der Vererbung. Die Reihe aller Klassen bildet einen Baum, wo ein „Object" an der Spitze steht.
Darüber hinaus können Java-Programme mehrere Steuerungs- Threads aufweisen. Um Wettlaufzustände zu vermeiden, kann die Steuerungsanweisung „synchronized" verwendet werden, um einen Codeblock oder eine Prozedur abzugrenzen, der/die zu einer festgelegten Zeit nicht mehr als einen aktiven Thread aufweisen darf.
Es kann zum Beispiel angenommen werden, dass ein gegenwärtiger Thread m abrufende Programme (z. B. unterschiedliche Klassen einer Anwendung) in der folgenden Reihenfolge durchlaufen hat: von dem abrufenden Programm 1 zu dem abrufenden Programm 2 zu dem abrufenden Programm m. Dann ruft das abrufende Programm m das Verfahren checkPermission auf. Ein möglicher Algorithmus checkPermission, welcher nützlich ist, um zu bestimmen, ob der Zugriff gewährt oder verwehrt wird, lautet wie folgt: Schema 2 – Erweiterter Algorithmus zum Prüfen der Erlaubnis unter der Verwendung von Kontext und geerbtem Kontext:
Es sollte nun anerkannt werden, dass es die vorliegende Erfindung Diensteanbietern, Herstellern von Konsumelektronik (CE), Endbenutzern oder Normungsorganisationen (wie etwa ATSC – Advanced Television System Committee) ermöglicht, flexible Sicherheitsrichtlinien für die Ausführung von heruntergeladenen Anwendungen auf DTV-Empfängern zu definieren. Die Flexibilität oder selbst das Vorhandensein einiger Arten von Anwendungen wäre ohne einen derartigen Mechanismus unmöglich.
Die vorliegende Erfindung untersucht das gegenwärtige Umfeld, in der eine Software-Anwendung ablaufen gelassen werden soll (wie etwa in einem Empfänger) und bestimmt, ob die Umfeldfaktoren des Empfängers die Zustände befriedigen, um einer Anwendung eine Erlaubnis zu gewähren, den Zugriff auf die Empfängerfunktion, die Empfängerressourcen und/oder die privaten Benutzerdaten zu erlauben.
Die Sicherheitsrichtlinie kann modifiziert werden, indem eine neue Richtliniendatei oder Aktualisierungen für die Richtliniendatei installiert oder heruntergeladen werden oder sogar durch einen Benutzer mit der Bereitstellung einer geeigneten Benutzerschnittfläche.
Obgleich die Erfindung in Verbindung mit verschiedenen bestimmten Ausführungsformen beschrieben worden ist, versteht der Fachmann, dass daran zahlreiche Änderungen und Modifikationen vorgenommen werden können, ohne von dem Bereich der Erfindung, wie in den Patentansprüchen dargelegt, abzuweichen.

Claims

Ein Sicherheitsverfahren zum Steuern des Zugriffs auf eine Funktion eines Empfängers für digitales Fernsehen, das die folgenden Schritte beinhaltet: (a) Bereitstellen einer Software-Anwendung an dem Empfänger; wobei die Software-Anwendung mit einer verbundenen Sicherheitsrichtlinie verbunden ist und als Antwort auf einen Ausführungsbefehl ausführbar ist; (b) Bereitstellen von Zustandsdaten, die einen Zustand des Empfängers definieren, bei dem der Zugriff auf die Empfängerfunktion durch die Software-Anwendung erlaubt wird; (c) Bereitstellen eines Steuersignals zum Anfordern des Zugriffs auf die Empfängerfunktion nach der Ausführung der Software-Anwendung; (d) Bestimmen, als Antwort auf das Steuersignal, ob die verbundene Sicherheitsrichtlinie der Software-Anwendung eine Erlaubnis für die Software-Anwendung, auf die Empfängerfunktion zuzugreifen, enthält; (e) wenn die Sicherheitsrichtlinie die Erlaubnis enthält: (i) Bestimmen, ob der Zustand des Empfängers erfüllt wird, indem Situationsdaten, die eine gegenwärtige Situation des Empfängers anzeigen, evaluiert werden; (ii) Ermöglichen, dass die Software-Anwendung auf die Empfängerfunktion zugreift, wenn der Zustand erfüllt wird; und (iii) Verhindern, dass die Software-Anwendung auf die Empfängerfunktion zugreift, wenn der Zustand nicht erfüllt wird; und (f) Verhindern, dass die Software-Anwendung auf die Empfängerfunktion zugreift, wenn die Sicherheitsrichtlinie die Erlaubnis nicht enthält.
Verfahren gemäß Anspruch 1, wobei: der Zustand eine bedingte Zugriffssituation des Empfängers anzeigt.
Verfahren gemäß Anspruch 2, wobei die bedingte Zugriffssituation mindestens eines von den Folgenden beinhaltet: eine Ausfallsituation; eine Per-Sendung-Bezahl-Situation; und eine Berechtigungssituation.
Verfahren gemäß Anspruch 1, wobei: der Zustand eine Benutzersituation des Empfängers anzeigt.
Verfahren gemäß Anspruch 4, wobei die Benutzersituation mindestens eine Situation von den Folgenden ist: Benutzerpräferenzen; ein Benutzerpasswort; oder eine Benutzeridentifizierung.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei: der Zustand mindestens eines von Zeit, Datum und Tag anzeigt.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei: der Zustand mindestens zum Teil durch die Software-Anwendung definiert wird.
Verfahren gemäß Anspruch 1, wobei: der Zustand anzeigt, dass ein Kanal oder eine Gruppe von Kanälen von dem Empfänger eingestellt wird.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei: die Software-Anwendung über ein Breitband-Fernsehleitungsnetz auf den Empfänger herunterladbar ist.
Verfahren gemäß einem der vorhergehenden Ansprüche, das den folgenden weiteren Schritt beinhaltet: Bereitstellen einer Benutzerschnittstelle, um einem Benutzer zu ermöglichen, mindestens zum Teil die Erlaubnis der Sicherheitsrichtlinie zu definieren.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei: die Software-Anwendung einen Java-Code beinhaltet.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei: der Ausführungsbefehl durch einen Benutzer ausgelöst wird.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei: die Erlaubnis mit einem Benutzer des Empfängers verbunden ist.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei: der Zustand in dem Code, der die Erlaubnis definiert, verschachtelt ist.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei: die Software-Anwendung an einen Empfänger-Gerätepark, einschließlich des Empfängers, sammelgesendet wird.
Verfahren gemäß einem der vorhergehenden Ansprüche, das den folgenden weiteren Schritt beinhaltet: Bereitstellen einer Benutzerschnittstelle, um einem Benutzer zu ermöglichen, mindestens zum Teil die Zustandsdaten, die den Zustand definieren, zu definieren.
Ein Sicherheitsgerät zum Steuern des Zugriffs auf eine Funktion eines Empfängers für digitales Fernsehen, das die folgenden Schritte beinhaltet: (a) ein Mittel zum Bereitstellen einer Software-Anwendung an dem Empfänger; wobei die Software-Anwendung mit einer verbundenen Sicherheitsrichtlinie verbunden ist und als Antwort auf einen Ausführungsbefehl ausführbar ist; (b) ein Mittel zum Bereitstellen von Zustandsdaten, die einen Zustand des Empfängers definieren, bei dem der Zugriff auf die Empfängerfunktion durch die Software-Anwendung erlaubt wird; (c) ein Mittel zum Bereitstellen eines Steuersignals zum Anfordern des Zugriffs auf die Empfängerfunktion nach der Ausführung der Software-Anwendung; (d) ein Mittel zum Bestimmen, als Antwort auf das Steuersignal, ob die verbundene Sicherheitsrichtlinie der Software-Anwendung eine Erlaubnis für die Software-Anwendung, auf die Empfängerfunktion zuzugreifen, enthält; (e) (i) ein Mittel zum Bestimmen, ob der Zustand des Empfängers erfüllt wird, indem Situationsdaten, die eine gegenwärtige Situation des Empfängers anzeigen, evaluiert werden, wenn die Sicherheitsrichtlinie die Erlaubnis enthält; (e) (ii) ein Mittel zum Ermöglichen, dass die Software-Anwendung auf die Empfängerfunktion zugreift, wenn sowohl der Zustand erfüllt wird als auch die Sicherheitsrichtlinie die Erlaubnis enthält; (e) (iii)ein Mittel zum Verhindern, dass die Software-Anwendung auf die Empfängerfunktion zugreift, wenn der Zustand nicht erfüllt wird; und (f) ein Mittel zum Verhindern, dass die Software-Anwendung auf die Empfängerfunktion zugreift, wenn die Sicherheitsrichtlinie die Erlaubnis nicht enthält.