DE60017438T2

DE60017438T2 - System zur betriebsmittelzugriffsteuerung

Info

Publication number: DE60017438T2
Application number: DE60017438T
Authority: DE
Inventors: Meandzija Bransilav; Alexander Medvinsky
Original assignee: Arris Technology Inc; General Instrument Corp
Current assignee: Arris Technology Inc
Priority date: 1999-09-03
Filing date: 2000-09-05
Publication date: 2005-12-22
Anticipated expiration: 2020-09-06
Also published as: WO2001018650A2; EP1222537B1; EP1222537A2; DE60017438D1; ATE287105T1; WO2001018650A3; TW513670B; CA2381017A1; AU7347500A; KR20020035582A; HK1049391A1; CN1372663A

Description

Diese Anmeldung genießt die Priorität der U.S. vorläufigen Patentanmeldung Nummer 60/152,312 mit dem Titel „Resource Access Control System", eingereicht am 3. September 1999, die hier vollständig aufgeführt ist.
ALLGEMEINER STAND DER TECHNIK
Die vorliegende Erfindung bezieht sich im Allgemeinen auf digitale Verarbeitungssysteme und insbesondere auf die Zuordnung von Betriebsmitteln in einem digitalen System.
Um Funktionalität bereitzustellen, ermöglichen digitale Verarbeitungsvorrichtungen, wie zum Beispiel Computersysteme, einem Benutzer der Vorrichtung verschiedene Software-Programme, Objekte etc. auszuführen. Ein Benutzer kann auf einem Computersystem zum Beispiel einen Webbrowser, ein Textverarbeitungssystem und ein E-Mail-Programm laufen lassen. Jede dieser Software-Anwendungen kann von einem anderen Software-Entwickler hergestellt sein und unabhängig bezogen, installiert und betrieben werden. Der Benutzer kann Software wie gewünscht laufen lassen oder vom dem Computer entfernen. Durch diesen Ansatz kann ein sich nicht änderndes Hardware-Teil, d. h. das Computersystem, viele verschiedene Aufgaben durch das Ausführen von Softwareobjekten durchführen. Auf diese Weise kann die Funktionalität des Computersystems wie gewünscht geändert oder aktualisiert werden.
Problematisch wird es bei diesem Ansatz, wenn die Software-Anwendungen oder Objekte um Betriebsmittel konkurrieren müssen. Zu den begrenzten Betriebsmittel eines Computersystems gehören der Direktzugriffsspeicher (RAM), der Plattenspeicher und Netzwerkzugriffs- oder Kommunikationsmechanismen zur Kommunikation mit anderen Vorrichtungen. Traditionell war die Zuordnung von Betriebsmitteln Aufgabe eines Betriebssystems in einem Computer. Das Hauptziel eines Betriebssystems ist es, jedem Softwareobjekt so viele Betriebsmittel zuzuordnen wie es auf Teilnehmerbetriebbasis benötigt. Durch diesen Ansatz ist es für die Hersteller von Softwareobjekten schwierig, die Zuordnung unter den in der Verarbeitungsvorrichtung ausführenden Objekten zu steuern.
Es wird immer wichtiger, in der Lage zu sein, den Zugriff zu Betriebsmitteln in einer digitalen Verarbeitungsvorrichtung zu regulieren, da die Gesamtgröße und -menge von Betriebsmitteln abnimmt. Dies gilt insbesondere für die verbraucherorientierte eingebettete Verarbeitung wie in einer Fernsehempfangsvorrichtung oder sogenannten „Set-Top-Box".
Es ist daher wünschenswert, ein Betriebsmittelzugriffssteuersystem (RACS = resource access control system) für die Verwendung in einer Verarbeitungsvorrichtung, wie zum Beispiel einem Computer, einer Set-Top-Box oder einer anderen Vorrichtung bereitzustellen, mit der Betriebsmittelzugriff und -zuordnung in sehr hohem Maße gesteuert werden können. Durch das Ermöglichen einer besseren Steuerung der Betriebsmittelzuordnung können Hersteller von Softwareobjekten unterschiedliche Finanzmodelle für den Verkauf von Software-Funktionalität an einen Endbenutzer entwickeln. Zum Beispiel kann ein Softwareobjekt zu einem niedrigen Preis bereitgestellt werden, wenn der Zugriff zu bestimmten Betriebsmitteln (z. B. eine Modemverbindung, Zugriff zu einem Fernsehtuner, Festplattenspeicher etc.) eingeschränkt ist. Das gleiche Softwareobjekt kann zu einem höheren Preis mit Betriebsmittelzugriff auf einer höheren Stufe bereitgestellt werden, so dass es eine umfangreichere Funktionalität für den Endbenutzer bereitstellt.
Ein Betriebsmittelzugriffssteuersystem, das eine detaillierte Steuerung der Betriebsmittelzuordnung jedes Softwareobjekts bereitstellt, kann außerdem verwendet werden, um eine hohe Sicherheitsstufe zu erreichen. Bestimmte Objektklassen können auf das Verwenden von begrenzten Betriebsmitteln eingeschränkt werden, wodurch sichergestellt wird, dass Objekte von hoher Priorität oder hoher Sicherheit, die mehrere oder verschiedene Betriebsmittel verwenden, adäquat und privat ausgeführt werden können.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung stellt ein Betriebsmittelzugriffssteuersystem bereit, das die Zugriffsrechte einzelner Softwareobjekte, die in einer Verarbeitungsvorrichtung ausführen, beschränkt. Gemäß der vorliegenden Erfindung kann die Zuordnung von Betriebsmitteln für ein Softwareobjekt während der Ausführung des Softwareobjekts geändert werden.
Demgemäß stellt die vorliegende Erfindung in einer Ausführungsform ein Verfahren zur Steuerung des Betriebsmittelzugriffs in einer digitalen Verarbeitungsvorrichtung bereit, wobei das Verfahren Folgendes beinhaltet: einen ersten Satz von Betriebsmitteln einem Softwareobjekt in einer digitalen Verarbeitungsvorrichtung zuordnen; und die Zuordnung von Betriebsmitteln zu den Softwareobjekten während der Ausführung des Softwareobjekts ändern.
In einer weiteren Ausführungsform stellt die vorliegende Erfindung ein Verfahren zur Steuerung des Betriebsmittelzugriffs in einer digitalen Verarbeitungsvorrichtung bereit, wobei das Verfahren Folgendes beinhaltet: einen ersten Satz von Betriebsmitteln in der digitalen Verarbeitungsvorrichtung identifizieren; einen Bereich mit dem ersten Satz von Betriebsmitteln verknüpfen; und den ersten Satz von Betriebsmitteln einem Softwareobjekt zuordnen, indem das Softwareobjekt mit dem Bereich verknüpft wird.
In einer weiteren Ausführungsform stellt die vorliegende Erfindung ein Verfahren zur Steuerung des Betriebsmittelzugriffs in einer digitalen Verarbeitungsvorrichtung bereit, wobei das Verfahren Folgendes beinhaltet: einen ersten Satz von Betriebsmitteln einem Softwareobjekt in der digitalen Verarbeitungsvorrichtung zuordnen; und die Zuordnung von Betriebsmitteln zu dem Softwareobjekt ändern, um die Funktionalität des Softwareobjekts zu modifizieren.
In einer weiteren Ausführungsform beinhaltet ein System zur Steuerung des Betriebsmittelzugriffs in einer digitalen Verarbeitungsvorrichtung Folgendes: Mittel zum Zuordnen eines ersten Satzes von Betriebsmitteln zu einem Softwareobjekt in der digitalen Verarbeitungsvorrichtung; und Mittel zum Ändern der Zuordnung von Betriebsmitteln zu dem Softwareobjekt während der Ausführung des Softwareobjekts.
Ein besseres Verständnis der Natur und der Vorteile der vorliegenden Erfindung lässt sich mit Bezugnahme auf die folgende ausführliche Beschreibung und die beigefügten Zeichnungen erlangen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Beispiel für einige der zahlreichen Sicherheitsfäden, die in einem laufenden System präsent sein können;
2 stellt einen Berechtigungsstapelspeicher für einen Sicherheitsfaden dar; und
3 ist eine Abbildung von Berechtigungsstapelspeichern der vorliegenden Erfindung.
DETAILLIERTE BESCHREIBUNG DER SPEZIFISCHEN AUSFÜHRUNGSFORMEN
Die vorliegende Erfindung stellt ein Betriebsmittelzugriffssteuersystem bereit, das die Zugriffsrechte einzelner Softwareobjekte, die in einer Verarbeitungsvorrichtung ausführen, beschränkt. Eine Kabel- oder Satelliten-Set-Top-Box, oder jeder andere Computer-Host, beinhaltet im Allgemeinen verschiedene Arten von Softwareobjekten, d. h. Systemprogramme, Interpretierer, Anwendungen, Applets, Skripte etc. Softwareobjekte benötigen Zugriff zu Betriebsmitteln, um ihre Funktion zu erfüllen, d. h. sie brauchen ein physikalisches/Software-Betriebsmittel wie ein Modem zum Kommunizieren, einen Tuner zum Einstellen eines Fernsehkanals, eine Datei zum Speichern von Daten etc. Daher kann ein gegebenes Softwareobjekt eine gewisse Art von Zugriff auf eine gegebene Art von Betriebsmittelobjekt benötigen. Es sollte beachtet werden, dass der Satz an Betriebsmittelobjekten den Satz an Softwareobjekten beinhaltet. Mit anderen Worten kann ein gegebenes Softwareobjekt Zugriff auf ein anderes Softwareobjekt benötigen.
Verschiedene Softwareobjekte können einen unterschiedlichen Betriebsmittelbedarf aufweisen, können von verschiedenen Code-Quellen stammen oder im Namen unterschiedlicher Set-Top-Benutzer laufen. In all diesen Fällen ist es notwendig, die Zugriffsrechte des Softwareobjekts zu beschränken; z. B. können nicht alle Softwareobjekte mit der Verwendung eines Modems oder dem Lesen/Schreiben einer Passwortdatei betraut werden. Jedes Softwareobjekt sollte Zugriffsrechte für einen Teilsatz von Betriebsmitteln haben, wenn es berechtigt ist, auf diese Betriebsmittel zuzugreifen. Das RACS ist dafür verantwortlich, die Einschränkungen des Betriebsmittelzugriffs, mit denen jedes Softwareobjekt versehen ist, durchzusetzen.
Ein fundamentales Konzept und ein wichtiger Baustein des RACS ist der Kompetenzbereich. Ein Bereich kann durch den Satz von Betriebsmittelobjekten, auf die gegenwärtig von einem Softwareobjekt direkt zugegriffen werden kann, und Abläufe, die auf diesen Betriebsmitteln zugelassen sind, abgegrenzt werden. Ein Softwareobjekt ist eine Entität, der Zulassungen (und demzufolge Rechenschaft) erteilt werden.
Die Java-Sicherheitsarchitektur verwendet ein ähnliches Konzept wie das der Kompetenzbereiche, um heruntergeladene Objekte auf den Zugriff zu ausschließlich den Betriebsmitteln, zu denen sie berechtigt worden sind, zu beschränken. Dies ist ein Beispiel eines statischen Kompetenzbereichs, in dem die Betriebsmittel, für die ein bestimmtes Objekt eine Berechtigung hat, sich mit der Zeit nicht verändern.
Das RACS kann außerdem dynamische Kompetenzbereiche beinhalten. Die Einbeziehung eines dynamischen Kompetenzbereichs bedeutet, dass sich die Betriebsmittel, für die ein Objekt eine Berechtigung hat, mit der Zeit verändern, selbst während das Objekt läuft. Dynamische Kompetenzbereiche werden insbesondere als Werkzeuge für den bedingten Zugriff verwendet. Der Verbraucher kann ein Softwareobjekt herunterladen, von dem einige Funktionalitätsbereiche über eine Betriebsmittelsteuerung gesperrt sind. Zu einem späteren Zeitpunkt kann derselbe Verbraucher erweiterte Funktionalitätsbereiche innerhalb desselben Softwareobjekts erwerben. Erreicht wird dies, indem die Betriebsmittelsteuerung auf dem Softwareobjekt geändert wird, so dass das Softwareobjekt auf eine erweiterte Liste von Betriebsmitteln zugreifen kann (d. h. für diese nun eine Berechtigung hat).
Obwohl das RACS am einfachsten in einer objektorientierten Umgebung wie zum Beispiel Java implementiert wird, sind die RACS-Architektur und ihre Implementierung, die in diesem Dokument beschrieben sind, in jeder beliebigen Softwareumgebung anwendbar. Zum Beispiel kann eine Softwareumgebung aus nativen in C oder C++ geschriebenen Anwendungen, interpretierten Java-Anwendungen, die in einer Java Virtual Machine (JVM) laufen, und HTML-Skripten und Java-Applets, die in einem Browser laufen, bestehen.
In einer Ausführungsform ist ein Kompetenzbereich mit einer Objektgruppe verknüpft. Jedes Objekt enthält eine Sicherheitsgruppenkennung (ID), die das Objekt mit einem bestimmten Kompetenzbereich verknüpft. Alle Objekte mit derselben Sicherheitsgruppenkennung erhalten eine Berechtigung für einen identischen Satz an Betriebsmitteln. Es ist möglich, dass ein Kompetenzbereich genau ein Objekt enthält.
Ferner ist es möglich, dass ein System Softwareobjekte beinhaltet, die eine Berechtigung für alle Betriebsmittel auf dem Host haben. Dies bedeutet jedoch nicht, dass diese Objekte keine Betriebsmittelüberprüfungen durch das RACS benötigen. Der Konsistenz wegen wird jedes Objekt demselben Kompetenzbereich, welcher eine Berechtigung für alle Betriebsmittel hat, zugeordnet. Die Identität eines jeden solchen Objekts wird dennoch, genau wie jedes andere Objekt, einer Authentifizierung unterzogen.
Wenn dies nicht der Fall wäre und einige Objekte nicht mit irgendeiner Berechtigungsinformation verknüpft wären, könnte ein Eindringling das RACS auf einfache Weise umgehen, indem er ein Objekt, das auf einen bestimmten Kompetenzbereich begrenzt ist, nimmt und einfach dessen Berechtigungsinformation herauslöst.
Um die Berechtigung einer bestimmten laufenden Instanz eines Objektes zu bestimmen, genügt es nicht, den Kompetenzbereich dieses Objektes zu betrachten. Dies liegt daran, dass ein laufendes Objekt ein anderes Objekt aus einem anderen Kompetenzbereich aufrufen kann. Diese Aufrufsequenz von Objekten muss verfolgt werden, um die geltenden Zulassungen einer laufenden Instanz eines Objektes zu ermitteln.
In einer weiteren Ausführungsform wird die Verwendung eines Sicherheitsfadens vorgesehen. Der Sicherheitsfaden ist ein Ausführungsfaden, der den gegenwärtigen Berechtigungszustand zusätzlich zu dem gegenwärtigen Ausführungszustand verfolgt (z. B. Registerwerte, lokale Variablen etc.). Jeder Sicherheitsfaden führt, genauso wie andere Fäden, unabhängig aus.
Der Berechtigungszustand eines Sicherheitsfadens ist eine Liste von Betriebsmitteln und zulässigen Abläufen auf jenen Betriebsmitteln, für die der Faden eine gegenwärtige Berechtigung aufweist. Im Allgemeinen ist ein Berechtigungszustand eine Funktion der Kompetenzbereiche von allen Objekten, die sich in dem gegenwärtigen Aufrufstapelspeicher des Sicherheitsfadens befinden. Die Art und Weise, auf die ein Berechtigungszustand ermittelt wird, wird infra beschrieben.
Wie es bei anderen Fäden der Fall ist, kann ein Sicherheitsfaden einen weiteren Sicherheitsfaden hervorbringen. Der neue Faden wird den Berechtigungszustand des Fadens, der ihn hervorgebracht hat, übernehmen. Sobald der neue Faden jedoch mit der Ausführung beginnt, wird sein Berechtigungszustand, unabhängig von dem Berechtigungszustand des ursprünglichen Fadens, auf der Grundlage der Objekte, die er aufruft, modifiziert. Wenn RACS aktiviert ist, wird jeder einzelne Faden, der in dem Host läuft, ein Sicherheitsfaden sein und einen verknüpften Berechtigungszustand haben.
In einer spezifischen Ausführungsform, die in 1 gezeigt ist, wird ein Beispiel für einige der zahlreichen Sicherheitsfäden, die in einem laufenden System präsent sein können, dargestellt. In diesem Beispiel läuft anfänglich nur das Betriebssystem, das mit seinem eigenen Sicherheitsfaden 0 verknüpft ist.
Faden 0 bringt später eine E-Mail-Anwendung (Sicherheitsfaden A) und einen JVM (Sicherheitsfaden B) hervor. Die Sicherheitsfäden A und B beginnen mit einer Kopie des Berechtigungszustands des Sicherheitsfadens 0. Nachdem Sicherheitsfäden A und B hervorgebracht wurden, laufen 3 unabhängige Sicherheitsfäden (0, A und B), wobei jeder von ihnen einen eigenen Berechtigungszustand aufweist.
Später bringt die E-Mail-Anwendung drei weitere Fäden hervor. Eingehende Mail überprüfen (Sicherheitsfaden A-1), Ausgehende Mail versenden (Sicherheitsfaden A-2) und Ausgang formatieren und zum Drucker senden (Sicherheitsfaden A-2). Fäden A-1, A-2 und A-3 beginnen jeweils mit einer Kopie des Berechtigungszustands von Faden A.
Es laufen nun 6 unabhängige Sicherheitsfäden (0, A, A-1, A-2, A-3 und B).
Zum Schluss setzt der JVM drei Java-Anwendungen in Gang, wobei jede von ihnen einen eigenen Sicherheitsfaden aufweist: Bildschirmschoner (Sicherheitsfaden B-1), Fantasieuhr (Sicherheitsfaden B-2) und Internet-Banking (Sicherheitsfaden B-3). (Hier wird eine verallgemeinerte Definition einer Java-Anwendung verwendet, nämlich ein Java-Objekt auf hoher Ebene, das direkt von dem JVM in Gang gesetzt wird. Im Gegensatz zur Standarddefinition einer Anwendung – ein Objekt, das die Funktion „main()" beinhaltet – können mehrere solcher Anwendungen durch dieselbe Instanz eines JVM gesteuert werden. Ein Beispiel einer solchen Anwendung ist ein Java-Applet. Dieselbe Instanz eines JVM ist in der Lage, mehrere Applets gleichzeitig laufen zu lassen.) Die Fäden B-1, B-2 und B-3 beginnen mit einer Kopie des Berechtigungszustandes von Faden B. Es laufen nun neun unabhängige Sicherheitsfäden (0, A, A-1, A-2, A-3, B, B-1, B-2 und B-3).
Wenn ein Objekt ein anderes Objekt, das sich in einem anderen Kompetenzbereich befindet, aufruft, ist der Ablauf so, dass sich der gegenwärtige Berechtigungszustand mit dem Kompetenzbereich des aufgerufenen Objekts kreuzt. Dies bedeutet, dass das aufgerufene Objekt nicht auf ein Betriebsmittel zugreifen kann, es sei denn, es kann von jedem Objekt in dem gegenwärtigen Aufrufstapelspeicher darauf zugegriffen werden.
Es ist legitim, dass es Objekte gibt, die zu einem Kompetenzbereich gehören, der Rechte auf jedes einzelne Betriebsmittel hat, wie zuvor erwähnt. Wenn ein solches Objekt aufgerufen wird, bleibt der gegenwärtige Berechtigungszustand derselbe. Tatsächlich kann ein Objekt nicht in diesen Kompetenzbereich gesetzt werden, weil es Rechte zu allen Betriebsmitteln haben soll, sondern weil es den gegenwärtigen Berechtigungszustand übernehmen soll.
Ein einfaches Kreuzen von Kompetenzbereichen kann in einigen Fällen unzureichende sein. Zum Beispiel können mehrere Softwareobjekte berechtigt oder nicht berechtigt sein, Ausgang an einen Drucker zu senden. Sie sind jedoch nur dazu berechtigt, bestimmte API-Aufrufe auf einem Druckertreiber zu machen und sollten nicht direkt an den Druckeranschluss schreiben dürfen.
Daher ist der Kompetenzbereich des Druckertreiberobjekts der einzige Kompetenzbereich, der die Zugriffsrechte auf den Druckeranschluss beinhaltet. Nach der im obigen Abschnitt definierten Kreuzungsregel wird, wenn der Druckertreiber aufgerufen wird, sein Kompetenzbereich mit dem gegenwärtigen Berechtigungszustand gekreuzt und nicht mehr in der Lage sein, auf den Druckeranschluss zuzugreifen. Dies hat zur Folge, dass hier eine neue Art der Kombination von Kompetenzbereichen benötigt wird.
Das RACS verwendet den privilegierten Abschnitt, der dem privilegierten Java-Abschnitt ähnelt, um dieses Problem zu lösen. Wenn ein „Privileg beginnen"-Konstrukt innerhalb des ausführenden Objekts vorgefunden wird, wird der gegenwärtige Berechtigungszustand erneut modifiziert – er wird auf den Zusammenschluss des gegenwärtigen Berechtigungszustands und des Kompetenzbereichs des ausführenden Objekts eingestellt. Wenn „Privileg beenden" vorgefunden wird, geht der Berechtigungszustand zurück in den vorherigen Zustand.
Es sind verschiedene Implementierungen der Sicherheitsfäden vorgesehen. In einer Ausführungsform hat jeder Sicherheitsfaden einen verknüpften Berechtigungsstapelspeicher, der analog zum Aufrufstapelspeicher ist, jedoch unabhängig geführt wird. Jeder Eintrag auf dem Berechtigungsstapelspeicher ist der Berechtigungszustand. Der gegenwärtige Berechtigungszustand eines Sicherheitsfadens ist zu jedem beliebigen Zeitpunkt der Berechtigungszustand, der sich oben auf seinem Berechtigungsstapelspeicher befindet.
In Einklang mit der Erfindung wird immer dann, wenn ein Aufruf zu einem anderen Softwareobjekt gemacht wird, ein neuer Berechtigungszustand oben auf den Berechtigungsstapelspeicher geschoben. Wie zuvor spezifiziert, ist der neue Berechtigungszustand der Zusammenschluss des alten Berechtigungszustands mit dem Kompetenzbereich des aufgerufenen Objekts. Sobald die Ausführung dieses neuen Softwareobjekts abgeschlossen ist und die Steuerung auf das vorherige Objekt übertragen wird, wird der gegenwärtige Berechtigungszustand von dem Stapelspeicher abgehoben.
Wenn ein „Privileg beginnen"-Konstrukt vorgefunden wird, wird auf ähnliche Weise ein neuer Berechtigungszustand oben auf den Berechtigungsstapelspeicher geschoben. Dieses Mal ist der neue Berechtigungszustand die Kreuzung des alten Berechtigungszustands mit dem Kompetenzbereich des gegenwärtigen Objekts. Sobald der privilegierte Abschnitt beendet ist (mit einem „Privileg beenden"-Konstrukt), wird der Berechtigungszustand vom Stapelspeicher abgehoben.
Nun wird Bezug auf 2 genommen, in der ein Beispiel eines Berechtigungsstapelspeichers für den Sicherheitsfaden 1 gezeigt wird. Der Sicherheitsfaden 1 wird von einem anderen Zustand gestartet und nimmt einen anfänglichen Berechtigungszustand So an. Der Berechtigungszustand So ist eine Kopie des Berechtigungszustands des hervorgebrachten Fadens.
Anschließend wird Objekt A aufgerufen und ein neuer Berechtigungszustand auf den Stapelspeicher geschoben. Dieser ist die Kreuzung des vorherigen Berechtigungszustands und des Kompetenzbereichs von Objekt A (PO_A). Auf ähnliche Weise wird Objekt B aufgerufen und der neue Berechtigungszustand ist die Kreuzung des vorherigen Zustandes und des Kompetenzbereichs von B (PO_B).
Schließlich wird innerhalb von Objekt B ein „Privileg beginnen"-Konstrukt angetroffen, wodurch ein neuer Berechtigungszustand erzeugt wird. Der neue Berechtigungszustand ist der Zusammenschluss des vorherigen Berechtigungszustandes und PO_B.
Im weiteren Einklang mit der Erfindung ist jeder Eintrag in dem Berechtigungsstapelspeicher ein Berechtigungszustand, der wenigstens die folgenden Informationen beinhalten sollte: eine Objektkennung des gegenwärtig ausführenden Objekts; eine Sicherheitsgruppenkennung (die einen Kompetenzbereich identifiziert); einen Zeitstempel mit dem Zeitpunkt, zu dem dieser Berechtigungszustand geschaffen wurde (d. h. auf den Stapelspeicher geschoben wurde); und eine Liste zulässiger Betriebsmittelabläufe (z. B. Öffnen, Schließen, Lesen und Schreiben).
Die Berechtigung für ein bestimmtes Betriebsmittel wird während des Ablaufs überprüft. Der wichtigste Platz zur Durchführung einer Betriebsmittelüberprüfung ist innerhalb einer „Öffnen"-Funktion für ein bestimmtes Objekt, welches ein Betriebsmittel darstellt. Der Öffnungsaufruf sollte einen „Modus" beinhalten, der ein zurückgekehrtes Betriebsmittel-Handle auf einen bestimmten Satz an Abläufen begrenzt. Demzufolge würde eine Überprüfung innerhalb der „Öffnen"-Funktion bestätigen, dass der Sicherheitsfaden sowohl dazu berechtigt ist, auf dieses Betriebsmittel zuzugreifen als auch die spezifizierten Abläufe durchzuführen.
Abläufe, die auf dem geöffneten Betriebsmittel durchgeführt werden, können ebenfalls durch das RACS überprüft werden, um die Sicherheit weiter zu verbessern. Es ist durchaus denkbar, dass ein Handle zu einem Betriebsmittel auf illegalen Wege erhalten wurde (außerhalb des normalen Aufrufs „Öffnen"), was durch eine Betriebsmittelüberprüfung während eines nachfolgenden Ablaufs auf dem Handle festgestellt werden kann. Da Betriebsmittelabläufe häufig durchgeführt werden können, muss bei der Implementierung dieser folgenden Betriebsmittelüberprüfungen Acht gegeben werden. Es mag ausreichen, dass die folgenden Betriebsmittelüberprüfungen die tatsächliche Überprüfung im Sinne einer verbesserten Leistung nur einmal alle paar Aufrufe durchführen.
Wenn ein illegaler Betriebsmittelzugriff innerhalb einer Betriebsmittelüberprüfungs-API festgestellt wird, muss eine entsprechende Maßnahme ergriffen werden. In einer Ausführungsform wird die Betriebsmittelüberprüfungs-API von einem gegen Eingriffe gesicherten Sicherheitsprozessor durchgeführt, der dafür verantwortlich sein wird, bei einem Zugriff ohne Berechtigung entsprechende Maßnahmen zu ergreifen. Die ergriffene Maßnahme kann Beliebiges von dem Folgenden oder eine Kombination davon beinhalten: einen Fehlercode zurücksenden, den angeforderten Ablauf auf dem Betriebsmittel verweigern; eine Zugriff-ohne-Berechtigung-Nachricht an ein Protokoll schreiben; den Zugriff ohne Berechtigung einer zuverlässigen Autorität melden; den verstoßenden Sicherheitsfaden beseitigen; und/oder mit dem Abschalten von verschiedenen Diensten innerhalb des Hosts beginnen. Um größtmögliche Flexibilität zu gewährleisten, kann jeder Kompetenzbereich Merker beinhalten, die die ergriffene Maßnahme oder die ergriffenen Maßnahmen festlegen, wenn ein Zugriff ohne Berechtigung festgestellt wird.
Jede Betriebsmittelüberprüfung kann die Kommunikation mit einem Sicherheitsprozessor einschließen, wodurch zu viel Overhead erzeugt werden kann. Wie im vorherigen Abschnitt erwähnt, kann dieser Overhead dadurch verringert werden, dass die tatsächliche Überprüfung nur einmal alle paar Abläufe durchgeführt wird.
In einer alternativen Ausführungsform werden die einzelnen Betriebsmittelzugriffe nicht sofort und nicht von dem Sicherheitsfaden, der das Betriebsmittel erfasste, überprüft. Stattdessen wird für jeden Betriebsmittelzugriff ein Schatten-Bild erstellt, idealerweise im sicheren Speicher, der für den Sicherheitsprozessor verfügbar ist, und von einem unabhängigen Faden, der innerhalb des Sicherheitsprozessors läuft, nachgeprüft wird. Wenn dieser Faden einen Zugriff ohne Berechtigung feststellt, wird er einige Maßnahmen ergreifen, die Beliebiges von dem Folgenden oder eine Kombination davon sein können: eine Zugriff-ohne-Berechtigung-Nachricht an ein Protokoll schreiben; den Zugriff ohne Berechtigung einer zuverlässigen Autorität melden; den verstoßenden Sicherheitsfaden beseitigen; und/oder mit dem Abschalten von verschiedenen Diensten innerhalb des Hosts beginnen. Jeder Kompetenzbereich kann Merker beinhalten, die die ergriffene Maßnahme oder die ergriffenen Maßnahmen festlegen, wenn ein Zugriff ohne Berechtigung festgestellt wird, wie zuvor erwähnt.
Es mag wünschenswert sein, die Betriebsmittelzulassungen für verschiedene Kompetenzbereiche dynamisch zu verändern. Zum Beispiel können Betriebsmittelzulassungen auf der Grundlage der Funktionalität, die der Besitzer der Set-Top-Box oder einer anderen Plattform erworben hat, modifiziert werden. Wenn ein Softwareobjekt aufgerufen wird, werden die aktuellsten Betriebsmittelzulassungen, die mit dessen Kompetenzbereich verknüpft werden, für die Ermittlung des Berechtigungszustandes eines Sicherheitsfadens verwendet, wodurch das RACS dynamischer als das Standard-Java-Sicherheitsmodel wird.
Manchmal werden die Zulassungen für ein Objekt, das gegenwärtig ausgeführt wird, ebenfalls modifiziert. Ein Objekt wie JVM zum Beispiel kann für einen anhaltenden Zeitraum kontinuierlich ausgeführt werden, und es ist erwünscht, dass die Änderungen vor einem Neustart in Kraft treten. Um diesen Fall zu bewältigen, müssen zusätzliche Mechanismen definiert werden.
Jeder Eintrag in dem Berechtigungsstapelspeicher enthält die Sicherheitsgruppenkennung, die sich auf einen bestimmten Kompetenzbereich bezieht. Wenn Betriebsmittelzulassungen für einen der Kompetenzbereiche in dem Berechtigungszustand modifiziert werden, ist es möglich, dass der Stapelspeicher aktualisiert wird, indem jeder Eintrag, beginnend mit demjenigen, der einem modifizierten Kompetenzbereich entspricht, und fortfahrend bis zum Ende des Stapelspeichers, modifiziert wird.
Bedauerlicherweise würde dies nicht ausreichen, um das Problem zu lösen. Wenn ein Sicherheitsfaden A einen Sicherheitsfaden A-1 hervorbringt, ist der anfängliche Berechtigungszustand von A-1 zu dem Zeitpunkt, zu dem A-1 erstellt wird, auf den Berechtigungszustand von A eingestellt. Angenommen einer der Kompetenzbereiche in dem Berechtigungsstapelspeicher von A wird zu dem Zeitpunkt T modifiziert. Der Berechtigungsstapelspeicher von A kann nun angeglichen werden, aber es kann sein, dass der anfängliche Berechtigungszustand von A-1 nun nicht mehr aktuell ist.
Es besteht keine Möglichkeit, eine Verbindung von dem Berechtigungsstapelspeicher von A zu dem anfänglichen Berechtigungszustand von A-1 bereitzustellen. Dies liegt daran, dass, nachdem A-1 gestartet wird, Faden A weiterhin unabhängig ausgeführt werden kann und nach einer Zeit T der Berechtigungsstapelspeicher von A völlig unterschiedlich sein kann oder A bis dann möglicherweise aufgehört hat.
Die vorliegende Erfindung stellt eine Lösung für dieses Problem bereit. Angenommen Sicherheitsfaden A erzeugt A-1. Der Berechtigungsstapelspeicher von A-1 wird dann zu einer exakten Kopie von dem Berechtigungsstapelspeicher von A initialisiert. Folglich wird, wenn ein Kompetenzbereich, der sich zu der Zeit (als A-1 erzeugt wurde) zufällig in dem Berechtigungsstapelspeicher von A befand, modifiziert wird, dieser auch in dem Berechtigungsstapelspeicher von A-1 wiederzufinden sein. Dies ermöglicht, dass alle Berechtigungszustände von A-1 in dem Stapelspeicher ordnungsgemäß aktualisiert werden.
Was nun 3 betrifft, ist zu sehen, wie Sicherheitsfaden A A-1 erzeugt. Anfänglich führt Faden A Objekt A aus, was bedeutet, dass Einträge, die von dem Kompetenzbereich von A betroffen sind, sowohl in dem Berechtigungsstapelspeicher von A als auch von A-1 gefunden wurden. Zu einem späteren Zeitpunkt (in Schritt 5) beendet Faden A das Ausführen von Objekt A und die entsprechenden Einträge in dem Berechtigungsstapelspeicher von A werden entfernt. Da Faden A-1 jedoch von dem Code in Objekt A erzeugt wurde, bleiben die entsprechenden Einträge in dem Berechtigungsstapelspeicher von A-1. Zu einem späteren Zeitpunkt wird der Kompetenzbereich von Objekt A modifiziert. Dies hat keinen weiteren Einfluss auf den Berechtigungsstapelspeicher von A, da er nicht Objekt A ausführt. Es hat jedoch einen Einfluss auf den Berechtigungsstapelspeicher von A-1, der entsprechend aktualisiert wird.
In einer Ausführungsform gibt es einen separaten Ausführungsfaden, Berechtigungsstapelspeicher-Auffrischungs-Faden (ASR-Faden, ASR = authorisation stack refresh) genannt, der die Inhalte von Berechtigungsstapelspeichern dynamisch aktualisiert, wenn sich die Kompetenzbereiche verändern. Hiermit kann nicht garantiert werden, dass die Berechtigungsstapelspeicher sofortig aktualisiert werden, es wird jedoch sichergestellt, dass sie innerhalb eines angemessenen Zeitraumes aktualisiert werden. Ob der Faden gestartet wird oder nicht ist optional und hängt davon ab, ob die Betriebsmitttelzulassungen, während ein bestimmtes Objekt ausgeführt wird, aktualisiert werden müssen oder nicht.
Um das RACS sicher zu implementieren, muss die Identität eines jeden Objekts sowohl während seines Herunterladens als auch während seines Startens (Starten der Ausführung) authentifiziert werden. Die Objektauthentifizierung kann unabhängig von dem RACS implementiert werden und ist nicht im Umfang dieser Diskussion inbegriffen.
Die Betriebsmittelzulassungen für einen Kompetenzbereich können sich dynamisch verändern und müssen außerdem sicher übergeben werden. Die Betriebsmittelzulassungen für jedes Objekt können mit einem privaten Schlüssel der Berechtigungsstelle signiert sein und sollten eine Versionsnummer enthalten, um Version-Rollback-Angriffe zu verhindern. Alternativ dazu kann die Berechtigungsautorität Betriebsmittelzulassungen über ein sicheres Nachrichtenprotokoll, wie TLS oder IPSEC, liefern. Die Einzelheiten der Lieferung von Betriebsmittelzulassungen sind nicht im Umfang dieser Diskussion eingeschlossen.
Die Sicherheit von RACS wird weiter verbessert, wenn alle Betriebsmittel- und Authentifizierungsüberprüfungen in einem gegen Eingriffe gesicherten Sicherheitsprozessor verkapselt sind. Das Design des Sicherheitsprozessors ist ebenfalls nicht im Umfang dieser Diskussion eingeschlossen.
Abschließend stellt die vorliegende Erfindung Verfahren zur Steuerung des Betriebsmittelzugriffs in einer digitalen Verarbeitungsvorrichtung bereit. Während Obiges eine komplette Beschreibung der bevorzugten erfindungsgemäßen Ausführungsform ist, ist es ebenso möglich, verschiedene Alternativen, Modifikationen und Äquivalente zu verwenden.
Abschließend stellt die vorliegende Erfindung Verfahren zur Steuerung des Betriebsmittelzugriffs in einer digitalen Verarbeitungsvorrichtung bereit. Während Obiges eine komplette Beschreibung der bevorzugten erfindungsgemäßen Ausführungsform ist, ist es ebenso möglich, verschiedene Alternativen, Modifikationen und Äquivalente zu verwenden. Daher sollte der Umfang der vorliegenden Erfindung nicht in Bezug auf die obige Beschreibung, sondern stattdessen in Bezug auf die beigelegten Ansprüche, zusammen mit dem vollständigen Umfang ihrer Äquivalente, bestimmt werden.

Claims

Ein Verfahren zur Steuerung des Betriebsmittelzugriffs in einer digitalen Verarbeitungsvorrichtung, wobei das Verfahren Folgendes umfasst: einen Kompetenzbereich einschließlich eines ersten Satzes von Betriebsmitteln und zulässigen Abläufen einem Softwareobjekt in der digitalen Verarbeitungsvorrichtung zuordnen; und die Zuordnung von Betriebsmitteln und zulässigen Abläufen zu dem Softwareobjekt während der Ausführung des Softwareobjekts ändern.
Verfahren gemäß Anspruch 1, das ferner Folgendes umfasst: einen ersten Satz von Betriebsmitteln und zulässigen Abläufen in der digitalen Verarbeitungsvorrichtung identifizieren; einen Kompetenzbereich mit dem ersten Satz von Betriebsmitteln und zulässigen Abläufen verknüpfen; und den ersten Satz von Betriebsmitteln und zulässigen Abläufen einem Softwareobjekt zuordnen, indem das Softwareobjekt unter Verwendung eines Kennungswertes mit dem Kompetenzbereich verknüpft wird.
Verfahren gemäß Anspruch 2, wobei ein Softwareobjekt mit einem oder mehreren Kompetenzbereichen verknüpft werden kann.
Verfahren gemäß Anspruch 2, wobei der Kompetenzbereich statisch ist.
Verfahren gemäß Anspruch 2, wobei der Kompetenzbereich mit einem neuen Satz von zulässigen Abläufen dynamisch aktualisiert wird.
Verfahren gemäß Anspruch 2, wobei ein Softwareobjekt mit einer Sicherheitsgruppenkennung verknüpft ist, welche das Softwareobjekt mit dem Kompetenzbereich verknüpft.
Verfahren gemäß Anspruch 2, wobei jedes mindestens eines Softwareobjekts mit einer einzelnen Sicherheitsgruppenkennung verknüpft ist; und jede unterschiedliche Sicherheitsgruppenkennung das Softwareobjekt oder damit verknüpfte Objekte mit einem unterschiedlichen Kompetenzbereich verknüpft.
Verfahren gemäß Anspruch 7, das ferner Folgendes einschließt: einen Sicherheitsfaden mit einem Berechtigungszustand laufen lassen; und Softwareobjekte über den Sicherheitsfaden aufrufen, wobei der Berechtigungszustand basierend auf die über den Sicherheitsfaden aufgerufenen Softwareobjekte modifiziert wird.
Verfahren gemäß Anspruch 8, wobei sich der Berechtigungszustand, wenn ein erstes Softwareobjekt ein zweites Softwareobjekt aufruft, mit dem Kompetenzbereich des zweiten Softwareobjekts kreuzt.
Verfahren gemäß Anspruch 7, wobei alle der Softwareobjekte, die mit derselben Sicherheitsgruppenkennung verknüpft sind, für einen identischen Satz an Betriebsmitteln berechtigt sind.
Verfahren gemäß Anspruch 8, das ferner Folgendes einschließt: einen Berechtigungsstapelspeicher mit einem Sicherheitsfaden verknüpfen, wobei der gegenwärtige Berechtigungszustand des Sicherheitsfadens der Berechtigungszustand ist, der sich in dem obersten Teil des Berechtigungsstapelspeichers befindet.
Verfahren gemäß Anspruch 1, das ferner Folgendes umfasst: die Zuordnung von Betriebsmitteln zu dem Softwareobjekt ändern, um die Funktionalität des Softwareobjekts zu modifizieren.
Verfahren gemäß Anspruch 12, wobei die Zuordnung von Betriebsmitteln zu dem Softwareobjekt geändert wird, während das Softwareobjekt ausführt.
Verfahren gemäß Anspruch 5, das ferner Folgendes umfasst: den Kompetenzbereich aktualisieren, indem unter Verwendung eines sicheren Onlineprotokolls eine Nachricht gesendet wird.
Verfahren gemäß Anspruch 8, wobei eine Vielzahl von Sicherheitsfäden einschließlich mehrerer Objekte in mehreren Kompetenzbereichen in einem Host ausführen, wobei die Vielzahl von Sicherheitsfäden durch unterschiedliche Sicherheitsgruppenkennungen identifiziert werden, wobei das Verfahren ferner Folgendes umfasst: an dem Host eine Nachricht empfangen, um erlaubte Betriebsmittelabläufe für einen gegebenen Kompetenzbereich zu ändern; und den Berechtigungszustand von Sicherheitsfäden als Antwort auf die geänderten erlaubten Betriebsabläufe für den gegebenen Kompetenzbereich aktualisieren.
Verfahren gemäß Anspruch 8, wobei ein erstes Objekt in einem ersten Kompetenzbereich ein zweites Objekt in einem zweiten Kompetenzbereich aufruft, wobei das Verfahren ferner Folgendes umfasst: den Berechtigungszustand mit dem zweiten Kompetenzbereich kreuzen, um erlaubte Betriebsabläufe für das zweite Objekt zu bestimmen.
Verfahren gemäß Anspruch 8, wobei ein erstes Objekt in einem ersten Kompetenzbereich ein zweites Objekt in einem zweiten Kompetenzbereich aufruft, wobei das Verfahren ferner Folgendes umfasst: eine Vereinigung des ersten und zweiten Kompetenzbereichs bestimmen, um erlaubte Betriebsabläufe für das zweite Objekt zu bestimmen.
Verfahren gemäß Anspruch 8, wobei ein Stammfaden einen neuen Faden hervorbringt und der neue Faden den Berechtigungszustand des Stammfadens übernimmt.