DE3751047T2

DE3751047T2 - Softwareschutzsystem einschliesslich eines Einschlüsselkryptosystems, eines auf Hardware beruhenden Genehmigungssystems und eines geschützten Zusatzprozessors.

Info

Publication number: DE3751047T2
Application number: DE3751047T
Authority: DE
Inventors: Ashileshwari Narain Chandra; Liam David Comerford; Steve Richard White
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1986-11-05
Filing date: 1987-11-03
Publication date: 1995-08-10
Anticipated expiration: 2007-11-04
Also published as: EP0266748A2; EP0266748B1; DE3751047D1; EP0266748A3

Description

Die Erfindung betrifft das Gebiet der Datenverarbeitung und im speziellen einen Kopierschutz für Software. Im besonderen wird ein Mechanismus bereitgestellt, der die Benutzung von auf Magnetplatten oder anderen Medien vertriebener Software auf Computer beschränkt, die mit einem spezifischen physisch sicheren Coprozessor verbunden sind, wobei dieser Mechanismus die Herstellung von Sicherungskopien durch den Benutzer nicht stört, der Softwareschutz aber durch keine dieser Sicherungskopien gefährdet ist.
Eine gute Beschreibung des technischen Hintergrundes der Erfindung wird in der EP-A-0 174 472 der Anmelderin gegeben.
In Erweiterung des Standes der Technik, der in der erwähnten Anmeldung beschrieben ist, schlägt Uchenick in dem U.S.-Patent Nr. 4 458 315 ein Sicherungsverfahren für den Softwareschutz vor, bei dem die Software mit einer Schlüsselnummer (erste Schlüssel-Information) vertrieben wird. Damit die Software ausgeführt werden kann, muß der Computer Zugriff zu einem Gerät haben, das eine zweite "Schlüsselinformation" gespeichert hat. Das Programm wird, ohne daß die erste und die zweite Schlüsselinformation bestimmte spezifische Beziehungen miteinander eingehen, nicht ordnungsgemäß arbeiten. Das Patent beschreibt jedoch weder die Verwendung eines Vorgangszeichens, die einen wesentlichen Teil der vorliegenden Erfindung bildet, noch gibt es dort irgendein offensichtliches Hindernis, das einen Hacker davon abhalten könnte, die Software lediglich zu ändern, so daß sie dann ohne diesen Vergleichsschritt ausgeführt werden kann, noch beschreibt das Patent, wie der Computer Zugriff auf die "Aufzeichnungs-Schlüsselinformation" bekommt und zwar auf solche Art und Weise, daß diese nicht dupliziert oder gefälscht werden kann.
Best beschreibt in den U.S.-Patenten 4 168 396, 4 278 837 und 4 465 901 einen Programmschutzmechanismus, welcher verschlüsselte Programme verwendet. Best schlägt jedoch vor, daß jede Kopie eines Programms kundenspezifisch hergestellt wird, so daß sie nur auf einem einzigen Mikroprozessor, d.h. in einem einzelnen physisch einzigartigen Mikroprozessor ausführbar ist. Dieser Schutz erscheint durch Aufdecken des zur Entschlüsselung benötigten Schlüssels und durch andere kryptoanalytische Verfahren umgehbar zu sein. Als ein praktisches Verfahren für den Softwareschutz ist diese Methode jedoch nicht brauchbar. Ein Softwareverkäufer muß jede Kopie seiner Software < welche kundenspezifisch konfiguriert ist) zusammen mit dem Mikroprozessor verkaufen, der für die Ausführung der zugehörigen Software spezifiziert ist. Die einzige Alternative besteht für den Softwareverkäufer darin, den Mikroprozessor, den der Benutzer besitzt, zu identifizieren, so daß die Software für diesen speziell eingerichtet werden kann. Mit der Erweiterung, daß Softwareverkäufer die Software für eine Klasse von Mikroprozessoren freigeben (z.B. für alle 80286), geht der Schutz verloren, weil alle Duplikate frei auf allen Mikroprozessoren dieser Klasse laufen.
Die EP-A-0 191 162 offenbart ein kryptographisches Verfahren, wobei jede Kopie des Programms mit einem Schlüssel verschlüsselt wird, der für diese Kopie spezifisch ist. Der Benutzer des Programms hat ein Paßwort, das für diesen Benutzer spezifisch ist. Das Benutzer-Paßwort kann auf einer Magnetkarte (smart card) implementiert sein oder als Paßwort über die Tastatur eingegeben werden. Jede Kopie des Programms ist individuell spezifiziert.
Die bereits erwähnte Schrift EP-A-0 174 472 beschreibt ein Verfahren zur Aufzeichnung von Daten auf magnetischen Medien auf solche Weise, daß der Vorgang des Datenlesens die Daten verändert. Derartige "einmal zu lesende" magnetische Aufzeichnungen können nicht durch konventionelle Plattenlaufwerke erzeugt werden, so daß sie durch konventionelle Personalcomputersysteme nicht kopiert werden können. Wie in der erwähnten Anmeldung beschrieben ist, ist einem Computer ein physisch und logisch sicherer Coprozessor zugeordnet und die auf einem magnetischen Medium vertriebene Software enthält mindestens einen Abschnitt oder Teil, der verschlüsselt ist. Das magnetische Medium enthält außerdem einen verschlüsselten Dechiffrierschlüssel, welcher durch den Coprozessor zur Dechiffrierung des verschlüsselten Teils der Software verwendet werden muß. Der Vorgang des Übertragens des verschlüsselten Dechiffrierschlüssels vom magnetischen Medium zum sicheren Coprozessor ist mit einem Mechanismus verknüpft, der die Daten verändert. Dies sichert, daß ohne außerordentliche Maßnahmen der verschlüsselte Dechiffrierschlüssel nicht mehr übertragbar ist, wenn das magnetische Medium einmal gelesen worden ist. Dies verhindert die Erstellung von Kopien des Verteilungsmediums, die mit anderen Computer angefertigt werden können und den Kopierschutzmechanismus zerstören würden. Wenn der Coprozessor einmal Zugriff zum verschlüsselten Dechiffrierschlüssel hat, kann er diesen Schlüssel entschlüsseln. Wenn die Software ausgeführt wird, wird der verschlüsselte Teil durch den Coprozessor entschlüsselt. Dies sichert die Ausführbarkeit der Software, verhindert aber, daß der Benutzer Zugriff auf das gesamte Softwarepaket in entschlüsselter Form bekommt.
Der in der erwähnten Anmeldung beschriebene Mechanismus ist gegen Angriffe sehr widerstandsfähig, weil der Dechiffrierschlüssel und der geschützte Teil der Software dem Benutzer niemals in unverschlüsselter Form zugängig sind. Dem Besitzer der Software ist es gestattet, unbegrenzt Sicherungskopien anzulegen, aber diese Sicherungskopien sind auf jedem anderen Personalcomputer (einem, welcher keinen Zugriff auf den speziellen Coprozessor hat, der bereits den Dechiffrierschlüssel gespeichert hat) nutzlos. Das Schutzsystem kann von jedem Softwareautor benutzt und von jedem Hardwareproduzenten gefertigt werden, weil kein Teilen geheimer Informationen (Schlüsselinformation) zwischen den beteiligten Parteien erforderlich ist und weil die Methoden öffentlich gemacht werden können, ohne der Sicherheit des Systems zu schaden.
Die einmal zu lesende Magnetaufzeichnung hat jedoch in einem Kopierschutzsystem zwei verwundbare Stellen. Erstens ist es immer möglich (obwohl kostspielig) das magnetische Medium zu untersuchen und ein Gerät herzustellen, welches dessen Verhalten gegenüber einem Computersystem nachbildet. Zweitens könnte ein entschlossener Hacker in der Lage sein, eine Vorrichtung zu bauen, welche den Vor-Lese-Zustand der "einmal zu lesenden", aufgezeichneten Daten wiederherstellt, die dazu verwendet wurden, ein System in die Lage zu versetzen, einen Dechiffrierschlüssel zu akzeptieren. Das neu initialisierte Medium kann dann dazu verwendet werden, illegal ein zweites System zu "autorisieren".
Das Verfahren, wie es in der erwähnten Anmeldung beschrieben ist, erfordert die Benutzung eines bekannten Chiffriersystems mit Schlüssel. Diese Begrenzung der Systemarchitektur schränkt die Flexibilität des Systems ein. Zusätzlich erfordert das in der erwähnten Anmeldung beschriebene System die Verwendung eines Bus-Steckplatzes, der auf einigen Systemen nicht verfügbar sein kann oder der für einen Benutzer zu wertvoll sein kann. Dies ist aber notwendig, damit es dem Coprozessor ermöglicht wird, die Busoperationen des Wirtsrechners zu beobachten, so daß er selbst sicherstellen kann, daß die Erscheinung der einmal zu lesenden Magnetaufzeichnung nicht durch ein Programm auf dem Wirtsrechner simuliert wird.
Die vorliegende Erfindung überwindet die oben erwähnten Nachteile erstens dadurch, daß ihr kein Bus-Steckplatz für einen physisch sicheren Coprozessor zugewiesen werden muß und sie verläßt sich weder auf bekannte Schlüssel-basierte Chiffriersysteme noch verläßt sie sich auf einmal zu lesende magnetische Medien. Unter diesen Gesichtspunkten ist sie sowohl flexibler als auch gegen versuchte Softwarepiraterie widerstandsfähiger als das frühere System.
Die vorliegende Erfindung basiert auf der Erkenntnis, daß die heutige Vertriebspraxis bei der Software dem Benutzer zusätzlich zu der Software selbst auch das Recht "liefert", die Software auszuführen. Das heißt im besonderen, daß wenn Software an einen typischen Benutzer verkauft wird, der Benutzer nicht nur die Software selbst erwirbt, sondern auch das Recht, diese zu benutzen. Er kann jedoch mit einem typischen Personalcomputer die Software duplizieren und sie zusammen mit dem (implizierten) Recht, diese zu benutzen, an andere weiterverteilen. Die vorliegende Erfindung sucht nach Möglichkeiten, die Software von dem Recht, sie zu benutzen, zu trennen. Weiterhin wird angestrebt, die Mittel zum Erzeugen dieser Ausführungsrechte in die Hände der Softwareautoren oder ihrer Vertreter zu geben. Es wird ebenfalls angestrebt, diese Dinge so zu organisieren, daß existierende oder geplante Vertriebskanäle für die Software nicht gestört werden und daß nur minimale Veränderungen an den Mitteln, mit welchen die Software für den Vertrieb vorbereitet wird, vorgenommen werden müssen. Wie weiter unten beschrieben werden wird, kann entsprechend der vorliegenden Erfindung der typische Softwarekäufer, die Software, die er vom Händler erhalten hat, nach freiem Willen duplizieren. Das Recht auf Benutzung der Software kann er jedoch nicht duplizieren. Er erhält tatsächlich eine einzelne Berechtigung, diese Software zu benutzen. Um wirksam zu werden, muß dieses Benutzungsrecht in einem geeigneten Coprozessor installiert sein und nur wenn das Benutzungsrecht auf dem geeigneten Coprozessor (welcher mit dem Wirtsrechner verbunden ist, auf welchem der Benutzer die Software ausführen lassen will) installiert ist, wird die Software ausführbar. Andere Kopien der Software, die der Benutzer angefertigt haben könnte, sind auf jedem anderen Wirtsrechner nicht ausführbar (selbst dann, wenn solch ein anderer Wirtsrechner mit einem anderen geeigneten Coprozessor verbunden ist).
Gemäß der vorliegenden Erfindung kann die Software auf magnetischen Medien (wie beispielsweise auf Band oder Diskette) oder über andere Mittel (Telephonleitungen, Kabel oder Rundfunkübertragung) vertrieben werden. Die Software ist in einen verschlüsselten Abschnitt Pe (encrypted) und einen unverschlüsselten Abschnitt Pc (clear text) unterteilt. Die Auswahl der Unterteilung erfolgt durch den Softwarehändler unter Kenntnis des Umstandes, daß nur der verschlüsselte Teil vor Piraterie geschützt ist. Der verschlüsselte Abschnitt Pe der Software wird durch einen physisch und logisch sicheren Coprozessor entschlüsselt und ausgeführt, wenn der Coprozessor den Dechiffrierschlüssel besitzt, welcher das Recht zur Ausführung verkörpert. Der geschützte Teil der Software wird folglich niemals in Klartext dargestellt und niemals durch ein unbefugtes System ausgeführt. Der Coprozessor kann an den Personalcomputer des Benutzers entweder über den Systembus oder über eine Ein/Ausgabe-Schnittstelle oder eine andere Kommunikationsschnittstelle angeschlossen werden.
Damit der Coprozessor wirksam werden und den verschlüsselten Abschnitt der geschützten Software entschlüsseln kann, muß er mit dem Dechiffrierschlüssel (Right-to-execute RTE - Befugnis zur Ausführung - auch als AK oder Application Key - Anwendungsschlüssel bezeichnet) ausgerüstet werden, der dazu benötigt wird, den verschlüsselten Abschnitt der Software ausführbar zu machen. Der Schlüssel (RTE oder AK) muß in den Coprozessor des Softwarebesitzers so übertragen werden, daß der Übertragungsmechanismus nicht durch einen Benutzer wiederverwendet oder reproduziert werden kann, der dann den Freigabeschlüssel auf andere Personalcomputer übertragen könnte. Dies wird dadurch erreicht, daß der wirksamen Übertragung des Dechiffrierschlüssels in den nicht-flüchtigen Speicher des Coprozessors ein Vorgangszeichen (Token) zugeordnet ist, z.B. ist die Präsenz des Vorgangszeichens für die wirksame Übertragung des Dechiffrierschlüssels zum Coprozessor erforderlich. Das Zeichen ist aus Gründen, welche weiter unten beschrieben werden, gegen Fälschungen sehr widerstandsfähig und sein Inhalt wird während des Übertragungsvorgangs zerstört. Das Zeichen besitzt einen Informationsgehalt, der dem Coprozessor bekannt ist, weil dieser in einer verschlüsselten Datei ausgewiesen ist. Diese Datei wird als "Verschlüsselte Token Beschreibung" oder ETD (Encrypted Token Description) bezeichnet. Diese Identifikation wird dem Coprozessor gegenüber dadurch als echt ausgewiesen, daß sie mit demselben Schlüssel (AK) verschlüsselt wurde, den der Softwarehändler benutzt hat, um den geschützten Abschnitt der Software zu verschlüsseln. Die ETD-Datei kann dadurch an den Benutzer weitergegeben werden, daß sie in ein zugeordnetes Register des Tokens geschrieben wird, indem sie auf dem Vertriebsmedium aufgezeichnet wird oder indem sie über andere Mittel vertrieben wird.
Der vom Softwarehändler gelieferte Schlüssel (AK) wird für den Coprozessor dadurch verfügbar, daß er in verschlüsselter Form zusammen mit dem Programm über das Verteilungsmedium der Software oder über andere Mittel bereitgestellt wird, wie sie im Fall der ETD-Datei beschrieben worden sind. Im allgemeinen Fall wird der Schlüssel zum Verschlüsseln des AK aus einer Liste von Coprozessor-Steuerprogrammschlüsseln (CSKs - Coprozessor Supervisor Keys) ausgewählt, welche in allen Coprozessoren gespeichert ist, die von einem gegebenen Händler geliefert werden.
Die Funktion des Verschlüsselns des Dechiffrierschlüssels des Softwarehändlers mit einem dieser gespeicherten Chiffrierschlüssel ist ein Service, der vom Coprozessor bereitgestellt wird, so daß der Schlüssel-Speicher (CSKs) dem Softwarehändler niemals offengelegt werden muß. Der Coprozessor, den der Softwarehändler verwendet, um den Softwarehändler-Schlüssel zu verschlüsseln, kann genau derselbe Typ Coprozessor sein, wie ihn der Benutzer zum Entschlüsseln und Ausführen der Software verwendet. Alternativ dazu können spezielle Prozessoren zu diesem Zweck verkauft werden, oder es können Standardprozessoren durch eine verschlüsselte Nachricht vom Hardwarehersteller in die Lage versetzt werden, diese Funktion auszuführen. Diese Optionen können nützlich sein, um dem Händler solcher Geräte eine gewisse Flexibilität zu verschaffen.
Aus demselben Grund, aus dem der Softwarehändler-Dechiffrierschlüssel (wie beispielsweise der AK) niemals dem Benutzer der Software offengelegt wird, werden die Chiffrierschlüssel des Hardwareverkäufers (CSK) niemals dem Softwarehändler offengelegt. Dieses System hat folglich die Eigenschaft, daß zur Verwendung des bereitgestellten Schutzmechanismus keinerlei Informationen zwischen Hardware- und Softwareherstellern ausgetauscht werden muß. Zusätzlich kann für alle Chiffrierfunktionen ein einzelnes Chiffriersystem, wie beispielsweise DES, verwendet werden.
Entsprechend der vorliegenden Erfindung wird dem Coprozessor zum Zugriff auf das Übertragungstoken ein Datenübertragungsweg zur Verfügung gestellt, der eine Datenübertragung mit einem Hardware-Subsystem, beispielsweise einer Speicherkassette, gestattet. Dieser Datenübertragungsweg kann eine Verbindung zur Kassette verwenden, die entweder vom Wirtsrechner (wie beispielsweise ein PC) oder vom Coprozessor bereitgestellt wird, Die Kassette enthält einen elektronischen Speicher mit Eigenschaften, die sich (auf eine Art und Weise, die noch beschrieben wird) in Abhängigkeit davon verändern, ob der Speicher ausgelesen oder in ihn geschrieben wird. Dieses Kassetten-Subsystem muß extrem schwierig zu kopieren sein, in dem Sinn, daß es sehr unwahrscheinlich ist, daß ein von einem Benutzer erzeugtes Substitut einen Coprozessor dazu verleitet, es als Verifikation des Benutzer-Rechts, einen gegebenen Dechiffrierschlüssel (AK) in den Benutzer-Coprozessor zu speichern, zu akzeptieren. Weil die Verbindung zu dem Subsystem physisch offenliegt, muß der Übertragungsmechanismus, der diese Verbindung als sein Übertragungsmedium benutzt, gegen Fälschungen widerstandsfähig sein.
Um gegen Fälschungen widerstandsfähig zu sein, muß jeder Vorgang wirklich einmalig und durch den Coprozessor verifizierbar sein. Die Technik, durch welche diese Sicherheit erreicht wird, wird unten beschrieben.
Das Subsystem, welches dazu verwendet wird, das Recht des Benutzers auf einen speziellen Dechiffrierschlüssel zu verifizieren wird als Übertragungstoken bezeichnet. Die notwendigen Funktionen können unter Verwendung von Programmen implementiert werden, die durch einen Mikroprozessor oder durch Verwendung eines zweckbestimmten Hardwaresystems ausgeführt werden. Da die wirtschaftlichste Implementierung eines Übertragungstokens ein zweckbestimmtes Hardwaresystem ist, ist dies die Version, die beschrieben wird.
Die Übertragungstoken-Hardware und deren Informationsgehalt.muß physisch sicher bleiben, damit ein Zugriff auf sie durch den Benutzer mit Mitteln, die die Eigenschaft des Fälschungsschutzes umgehen, verhindert wird. Eine Implementierung dieser physischen Sicherheitsvorkehrungen wird in der EP-A-0 268 882 beschrieben, deren Offenbarung durch diese Bezugnahme aufgenommen ist. Dieselbe Technik kann verwendet werden, um den Coprozessor selbst physisch zu sichern und um dessen Speicherinhalt vor der Offenlegung durch einen Benutzer zu schützen. Weil Token als einzelne, ständig mit Energie versorgte integrierte Schaltkreischips implementiert werden können, werden keine weiteren physischen Sicherheitsvorkehrungen benötigt. Wenn die physischen Sicherheitsvorkehrungen eines Tokens gebrochen werden, werden keine Chiffrierschlüssel offenbart, und nur das einzelne zugehörige Softwarepaket kann weitergegeben werden.
Dementsprechend wird gemäß der vorliegenden Erfindung die zu schützende Software in einen Klartext-Abschnitt und in einen verschlüsselten Abschnitt unterteilt, wobei der Chiffrierschlüssel (AK), der zum Verschlüsseln der Software verwendet wird, nur dem Softwarehändler bekannt ist. Die geschützte Software, die dem Benutzer geliefert wird, ist mit dem Software-Dechiffrierschlüssel verbunden, der in verschlüsselter Form (EAK) vorliegt. Der Software-Chiffrierschlüssel (AK) wird mit dem Chiffrierschlüssel (CSK) des Hardwareverkäufers verschlüsselt, welcher dem Softwarehändler unbekannt ist. Diese Verschlüsselung ist ein Service, der durch solche Coprozessoren ausgeführt wird. Die Software und der verschlüsselte Dechiffrierschlüssel (EAK) können einer Information zugeordnet werden, die ein Übertragungstoken (TOKEN DATA) beschreibt, indem diese Beschreibung unter dem AK verschlüsselt wird. Der Zusammenhang zwischen dem Inhalt des Tokens und den Tokendaten (nach Verschlüsselung unter AK) zeigt dem Coprozessor an, daß dieser spezielle AK zur zukünftigen Benutzung gespeichert werden darf. Dem befugten Benutzer wird ein Token bereitgestellt, welches in einer bevorzugten Ausführungsform in Form einer Hardwarekassette implementiert ist. Das Übertragungstoken ist physisch und logisch gesichert, so daß ein ausreichender Teil seines Informationsgehaltes dem Benutzer nicht zugängig ist. Das Übertragungstoken oder die Hardwarekassette, die das Übertragungstoken enthält, besitzt als Charakteristikum die Eigenschaft, daß die Information nur einmal zu lesen ist, wobei der Inhalt beim ersten Lesen der Hardwarekassette verändert wird, so daß die Befugnis, welche durch die Hardwarekassette repräsentiert wird, durch den Benutzer tatsächlich nicht wiederverwendet werden kann. Dem Benutzer wird ebenfalls ein physisch und logisch sicherer Coprozessor bereitgestellt. Der physisch und logisch sichere Coprozessor hat in einem nichtflüchtiger Speicher den (die) Dechiffrierschlüssel des Hardwareverkäufers CSK1, CSK2 usw. Die das Token beschreibenden Daten werden typischerweise mit der Software übertragen.
Wenn der Benutzer das erste Mal versucht, die geschützte Software zu benutzen, koppelt er den physisch und logisch sicheren Coprozessor mit dem Computersystem, auf welchem die geschützte Software laufen soll und koppelt ebenfalls die Hardwarekassette, die das Übertragungstoken enthält, mit dem Computersystem.
Beim ersten Lauf der Software wird der verschlüsselte Softwareschlüssel EAK zum Coprozessor übertragen und wird vom Coprozessor unter Verwendung des erforderlichen CSK entschlüsselt, um damit den AK zu erhalten. Aus Gründen, welche unten beschrieben werden, ist diese Übertragung temporär, der Coprozessor wird diese Übertragung zurückweisen, wenn die unten beschriebenen Bedingungen nicht erfüllt sind. Ein überprüfbarer Abschnitt des Inhalts der Hardwarekassette, d.h. das Übertragungstoken, wird unter Verwendung eines gegen Fälschung widerstandsfähigen Frage/Antwort-Protokolls ebenfalls zum Coprozessor übertragen; dieser Prozeß verändert oder zerstört die Inhalte der Hardwarekassette. Die einem Beobachter der Frage und der Antwort enthüllte Information ist jedoch nicht ausreichend, um einem Fälscher zu erlauben, eine korrekte Antwort auf eine andere Coprozessor-Anfrage zu entwerfen. Das Übertragungstoken kann durch einen Softwareautor mit Information "neugefüllt" werden, jedoch wird das neugefüllte Übertragungstoken einen Coprozessor nur dazu ermächtigen, einen AK von diesem Autor zu akzeptieren. Der physisch und logisch sichere Coprozessor, bestimmt ob das Übertragungstoken wirksam wird oder nicht, indem er feststellt, ob es einem erwarteten Übertragungstoken entspricht oder nicht. Nehmen wir an, das Token wird als akzeptierbar erkannt, dann speichert der Coprozessor den Software-Dechiffrierschlüssel AK in seinem Festspeicher. An diesem Punkt bewirkt die Übertragung, daß der Coprozessor den AK verwenden kann, um die geschützte Software zu entschlüsseln und auszuführen.
Wenn der Software-Dechiffrierschlüssel AK einmal in dem Festspeicher des Coprozessors gespeichert ist, kann die geschützte Software ausgeführt werden. Der Klartext-Abschnitt der geschützten Software wird durch das Computersystem des Benutzers ausgeführt. Der verschlüsselte Abschnitt (der geschützte Abschnitt) der Software wird beim Laden durch den Coprozessor entschlüsselt. Die logische und physische Sicherheit des Coprozessorspeichers verhindert, daß der Benutzer Zugriff auf die Klartextoder ausführbare Form der geschützten Software hat.
Bei jeder folgenden Benutzung der geschützten Software wird der Software-Dechiffrierschlüssel AK, der jetzt in dem Festspeicher des Coprozessors gespeichert ist, dazu verwendet, die verschlüsselten Abschnitte davon zu entschlüsseln. Der Benutzer kann so viele Sicherungskopien der Software anfertigen, wie er möchte; ohne Zugriff auf einen physisch und logisch sicheren Coprozessor, der den Dechiffrierschlüssel AK speichert, ist jedoch jede Sicherungskopie unbenutzbar, weil der verschlüsselte Abschnitt der Software nicht entschlüsselt werden kann.
In Verbindung mit der Ausführung der verschlüsselten Software durch den besagten Coprozessor, wird der befugte Prozessor die verbleibenden Abschnitte, d.h. die ursprünglich unverschlüsselten Abschnitte, ausführen.
Das getrennte Recht-auf-Ausführung umfaßt in einer bevorzugten Ausführungsform einen Dechiffrierschlüssel für die verschlüsselten Abschnitte der Software. Solange der Dechiffrierschlüssel mit der Software zusammen vertrieben werden kann, wird er in verschlüsselter Form vertrieben. Der Coprozessor wird bei seiner Herstellung mit dem Schlüssel (CSK) versehen, der erforderlich ist, um den Software-Dechiffrierschlüssel zu entschlüsseln. Ohne weiteren Schutz würde dies jedoch jeden Coprozessor ermächtigen, jede Software laufen zu lassen, die entsprechend der vorhergehenden Beschreibung vertrieben wurde. Dies würde den Ansprüchen der Softwareautoren nicht gerecht werden. Deshalb benötigt der Coprozessor weitere Beweismittel für das Recht-auf-Ausführung des Benutzers. Dieses Beweismittel hat die Form einer authentischen (unbenutzten) Hardwarekassette. Wenn und nur dann wenn die Hardwarekassette die Anforderungen des Coprozessors erfüllt, wird der Software-Dechiffrierschlüssel funktionsfähig gemacht. Der Coprozessor hat (über einen von verschiedenen alternativen Wegen) Informationen zur Verfügung, die als Tokendaten bezeichnet werden. Diese Tokendaten können mit dem Coprozessor in verschlüsselter Form verbunden werden, so daß der Weg, über den die verschlüsselten Tokendaten dem Coprozessor zugängig gemacht werden, nicht sicher sein muß. Die Tokendaten sind unter Verwendung desselben Software-Dechiffrierschlüssels verschlüsselt worden. Die Kassette speichert die Tokendaten in Klartextform und folglich muß die Hardwarekassette physisch und logisch sicher sein. Der Zugriff des Coprozessors auf die Hardwarekassette erfolgt in Form einer Anfrage. Die Hardwarekassette reagiert auf die Anfrage durch Rücksenden einer Antwort, welche eine Funktion sowohl der Anfrage als auch der Tokendaten ist. Diese Funktion offenbart über die Tokendaten nicht genug, daß es möglich wäre, das Verhalten eines unbenutzten Tokens zu reproduzieren. Ein Beispiel für eine solche Funktion wäre die Auswahl eines 50%igen Tokeninhalts auf Basis des Inhaltes der Anfrage. Wenn die Hardwarekassette die Antwort erzeugt, werden alle Klartext-Tokendaten, die sie gespeichert hatte, überschrieben oder zerstört. Als ein Ergebnis des Frage/Antwort-Prozesses, empfängt der Coprozessor den ausgewählten Abschnitt oder die Transfomation der Klartext-Tokendaten. Der Prozeß ist so organisiert, daß selbst obwohl der Datenübertragungsweg zwischen dem Coprozessor und der Hardwarekassette nicht sicher ist, irgendeine Überwachung dieses Vorgangs (zum Beispiel das Kopieren der Frage und der Antwort) nur eine ungenügende Information dazu liefern würde, um das Verhalten der Kassette zu simulieren. Wenn auch der Coprozessor nur den ausgewählten Abschnitt oder eine Transformation der Klartext-Tokendaten empfängt, verfügt der Coprozessor über alle Informationen, die er benötigt, um festzustellen, ob die Antwort eine authentische Kassette identifiziert, weil der Coprozessor sowohl die Anfrage als auch die kompletten Klartext-Tokendaten zur Verfügung hat (da er die verschlüsselten Tokendaten entschlüsselt hat).
Der Datenübertragungsweg zwischen dem Coprozessor und der Hardwarekassette kann entweder direkt (durch Koppeln der Hardwarekassette an eine Schnittstelle im Coprozessor) oder indirekt über den Wirtsrechner oder den zu autorisierenden Prozessor verlaufen.
Ein bevorzugtes Beispiel einer geeigneten Anfrage ist eine Zufallszahl einer bestimmten Bitlänge. Die Anfrage wird in die Hardwarekassette eingegeben und dazu verwendet, unter verschiedenen und exklusiven Abschnitten der Klartext-Tokendaten, wie sie in der Hardwarekassette gespeichert sind, eine Auswahl vorzunehmen. In einem einfachen Beispiel kann die Anfrage binär sein, so daß, wenn die Klartext-Tokendaten in zwei Abschnitte unterteilt werden, jedes Bit der Anfrage verwendet werden kann, ein Bit aus dem ersten oder zweiten Abschnitt auszuwählen. Ein ausgewähltes Bit bildet ein Bit der Antwort und gleichzeitig werden die ausgewählten und nicht ausgewählten Bits überschrieben oder anderweitig gelöscht. In diesem Beispiel ist dann die Bitlänge der Anfrage gleich der halben Bitlänge der Klartext-Tokendaten. Weil der Datenübertragungsweg zwischen dem Coprozessor und der Hardwarekassette ungesichert ist, wird angenommen, daß ein Hacker in der Lage sein wird, die Anfrage und die Antwort zu kopieren. Aber der Hacker ist unmöglich in der Lage, die Anfrage, die ein anderer Coprozessor erzeugen wird, zu steuern und deshalb ist die Antwort, die er kennt, auch nicht ausreichend, ihn in die Lage zu versetzen, den Effekt einer authentischen Hardwarekassette zu simulieren.
Die Software, der zugeordnete verschlüsselte Dechiffrierschlüssel EAK und die Information, die das autorisierte Übertragungstoken betrifft, kann auf einem magnetischen Medium (Diskette oder Band) bereitgestellt werden. Alternativ dazu kann diese Information über eine Nachrichtenverbindung (Telephonleitung, CATV usw.) geliefert werden. Der Coprozessor, der entsprechend des Verfahrens verwendet wird, muß nicht ständig in das Computersystem des Benutzer eingebunden oder daran über Leitungen angeschlossen sein. Um jedoch die geschützte Software auf dem Computersystem ausführen zu können, muß das Computersystem in der Lage sein, mit dem Coprozessor in Verbindung zu treten. Wenn der Coprozessor den Software-Dechiffrierschlüssel (AK) nicht gespeichert hat, muß der Coprozessor ebenfalls mit einem Übertragungstoken verbunden sein, so daß der Dechiffrierschlüssel AK durch den Coprozessor akzeptiert werden kann. Die Hardwarekassette, die das Übertragungstoken enthält, ist so organisiert, daß sie in der Lage ist, eine geeignete Übertragung eines Dechiffrierschlüssel AK einmal und nur ein einziges Mal zu autorisieren. Das stellt sicher, daß der Benutzer den Software-Dechiffrierschlüssel AK auf einen einzelnen Coprozessor übertragen kann. Obwohl der Benutzer das Softwaremedium frei kopieren kann, kann das geschützte Programm nur im Zusammenwirken mit einem Coprozessor ausgeführt werden, der den Software-Dechiffrierschlüssel enthält. Weil der Coprozessor physisch und logisch sicher ist, kann der gespeicherte Software-Dechiffrierschlüssel nicht kopiert werden. Weil die Hardwarekassette, die das Übertragungstoken enthält sowohl physisch als auch logisch sicher ist, kann sie nicht kopiert werden und weil der Vorgang der Übertragung des Software-Chiffrierschlüssels bewirkt, daß der Informationsgehalt des Tokens verändert oder zerstört wird, kann dieser Prozeß nur einmal ausgeführt werden.
Wie oben beschrieben enthält das Software-Verteilungsmedium Informationen, die das Token beschreiben. Diese Informationen sind verschlüsselt, um sie vor Offenlegung gegenüber unautorisierten Quellen zu schützen. Wie weiter unten beschrieben werden wird, ist es jedoch überhaupt nicht von Wichtigkeit, daß die verschlüsselte Tokenbeschreibung auf dem Softwareverteilungsmedium mit enthalten oder diesem zugeordnet ist. Es ist ein Vorteil, wenn alle Token einmalig sind. Wenn eine einmalige Tokenbeschreibung auf jedem Softwareverteilungsmedium enthalten ist, erfordert dies daß jedes Softwareverteilungsmedium einmalig ist. Es wäre vorteilhafter, wenn alle Softwareverteilungsmedien identisch sein könnten, weil dies die Herstellungskosten minimiert. Dies kann erreicht werden, indem die Hardwarekassette mit den Mitteln ausgestattet wird, um die verschlüsselten Tokendaten zu speichern. Alle einmaligen Informationen können somit auf die Hardwarekassette isoliert werden.
Wie unten beschrieben werden wird, verändert sich das auszuführende Protokoll in Abhängigkeit von der Tatsache, ob die verschlüsselten Tokendaten dem Softwareverteilungsmedium zugeordnet sind oder ob die Hardwarekassette die Klartext-Tokendaten enthält.
In dem einen Fall, wird das Token durch den Coprozessor auf eine solche Weise überprüft, daß der Prüfprozeß (obwohl über ungesicherte Leitungen ausgeführt) nicht genügend Tokendaten offenbart, um die Befugnis, welche das Token repräsentiert, erfolgreich fälschen zu können. Um diesen Prozeß zu implementieren, wird eine Zufallszahl durch den Coprozessor erzeugt (und für zukünftige Verwendung aufbewahrt). Die Zufallszahl wird dazu verwendet, das Token abzufragen, welches an den Coprozessor den Abschnitt der Tokendaten zurückgibt, der durch die Zufallszahl ausgewählt wird. In der Kassette werden sowohl die Tokendaten, die ausgewählt wurden (und zum Coprozessor übertragen werden) als auch die Tokendaten, die nicht ausgewählt wurden, zerstört. Selbst wenn die Antwort der Hardwarekassette durch unbefugte Personen aufgezeichnet wird, ist sie auf diese Weise nutzlos, außer in der wenig wahrscheinlichen Situation, in der der Coprozessor die identische Zufallszahl erzeugt oder wenn der Fälscher die erwartete Antwort errät.
Damit ein Fälscher einen anderen Coprozessor dadurch irreführen kann, daß er diesen Coprozessor mit einer gefälschten Antwort auf dessen Zufallszahl-Anfrage konfrontiert, muß die zweite Anfrage entweder mit der ersten identisch sein oder der Fälscher muß die richtige Antwort auf die neue Anfrage erraten. Die Wahrscheinlichkeit für diese beiden Fälle kann dadurch herabgesetzt werden, daß längere Anfragen verwendet werden. Indem eine gute Zufallszahlerzeugung mit ausreichend langen Anfragen an und Antworten von dem Token kombiniert wird, kann der Job des Fälschens beliebig erschwert werden.
Der Coprozessor akzeptiert den verschlüsselten Softwareschlüssel EAK entweder von der Tokenkassette oder von dem Softwareverteilungsmedium (bevorzugt) und entschlüsselt ihn unter Verwendung eines Coprozessor-Steuerprogrammschlüssels CSK, der im Coprozessor zum Zeitpunkt seiner Herstellung gespeichert wird.
Der Coprozessor akzeptiert dann die verschlüsselten Tokendaten (entweder von der Tokenkassette oder vom Softwareverteilungsmedium) und entschlüsselt die Tokendaten unter Verwendung des entschlüsselten Softwareschlüssels AK. Dann kann der Coprozessor die Zufallszahl und die Klartext-Tokendaten kombinieren, um die richtige Antwort der Hardwarekassette auf seine Zufallszahl-Anfrage zu bestimmen. Die richtige Antwort, die vom Coprozessor berechnet wurde, kann dann mit der tatsächlichen Antwort der Hardwarekassette verglichen werden. Wenn der Vergleich positiv ausfällt, ist die Befugnis des Benutzers, den Schlüssel AK zu verwenden, festgestellt. Diese Verwendung umfaßt jedoch nicht die Möglichkeit den tatsächlichen Inhalt des AK zu bestimmen.
Im Fall, daß die verschlüsselten Tokendaten nicht dem Softwareverteilungsmedium zugeordnet sind, können diese anstatt dessen in einem speziellen Register in der Hardwarekassette gespeichert werden. Die Klartext-Tokendaten werden ihm einem spezialisierten Registersatz gespeichert, welcher beim Lesen nur einen Abschnitt der gespeicherten Information bereitstellt, wobei die bereitgestellte Information durch die Antwort der gelesenen Teile des Tokens auf Basis der auswählenden Zufallszahl ausgewählt wird. Diese Teile können weiterhin die ausgewählte Information transformieren, indem der Teil der gespeicherten Information, der nicht ausgewählt wurde, dazu verwendet wird. Bevor oder nachdem der Coprozessor die Anfrage an die Hardwarekassette abgesetzt und deren Antwort (die Kombination der Zufallszahl und der Klartext-Tokendaten) empfangen hat, kann er fortfahren, die Hardwarekassette abzufragen und somit die verschlüsselten Tokendaten auszulesen. Dies bedeutet natürlich, daß die verschlüsselte Form der Tokendaten dem Benutzer (und jeder unbefugten Person) zugängig wird. Aber dies untergräbt die Sicherheit nicht mehr, als wenn die verschlüsselten Tokendaten auf dem Softwareverteilungsmedium stehen, wo sie ebenfalls dem Benutzer und jeder unbefugten Person zugängig sind. Es sollte beachtet werden, daß das Token keine Chiffrierschlüssel enthält. Wenn der Coprozessor als ein vertrauter Empfänger einer geheimen Information (AKs) betrachtet wird, dann kann das Token mit einem Wachssiegel auf einem Umschlag gleichgesetzt werden, das dem Empfänger die Sicherheit gibt, daß kein anderer Empfänger die Nachricht (einen AK) erhalten hat. Das Token verschafft somit dem Softwarehändler die Kontrolle über die Gesamtzahl der Coprozessoren, die in der Lage sind, ihre Software abzuarbeiten. Diese Kontrollmöglichkeit ist es, was heute fehlt und wodurch die Softwarepiraterie ermöglicht wird.
Es sollte klar sein, daß die Lösung dieses Systems für das Problem der Softwarepiraterie darauf beruht, daß sowohl der Personalcomputer als auch die Disketten durch Hinzufügen von Hardwarekomponenten verbessert werden, welche einen Ausgleich für die Offenlegungen, die die Piraterie erlauben, schaffen. Im Fall des Personalcomputers beinhaltet diese Offenlegung, daß der Benutzer die Möglichkeit hat, den kompletten Adreß- und Registerbereich des Computersystems zu untersuchen und mit Kommandos darauf zuzugreifen. Im Fall der Diskette (oder jedes anderen Verteilungs- oder Speichermediums) ist dies die Tatsache, daß eine funktionelle Reproduktion der Medien hergestellt werden kann. Es ist möglich, die Verbesserungen in einer Weise zu beschreiben, welche die Anwendbarkeit dieses Systems auf andere Computersysteme als Personalcomputer klarer macht.
Der Offenheit existierender Computersysteme wird durch Hinzufügen eines Coprozessorsystems Rechnung getragen. Dieses System wird benötigt, um zwei privilegierte Ebenen über der des Systembenutzers zu implementieren. Dies ist selbst in dem Fall notwendig, in dem das Computersystem eine CPU besitzt, welche privilegierte Ebenen hat. In einem solchen System sind noch einzelne Benutzer für das Laden des Betriebssystems verantwortlich und diese könnten ein Betriebssystem erstellen, welches ihren Zugriff auf geschützte Abschnitte des Händlercodes unterstützt. Selbst wenn das Betriebssystem in ROMs in der CPU eingebrannt ist, würde dem Benutzer der physische Zugriff auf den geschützten Code nicht verwehrt werden.
Die Struktur privilegierter Ebenen, die durch dieses Problem diktiert wird, ist folglich eine Verzweigung von einer beliebigen vorhandenen Struktur. Diese Verzweigung umfaßt zwei Ebenen, die tatsächlich parallel wirken und von der existierenden Struktur getrennt sind. Diese zwei privilegierten Ebenen, welche durch den Coprozessor dem Computer hinzugefügt werden (oder die auf geeignete Weise in den Aufbau des Computersystems hineinkonstruiert sind), haben unterschiedliche Funktionen. Die untere der beiden Ebenen stellt einen Bereich zur Verfügung, in welchem ein Abschnitt des Händlercodes als Service ausgeführt wird und zwar für den Teil des Händlercodes, der in dem offenen Speicher des Wirtsrechners läuft. Die höhere privilegierte Ebene in dieser Verzweigung wird dazu verwendet, das Sicherungsprotokoll, welches bei Installation oder Benutzung die Verbreitung des Rechts-auf-Ausführung verhindert, auszuführen. Dieses Protokoll ist als ein Service für die niedrigere privilegierte Ebene oder den Wirtsrechner verfügbar.
Diese Architekturerweiterung bestehender Computersysteme stellt eine Unterstützung für allgemeine Sicherheitsfunktionen in der Datenverarbeitung bereit, indem Mittel zur Verfügung gestellt werden, über die eine vertrauenswürdige Ausführung von Software gewährleistet wird. Die veränderte privilegierte Struktur stellt einen Ausführungsbereich bereit, in welchem der Softwarelieferant ein höheres Privileg besitzt als der Systembenutzer. Diese privilegierte Ebene ist parallel zum, aber getrennt vom Systembediener. Auf dieser privilegierten Ebene kann der Softwarelieferant sein Produkt als Service für den Benutzer ausführen lassen, ohne daß er den Zugriff auf dieses als ein Softwareobjekt freigibt. Diese Software ist dann in dem Sinn vertrauenswürdig, daß sie nur als Service verwendet, aber nicht durch den Benutzer verändert oder beobachtet werden kann. Der Nutzen derart vertrauenswürdiger Softwareausführung ist für den Fachmann auf dem Gebiet der Systemsicherheit klar erkennbar.
Eine zweite privilegierte Ebene wird als Teil dieser Struktur privilegierter Ebenen bereitgestellt. Es liegt in der Verantwortung dieser privilegierten Ebene, die Operationen zu steuern, die erforderlich sind, damit das Softwareprodukt ausgeführt werden kann. Diese privilegierte Ebene ist in dem Sinn vertrauenswürdig, daß sie nur dann die Ausführung von Code gestattet, wenn der Softwarelieferant das Recht zu Ausführung erteilt hat. Diese privilegierte Ebene hat zusätzlich die Aufgabe, Anwendungen, die in der niedrigeren Ebene abgearbeitet werden, in dem Fall voneinander zu trennen, wenn mehrere Programme darin ausgeführt werden. Dies ist eine klassische Betriebssystemfunktion und sie ist notwendig, um den auf der unteren Ebene ausgeführten Code vertrauenswürdig zu halten.
Dementsprechend stellt die vorliegende Erfindung ein Verfahren zur Sicherung geschützter Software gegen unbefugte Benutzung bereit, ohne daß existierende Vertriebskanäle für die Software zerstört werden und gleichzeitig ohne daß die unbeschränkte Herstellung von Sicherungskopien der geschützten Software durch den Benutzer gestört wird, wobei das Verfahren die Schritte umfaßt:
a) Bereitstellen eines physisch sicheren Coprozessors und Koppeln des Coprozessors mit einem Wirtsrechner (host) des Benutzers, um zwischen diesen Computern einen bidirektionalen Informationsaustausch mit dem Ziel zu unterhalten, ein zusammengesetztes Datenverarbeitungssystem zu erzeugen, das den Wirtsrechner und den Coprozessor umfaßt; b) Bereitstellen logischer Sicherheitsvorkehrungen für den Coprozessor durch: 1) Bereitstellen einer ersten privilegierten Ebene, die einen sicheren Speicher der ersten Ebene und Operationsbefehle der ersten Ebene enthält, welche gegen Zugriff und Veränderung durch den Benutzer gesichert sind zur Ausführung der geschützten Software; c) Vertrieb der geschützten Software in einer Form, in welcher zumindest ein Teil durch den Wirtsrechner unausführbar ist; d) Vertrieb eines weiteren greifbaren Elementes getrennt von der geschützten Software, repräsentierend das Recht zur Ausführung der geschützten Software; e) Herstellung des Zugriffs des zusammengesetzten Datenverarbeitungssystems auf die geschützte Software und auf das weitere greifbare Element; dadurch gekennzeichnet, daß: Schritt b) weiterhin den Schritt umfaßt: 2) Bereitstellen einer zweiten privilegierten Ebene zur Überwachung des Befugnisses zur Ausführung der geschützten Software durch die erste privilegierte Ebene, enthaltend einen sicheren Speicher der zweiten Ebene und Operationsbefehle der zweiten Ebene welche gegen Zugriff und Veränderung durch den Benutzer oder irgendeinen Autor von geschützter Software gesichert sind; weiterhin dadurch gekennzeichnet, daß die geschützte Software, wie sie entsprechend Schritt c) vertrieben wird, durch den Coprozessor ausführbar ist, aber nur über die Ermächtigung durch die zweite privilegierte Ebene; und dadurch gekennzeichnet, daß das Verfahren desweiteren die Schritte umfaßt: f) Überprüfen der Authentizität des weiteren greifbaren Elementes durch den Coprozessor auf der zweiten privilegierten Ebene; g) Veränderung des sicheren Speichers der zweiten Ebene auf eine besondere Weise, damit eine Feststellung der Authentizität des greifbaren Elementes durch die zweite privilegierte Ebene wiedergegeben wird und h) Ausführung der geschützten Software solange, wie die Anderung des sicheren Speichers der zweiten privilegierten Ebene erkannt wird und Verneinen einer entsprechenden Anforderung, denn diese Anderung nicht vorhanden ist.
Aus dem Vorstehenden sollte deutlich geworden sein, daß die erste privilegierte Ebene die Aufgabe hat, die geschützte Software als Service für den Softwarehändler und den Benutzer auszuführen, aber die Software vor dem Zugriff durch den Benutzer zu schützen. Die zweite privilegierte Ebene enthält die Chiffrierschlüssel-Organisationsfunktionen bezüglich des Erwerbs des Rechts auf Ausführung und wenn dies einmal erworben ist, bezüglich des Kopierens des benötigten Dechiffrierschlüssels in den sicheren Speicherbereich (zweite privilegierte Ebene) des Coprozessors. Natürlich ist die Software, so wie sie vertrieben wird, durch den Wirtsrechner unausführbar, weil mindestens ein Abschnitt verschlüsselt ist. Die Software ist durch den Coprozessor ausführbar, wenn er einmal dazu die Befugnis durch die zweite privilegierte Ebene erhalten hat. Das weitere greifbare Element ist die Hardwarekassette, die das Übertragungstoken speichert. Die Art und Weise, auf die der Coprozessor die Authentizität des Übertragungstokens überprüft, ist schon detailliert beschrieben worden. Die Veränderung des sicheren Speichers der zweiten privilegierten Ebene besteht darin, daß der Software-Dechiffrierschlüssel dort eingeschrieben wird. Wann auch immer die Ausführung der geschützten Software durch den Benutzer angefordert wird, wird über die zweite privilegierte Ebene ein Zugriff auf den sicheren Speicherbereich ausgeführt, um zu bestimmen, ob der passende Software-Dechiffrierschlüssel vorhanden ist. Wenn dieser vorhanden ist, initiiert der Coprozessor die Entschlüsselung der geschützten Software und das Speichern dieser Software in dem sicheren Speicherbereich der ersten privilegierten Ebene des Coprozessors. Nachfolgend erteilt die zweite privilegierte Ebene die Befugnis zur Ausführung durch die erste privilegierte Ebene. Wenn der benötigte Software-Dechiffrierschlüssel nicht vorhanden ist, wird die Benutzerforderung nach Ausführung der Software abgelehnt.

Kurze Beschreibung der Zeichnungen

Die vorliegende Erfindung wird im Zusammenhang mit den anliegenden Zeichnungen, in welchen gleiche Bezugszeichen identische Vorrichtungen identifizieren, so detailliert beschrieben werden, daß es einem Fachmann ermöglicht wird, diese zu realisieren. Bezüglich der Zeichnungen gilt:
Figur 1 ist ein Blockschaltbild, das die Hauptkomponenten des Wirtsrechners 10 und des Coprozessors 15 zeigt;
Figur 2 ist ein Blockschaltbild der Hardwarekassette 20 und deren Verbindung mit einem geeigneten Verbinder 23, entweder von der Ein-/Ausgabe-Schnittstelle 154 des Coprozessors oder von der Ein-/Ausgabe-Schnittstelle 19 des Wirtsrechners 10;
Figur 3 illustriert die Komponenten eines vertriebsfähigen Softwaresatzes entsprechend einer Ausführungsform der vorliegenden Erfindung;
Figur 4 zeigt, wie die vertriebsfähigen Komponenten durch den Softwarehändler erzeugt werden;
Figur 5 zeigt auf schematische Weise die Wechselwirkungen zwischen dem zusammengesetzten Datenverarbeitungssystem, bestehend aus dem Wirtsrechner 10 und dem Coprozessor 15 sowie dem zu vertreibenden Softwarepaket, bestehend aus der Tokenkassette und dem vertriebsfähigen Softwaresatz (Figur 3> während des Prozesses der Erlangung des Rechts-auf-Ausführung;
Figur 6 gleicht Figur 5 mit dem Unterschied, daß die Wechselwirkung der oben erwähnten Komponenten in einem Stadium nach dem Prozeß der Erlangung des Rechts-auf-Ausführung, d.h. während des Ladens, Entschlüsselns und des Softwarelaufs gezeigt werden;
Figur 7 ist ein Flußdiagramm, das die Servicefunktionen im Wirtsrechner entsprechend der Erfindung zeigt;
Figur 8 ist ein Flußdiagramm des Prozesses der Erlangung das Rechts-auf-Ausführung, der im Coprozessor 15 ausgeführt wird;
Figur 9A zeigt die Servicefunktionen, die im Wirtsrechner 10 bei einem Lade-, Entschlüsselungs- und Ausführungsprozeß ausgeführt werden, und
Figur 9B zeigt die entsprechenden Service funktionen, die im Coprozessor in Verbindung dem Lade-, Entschlüsselungs- und Ausführungsprozeß ausgeführt werden.

Detaillierte Beschreibung bevorzugter Ausführungsformen

Wie in der oben zitierten EP-A-0 174 472 beschrieben, kann der Begriff Personalcomputer oder Einzel-Benutzer-System für individuelle Datenstationen, wie er auf eine Klasse kleinerer Computer angewandt wird, irreführend sein. Diese Systeme werden geeigneter als Einzel-Bediener-Systeme bezeichnet. Aus dem Blickwinkel klassischer Betriebssysteme stellt dies den Benutzer-Bediener in eine Vertrauensstellung, in welcher er Zugriff auf den gesamten Systemcode und die Systemeinrichtungen hat. In gewöhnlichen Einzel-Bediener-Systemen gibt diese Offenlegung des Systemcodes und der Hardware-Systemeinrichtungen die Möglichkeit, Code zu duplizieren und weiter zu verbreiten, was bei klassischen großen Computersystemen mit separaten Bedienern und Benutzern unmöglich wäre. Die Mittel, durch welche diese Sicherheit bei großen Systemen erreicht wird, sind die Implementierung eines Systems, in welchem den Benutzern eine privilegierte Statusebene zugewiesen wird, welche durch das System geprüft und damit festgestellt wird, ob der Benutzer bestimmte Befehle oder Zugriffe auf bestimmte Daten zum Lesen oder Modifizieren ausführen darf oder nicht.
Gemeinsam mit einem Zweck der Erfindung der oben zitierten EP-A-0 174 472 ist es der Zweck der vorliegenden Erfindung, mitzuteilen, wie ein System unter Benutzung privilegierter Ebenen auf einem Einzel-Bediener-System zum Vorteil des Hardwareherstellers, des Softwarehändlers und des vorsichtigen Einzel-Bediener-System-Benutzers implementiert werden kann. Dies wird als "Shared Higher Level of Privilege System" (System geteilter höherer privilegierter Ebenen> bezeichnet, weil man es derart betrachten kann, daß jedem Softwarehändler eine höhere privilegierte Ebene bereitgestellt wird als dem Benutzer, ohne daß ein Händler Zugriff auf die privilegierten Informationen eines anderen Händlers erhält. Bei Verwendung dieses Systems ist ein Teil der Hardware und der Software dieses Systems in einem Coprozessor-Subsystem versteckt, welches in dem Einzel-Bediener-System (auch als Wirtsrechner (host) oder Datenstation bezeichnet) installiert oder mit diesem verbunden ist, so daß einzelne Teile der Händlersoftware für den Benutzer unzugängig gemacht werden können, außer, daß sie als Service (Dienst) nutzbar sind. Zusätzlich gestattet das Verfahren des Softwaretransports entweder auf magnetischen Medien (Diskette oder Band) oder über Nachrichtenverbindung dem Softwarehändler manche Teile der Software in verschlüsselter Form vor dem Benutzer zu verbergen, ungeachtet dessen, daß der Benutzer mit den ihm auf dem System zur Verfügung stehenden Ressourcen in der Lage ist, die Software zu untersuchen.
Zum Zweck dieser Beschreibung wird angenommen, daß die Wirtsrechner-Hardware oder Datenstation ein IBM Personalcomputer (PC) ist, dessen Arbeitsweise in dem IBM Personal Computer technical reference manual, 1981 beschrieben ist. Weiterhin wird angenommen, daß das Plattenspeicher-Betriebssystem (DOS - Disk Operating System) ein IBM PC DOS sei. Diese Voraussetzungen werden gemacht, um Klarheit zu schaffen, weil die Arbeitsweise von DOS-Diensten in dieser Kombination für eine Maschinenklasse typisch ist, für welche die vorliegende Erfindung nützlich ist. Es sollte klar sein, daß DOS und die Hardwareoperationen als repräsentativ für alle analogen Operationen auf diesen oder anderen Wirtsrechnersystemen (einschließlich Großrechner) unter diesem oder anderen Betriebssystemen angesehen werden sollen.
Ein Software-Kopierschutzsystem entsprechend der vorliegenden Erfindung unter Verwendung geteilter höherer privilegierter Ebenen setzt sich aus zwei Teilen zusammen, aus dem Hardware-Unterstützungssystem für die privilegierten Ebenen (einem Coprozessor), welches in der Datenstation installiert oder mit dieser gekoppelt ist sowie aus dem Medium (magnetisch oder andersartig), welches verwendet wird, um die Software vom Händler zum Benutzer zu transportieren. Wie beschrieben werden wird, macht die Form, in der die Software weitergeleitet wird, es einfach, Sicherungskopien zu erstellen. Um jedoch eine zukünftige Zusammenarbeit mit einem Coprozessor bei der Ausführung der Software zu gewährleisten, muß die Software bei ihrer ersten Benutzung dem Coprozessor zusammen mit einem Token angeboten werden. Die Tokenkassette kann effektiv nur einmal verwendet werden und ist gegen Fälschungen sehr widerstandsfähig. Kopien des magnetischen Mediums sind für die Weitergabe der Möglichkeit, das Softwarepaket zu benutzen, nutzlos. Die Befugnis, einen Dechiffrierschlüssel AK zu akzeptieren, erhält der Coprozessor durch die Verwendung eines Tokens, so daß die Software auf dem PC (oder Wirtsrechner) in Verbindung mit diesem speziellen Coprozessor ausgeführt werden kann. Andere Coprozessoren, die dazu autorisiert worden sind, denselben Schlüssel zu benutzen, können ebenfalls die Software ausführen. Wenn die Tokenkassette benutzt wird, wird sie für die Übertragung weiterer Benutzungsbefugnisse unbrauchbar gemacht. Der Softwarehändler wird somit in die Lage versetzt, die Anzahl der autorisierten Systeme zu kontrollieren, ohne daß er mit den Systemen in Verbindung treten muß.
Die Anwendungssoftware muß aus mindestens einer Datei eines verschlüsselten Programms bestehen. Dieser Teil der Anwendungssoftware ist mit einem Chiffrierschlüssel (AK) verschlüsselt worden, der von dem Softwarehändler bereitgestellt wird. Der Softwareschlüssel (AK) wird in verschlüsselter Form (EAK) geliefert, verschlüsselt mit einem Schlüssel (CSK), der nur dem Hardwareverkäufer bekannt ist. Der Dechiffrierschlüssel (CSK) für diesen verschlüsselten Softwareschlüssel EAK wird vom Hardwareverkäufer im sicheren Speicher des Coprozessors mitgeliefert. Die Chiffrierung eines AK zur Erzeugung eines EAK wird auf solche Weise durchgeführt, daß der Chiffrierschlüssel (CSk) des Hardwareverkäufers dem Softwarehändler nicht zugängig ist. Es liegt im obersten Interesse des Softwarehändlers, solche Abschnitte der Anwendungssoftware zu verschlüsseln, die er als Eigentum betrachtet, weil es der verschlüsselte Abschnitt der Software ist, der gegen Weiterverbreitung durch den Benutzer geschützt ist.
Im Fall, daß die Software über ein magnetisches Medium (Diskette oder Band) vertrieben wird, kann das zum Verkauf oder zur Freigabe fertige Medium aus folgenden Teilen bestehen (siehe Figur 3):
1. Eine Anwendung, welche aus mindestens einer Datei eines verschlüsselten Programms besteht, verschlüsselt mit einem Schlüssel AK, der vom Softwarehändler ausgewählt wurde.
2. Der Dechiffrierschlüssel AK, der benötigt wird, um die verschlüsselte Software ausführbar zu machen, geliefert in verschlüsselter Form EAK, wobei die Verschlüsselung durch den Chiffrierschlüssel (geheim) des Hardwareverkäufers CSK erfolgt ist.
3. Tokendaten TD, welche in verschlüsselter Form ETD vorliegen, verschlüsselt mit demselben Softwarehändler-Schlüssel (AK), welcher verwendet wird, um den verschlüsselten Abschnitt der Anwendung zu verschlüsseln.
Wie unten beschrieben werden wird, wird die Verschlüsselung des Software-Dechiffrierschlüssels von einem Coprozessor durchgeführt, der in jeder Beziehung mit dem Coprozessor identisch sein kann, der in Verbindung mit dem PC betrieben wird. Wegen der Charakteristik des Coprozessors hat der Softwarehändler, der diese Ausrüstung benutzt, keinen Zugriff auf die darin gespeicherte Information (den Chiffrierschlüssel des Hardwareverkäufers CSK)
Wie unten beschrieben werden wird, kann die Software ebenfalls über Nachrichtenverbindung vertrieben werden so lange das Informationspaket, welches an einen Wirtsrechner gesendet wird, die oben aufgezählten Komponenten enthält.
Es ist ein Charakteristikum der vorliegenden Erfindung, daß das Verfahren durch Duplizieren der Software und den Versuch, die oben aufgezählten Informationen auszuführen, ohne daß der Coprozessor die Befugnis zur Ausführung der Software empfangen hat, nicht überwunden werden kann, egal ob die Information auf einem Wirtsrechner, welcher mit einem Coprozessor gekoppelt ist oder auch nicht gestartet wird.
Wenn ein Hacker Kopien der aufgezählten Informationen anfertigen will, welche auf Systemen laufen, die mit dem Coprozessor gekoppelt sind, muß er irgendwie dafür sorgen, daß eine Übertragung des Software-Dechiffrierschlüssels vom Verteilungsmedium zum Festspeicher des Coprozessors erfolgt. Wie jedoch unten beschrieben werden wird, erfordert diese Übertragung Tokendaten von einer einmal zu verwendenden Hardwarekassette und wie beschrieben werden wird, kann die Hardwarekassette so organisiert werden, daß es beliebig schwierig wird, das Verhalten zu duplizieren oder zu fälschen. In Abwesenheit einer passenden Tokenkassette wird der Coprozessor die Übertragung des AK, welche notwendig ist, um das geschützte Programm laufenzulassen, nicht akzeptieren. Folglich wird die Softwarepiraterie durch Kopieren der vertriebenen Informationen dadurch unterbunden, daß Schwierigkeiten beim Duplizieren oder Fälschen der Tokenkassette bestehen, mittels derer die Autorisierung erfolgt.
Wenn der Hacker eine Kopie der vertriebenen Informationen erstellen will, die auf Systemen ohne den Coprozessor läuft, dann muß er zuerst jene Teile des Anwendungsprogramms entschlüsseln, die verschlüsselt worden sind. Weil zwei Prozessoren in den Systemen arbeiten, die mit einem Coprozessor ausgerüstet sind, ist es möglich, daß die Anwendung so geschrieben ist, daß sie gleichzeitig auf zwei Prozessoren arbeitet oder spezielle Einrichtungen des Coprozessors benutzt. Wenn dies so ist, muß die Anwendung drastisch modifiziert werden, üm lauffähig zu werden. Die Piraterie durch Kopieren einer verschlüsselten Anwendung wird folglich durch die Stärke des Chiffrierverfahrens, das verwendet wird, um die Anwendung unlesbar zu machen, unterbunden. Es ist praktikabel, dies zu einer im wesentlichen unlösbaren Aufgabe zu machen. Selbst wenn es gelingt, könnte die Software noch nutzlos sein, wenn sie nicht so umgeschrieben wird, daß sie ohne Coprozessor laufen kann.
Damit das Kopierschutzsystem wirksam wird, ist es notwendig, daß nicht nur keine Kopie der vertriebenen Informationen erstellt werden kann, welche die Befugnis zum Akzeptieren eines AK auf einem anderen Coprozessor überträgt, sondern auch, daß die Software niemals im Systemspeicher in einer Form steht, die es dem Benutzer gestattet, eine Binärkopie des Systemspeichers mit einer komplett arbeitenden Version der Anwendung zu erstellen, welche in andere Systeme geladen werden könnte.
Es ist ebenfalls wünschenswert, daß der Benutzer in der Lage ist, eine unbegrenzte Anzahl an Sicherungskopien von der Software anzulegen, für welche der Coprozessor des Benutzers autorisiert ist, von denen alle für unbefugte Systeme nutzlos sind.
Dies sind Merkmale des vorliegenden Kopierschutzsystems und sie werden durch den Coprozessor unterstützt. Der Coprozessor ist selbst ein Datenverarbeitungssystem. Er besitzt seinen eigenen Prozessor, Firmware und Festwertspeicher (ROM - read only memory), einen Echtzeittakt und RAM. Er könnte in einem Personalcomputer als Adapterkartensatz installiert werden, der in den Speicher- und Ein-/Ausgabe-Adreßraum abgebildet wird oder er könnte mit einem Personalcomputer über eine Ein-/Ausgabe-Schnittstelle gekoppelt sein. Es sollte beachtet werden, daß es ein Merkmal der vorliegenden Erfindung ist, als Kontrast zu der Erfindung, die in der oben zitierten EP-A-0 174 472 beschrieben wird, daß der Coprozessor portabel ist. Der Coprozessor kommuniziert mit dem PC auf eine von zwei verschiedenen Arten. Wenn der Coprozessor in einem PC direkt installiert ist (beispielsweise als Kartensatz), dann kann er mit dem PC über einen gemeinsamen Speicherbereich und über einen Registersatz, der sich im Schnittstellen-Adreßraum des PC befindet, kommunizieren. In dieser Version ist der gemeinsame Speicher ein Teil des Coprozessors. Der Coprozessor steuert dessen Bustreiber und kann garantieren, daß der gemeinsame Speicher für Leseoperationen vom PC aus unzugängig ist. (Diese Architektur wird in der zitierten EP-A-0 174 472 beschrieben.) Als Alternative kann der Coprozessor mit dem PC über eine Ein-/Ausgabe-Schnittstelle kommunizieren. Unabhängig von der Art und Weise, auf welche solch eine Kommunikation ausgeführt wird, ist es notwendig, daß nur ein Teil des Coprozessorspeichers durch den PC adressierbar ist. Es ist ebenfalls notwendig, daß der Abschnitt des Coprozessorspeichers, der durch den PC nicht adressierbar ist, dem Benutzer physisch unzugängig ist. Es ist dieser Speicher, in welchem der Coprozessor den verschlüsselten Abschnitt der Anwendungssoftware entschlüsseln und abarbeiten wird.
Zusätzlich zu dem Prozessor, dem Speicher (RAM und ROM) und den Registern für die Schnittstellenadressen (wenn vorhanden) besitzt der Coprozessor einen physisch und logisch sicheren Speicherbereich, der ROMs und nicht-flüchtige Speicherelemente (wie beispielsweise batterie-gepufferte CMOS RAM oder EEPROMs) enthält.
Der ROM enthält die System-Firmware. Diese hat den Aufbau eines Monitors (Überwachungsprogramms), dessen Kommandos die Dienste repräsentieren, welche der PC vom Coprozessor anfordern kann. Ein kompletter Satz solcher Dienste würde als Minimalsatz enthalten:
1. Erlangung des Rechts-auf-Ausführung (ARE - acquire right to execute).
2. Laden, Entschlüsseln und Ausführen der Anwendung (LDR - load, decrypt, run)
Der nicht-flüchtige RAM-Speicher wird durch den Coprozessor als sicherer nicht-flüchtiger Speicher verwendet, in welchem die Dechiffrierschlüssel AK1, AK2 usw. oder initialisierte Anwendungen zusammen mit allen CSKs gespeichert werden.
Es sollte verstanden werden, daß der Coprozessor mindestens zwei privilegierte Ebenen besitzen muß, so daß der Speicher, der verwendet wird, um AKs zu speichern, vor dem Benutzer geeignet gesichert werden kann. Das ist erforderlich, weil der Benutzer ein Softwareautor sein könnte. Wenn die Software, die im Namen eines Autors ausgeführt wird, die AKs der anderen Autoren lesen könnte, könnten die Benutzerautoren die AKs anderer Autoren regenerieren und deren geschützte Software entschlüsseln. Es sollte verstanden werden, daß die Organisation der Installation, Verwendung und des Zugriffs auf die AKs wichtige Funktionen höherer privilegierter Ebenen des System sein sollten.
Alle Anwendungssoftware, die auf dem Coprozessor entschlüsselt und ausgeführt wird, befindet sich auf einer niedrigeren privilegierten Ebene als die im ROM befindliche Firmware, die den Zugriff auf den nicht-flüchtigen RAM steuert und die geschützte Software lädt, entschlüsselt und startet.
Wie vorstehenden schon vermerkt wurde, muß der Coprozessor sowohl physisch als auch logisch sicher sein. Diese Sicherheit wird gefordert, um zu verhindern, daß der Benutzer durch Anwendung von Logikanalysatoren oder anderer digitaler Steuer- und Auf zeichnungsgeräte eine Aufzeichnung vom Inhalt des sicheren Speicherbereiches erhalten kann und daraus die AKs oder die entschlüsselte Software. Eine geeignete Kapselung für den Coprozessor wird in der EP-A-0 268 882 der Anmelderin beschrieben, deren Offenbarung durch diese Bezugnahme aufgenommen ist.
Der PC oder die individuelle Datenstation ist ein gewöhnliches Einzel-Bus-Mikroprozessorsystem. Der IBM PC ist für diese Maschinenklasse typisch. Ein solches System benutzt den Bus (welcher ein Feld von Übertragungsleitungen mit in bestimmten Intervallen angeordneten Sockeln sein kann) als Kommunikätionsmedium zwischen logisch separaten Subsystemen. Manche dieser Subsysteme können sich auf demselben Packungselement (in diesem Fall eine gedruckte Leiterplatte, bezeichnet als "System Board") befinden, das den Bus trägt. Subsysteme die für die Funktion des Systems notwendig sind oder die eine Erweiterung der Systemfunktionen bieten, werden so gehandhabt, daß sie über die Sockel an den Bus angeschlossen werden. Es sollte beachtet werden, daß die Komponenten, die ein Subsystem bilden so gefertigt werden können, daß sich Teile des Subsystems auf unterschiedlichen Packungselementen befinden.
Das Komplement zu Subsystemen, welche in Figur 1 in dem als Wirtsrechner bezeichneten Bereich dargestellt sind, der mit 10 gekennzeichnet ist, ist ein Beispiel eines gewöhnlichen, nahezu minimalen PCs. Die PC CPU 4 ist ein einzelner Mikroprozessorchip und eine Gruppe von Unterstützungschips. Die PC CPU 4 wird mit einem periodischen Signal versorgt, als Takt bezeichnet sowie über die Unterstützungschips mit einer Verbindung zum Bus. Der Mikroprozessor ist normalerweise mit mehr Unterstützungsfunktionen ausgerüstet als dieser, aber alle Unterstützungsfunktionen haben das Ziel, einen sich wiederholenden Zyklus von Befehlslesen aus dem Speicher, Datenlesen aus ausgewählten Elementen der Subsysteme (beispielsweise Speicher mit wahlfreiem Zugriff), Ausführung von Befehlen und wenn nötig Speichern der resultierenden Daten in ausgewählten Elementen des Systems auszuführen. Die CPU 4 kann mit einer Unterstützungsfunktion ausgerüstet sein, die als direkter Speicherzugriff (DMA - direct memory access) bezeichnet wird, welche es erlaubt, daß der Mikroprozessor von Aufgaben entlastet wird, die die Bewegung von Daten von einem adressierbaren Element zu einem anderen beinhalten.
Der Mikroprozessor kontrolliert den Typ der auszuführenden Busoperation (Lesen, Speichern usw.) und den Typ des ausgewählten Elementes (RAM, Schnittstellen-Adreßregister usw.) dadurch, welche der Steuerleitungen auf dem Bus aktiviert werden (entsprechend eines Protokolles, bezeichnet als Busdefinition, auf das geeignete Potential gezogen werden). Über diese flittel ist der Mikroprozessor in der Lage, eine Auswahl von Befehlen zu erhalten (als Programm bezeichnet), die Befehle mit einem Satz von Daten auszuführen und zu bewirken, daß die Daten in anderen Elementen des Systems gespeichert werden, um als Folge dessen die Ausführung der Befehle zu verändern.
Der RAM 6 ist ein Subsystem, aus dem die Daten gelesen oder in das sie von der CPU 4 geschrieben werden können. Er ist ein Sub-System, das dazu verwendet wird, Daten und Befehle, welche von anderen Quellen geladen werden, zu speichern. Wenn er einen sinnvollen Inhalt enthält, dann ist dieser Inhalt von der CPU 4 in ihn eingeschrieben worden. Zu dem Zeitpunkt, zu dem der Computer eingeschaltet wird, ist der Inhalt des RAMs 6 für praktische Zwecke bedeutungslos.
Der ROM 8 ist ein Subsystem, aus dem Daten nur gelesen werden können. Er kann eine Sammlung von Programmen enthalten, welche benötigt werden, um einen nützlichen Betrieb des Computers zu starten und die nützlich sind, um die verbleibenden Subsysteme zu steuern.
Die verbleibenden Subsysteme, die Steuereinheit 9 für das Terminal, die Anzeige 11, das manuelle Eingabegerät 13, die Plattenspeicher-Steuereinheit 15, das Plattenlaufwerk 17 und die Ein-/Ausgabe-Schnittstelle 19 können so charakterisiert werden, daß sie sowohl adressierbare Elemente als auch mechanische, optische oder elektromagnetische (oder andere) Elemente haben oder unterstützen, welche die menschlichen Sinne beeinflussen, durch menschliche Aktionen beeinflußt werden oder ein magnetisches Medium manipulieren, um Lese- und Schreiboperationen auszuführen, die das Erzeugen und Erfassen von Grenzen zwischen magnetischen Gebieten auf dem magnetischen Medium beinhalten. Der Inhalt einiger der adressierbaren Elemente steuert die Aktionen der mechanischen, optischen oder elektromagnetischen Elemente und der Inhalt anderer adressierbarer Elemente wird von den mechanischen, optischen oder elektromagnetischen Elementen gesteuert. Folglich ist es dem Computersystem uber diese Mittel möglich, mit dem Benutzer und mit magnetischen und anderen Medien zusammenzuwirken. Das Subsysteml das die für das Zusammenwirken mit dem Benutzer benötigten Elemente zur Verfügung stellt, wird als Terminalsteuerungs-Subsystem bezeichnet. Die allgemeine Form eines Subsystems, das Lese- und Schreiboperationen auf einem magnetischen Medium ermöglicht, wird als Plattensteuerungssystem bezeichnet. Wenn diese Elemente gegeben sind, ist es möglich, die Arbeit solcher Systeme weitläufig zu beschreiben.
Zum Zeitpunkt des Einschaltens führt der Mikroprozessor ein Befehlslesen von einer festen Position des Speichers aus. Diese Adresse wird vom ROM 8 belegt. Der Befehl auf dieser Position ist ein Sprung zu Programmen, die den Zweck haben, das System für die spätere Benutzung zu testen und zu initialisieren. Eines der Systeminitialisierungprogramme bewirkt, daß ein Programm, welches als Disk Operating System (DOS) bezeichnet wird, von der Platte gelesen und ausgeführt wird. Dieses Programm (das DOS) ist in der Lage, Kommandos vom Benutzer durch Verwendung des Terminalsteuerungssystems anzunehmen. Diese Kommandos enthalten die Möglichkeit, zu bewirken, daß ein von dem Benutzer ausgewähltes Programm auf dem System abläuft, indem es dem DOS-Programm den Namen der Datei angibt (unter Verwendung der manuellen Eingabe), in welcher das Programm steht.
Das Komplement zu Subsystem, welche in Figur 1 gezeigt werden, ist ein Beispiel für ein minimales Coprozessorsystem, als 15 gekennzeichnet. Die Elemente der Hardware kann man sich aus zwei Teilen bestehend vorstellen. Ein Teil (bei 154) enthält adressierbare Elemente, welche es der Hardware erlauben, mit dem PC zu kommunizieren, so daß Kommandos und Daten ausgetauscht werden können (vergleichbar zwischen dem Benutzer und dem Wirtsrechnersystem). Die anderen Teile enthalten die Coprozessorelemente CPU 150, RAM 151, ROM 152, Echtzeittaktgeber 156 und nicht-flüchtigen RAM 153, die nicht direkt mit der Kommunikation mit dem PC befaßt sind.
Der nicht-flüchtige RAM 153 kann als EEPROM oder als batteriegepufferter CMOS RAM oder in jeder anderen Technologie, die ein Löschen des Speicherinhaltes ermöglicht, implementiert werden.
Die Kombination der Eigenschaften nicht-flüchtig und löschbar wird dazu benötigt, daß die Softwareschlüssel (AKs) und die Steuerprogrammschlüssel (CSK) des Coprozessors zwischen den Benutzungen des Coprozessors erhalten bleiben, aber in dem Fall gelöscht werden, wenn das Erkennungssystem für physische Eingriffe/Aufschaltungen 155 einen unbefugten Zugriffsversuch erkennt, siehe EP-A-0 268 882 als Beispiel für ein solches System.
Ein Echtzeittakt 156 ist ein Subsystem, welches einen spezialisierten Zähler enthält. Es wird von einer Batterie mit Energie versorgt, typischerweise von derselben Batterie, die verwendet wird, um die nicht-flüchtigen Speicher und den Zugriffsdetektor zu versorgen. Die Batterie versorgt den Zähler und seine Unterstützungschips in dem Zeitabschnitt mit Energie, wenn das Computersystem ausgeschaltet ist. Der Zähler erhöht seine Register in Abhängigkeit von den Taktsignalen, die durch seine Unterstützungschips erzeugt werden, so daß seine Register das Zeitintervall widerspiegeln, seit die Register vom Coprozessorhersteller initialisiert worden sind. Somit würde der Inhalt der Register ungefähr dem Tageszeitverlauffolgen, wenn sie mit der Tageszeit initialisiert worden sind. Die Register des Echtzeittaktes können von der CPU 150 gelesen werden.
Figur 1 zeigt eine Konfiguration des PCs und des zugeordneten Coprozessors, durch die Software, die entsprechend der vorliegenden Erfindung vertrieben wird, ausgeführt werden kann. Zu Beschreibungszwecken wollen wir annehmen, daß die Software auf magnetischen Medien, wie beispielsweise Disketten, vertrieben wird, obwohl im weiteren Verlauf der Beschreibung deutlich wird, daß die Software auf jede beliebige konventionelle Weise vertrieben werden kann. Während gemäß der in der zitierten EP-A-0 174 472 beschriebenen Erfindung, die Unterstützungshardware mit dem Wirtsrechner über dessen internen Bus kommuniziert, ist es ein Merkmal der vorliegenden Erfindung, daß der Coprozessor über eine Kommunikationsschnittstelle an den PC gekoppelt werden kann, so daß der Coprozessor bequem portabel sein kann. Wir werden den Betrieb des Systems unter Verwendung dieser Konfiguration beschreiben, obwohl es klar sein sollte, daß die vorliegende Erfindung auch dann angewendet werden kann, wenn der Coprozessor mit dem PC über den internen Bus kommuniziert.
Der Coprozessor 15 besitzt einige Merkmale, die denen der Unterstützungshardware der zitierten EP-A-0 174 472 gleichen. Im besonderen stellt der Coprozessor jedem Softwarehändler eine höher privilegierte Ebene bereit, als sie der Benutzer bekommt, verschafft ihm aber gleichzeitig keinen Zugriff auf privilegierte Informationen anderer Softwarehändler. Jede Anwendungssoftware, die auf dem Coprozessor entschlüsselt wird und darauf läuft befindet sich auf der niedrigeren der zwei privilegierten Ebenen. Die höher privilegierte Ebene, die als im ROM stehende Firmware implementiert ist, steuert den Zugriff auf den nicht-flüchtigen RAM 153, die Lade-, Entschlüsselungs- und Ablaufoperationen. Diese Struktur in dem Corprozessor verhindert, daß ein Softwarehändler ein Monitorprogramm schreibt, welches auf dem Coprozessor laufen würde, um auf die Firmware und den nicht-flüchtigen Speicher zuzugreifen (einschließlich der Dechiffrierschlüssel) und damit diese Informationen dem Wirtsrechner 10 zugängig machen würde.
Dementsprechend hat der Coprozessor 15 eine erste oder niedrigere privilegierte Ebene, welche Zugriff auf den RAM 151 hat. Wie schon beschrieben wurde, ist der RAM 151 gegen Zugriff durch den Benutzer und/oder den Wirtsrechner 10 gesichert. Die erste privilegierte Ebene enthält Operationsbefehle der ersten Ebene zur Ausführung geschützter Software. Der Coprozessor 15 hat jedoch auch eine zweite privilegierte Ebene definiert, die einen sicheren Speicher der zweiten Ebene und Operationsbefehle der zweiten Ebene umfaßt. Der sichere Speicher der zweiten Ebene wird durch den nicht-flüchtigen RAM 153 repräsentiert, und die Operationsbefehle der zweiten Ebene sind im ROM 152 definiert. Die zweite privilegierte Ebene ist sowohl gegen den Benutzer als auch gegen jeden Softwareautor gesichert. Diese zweite privilegierte Ebene des Coprozessors 15 ist es, die beim Erwerb der Ausführungsrechte in Aktion tritt und die deshalb die Abläufe steuert, die diesem vorausgehen. Dieselbe zweite privilegierte Ebene reagiert auch auf die Benutzeranforderungen zur Ausführung geschützter Software, führt das Laden und Entschlüsseln der geschützten Software aus und versetzt die erste privilegierte Ebene zur Ausführung der geschützten Software in den Betriebszustand, aber nur dann, wenn die zweite privilegierte Ebene festgestellt hat, daß die Befugnis zur Ausführung vorliegt.
Es gibt entsprechend der vorliegenden Erfindung zwei Betriebsarten (Modi) von oder mit geschützter Software. Ein erster Modus, bezeichnet als Erlangung des Ausführungsrechtes (ARE - Acquire Right-to-Execute) ist notwendig, damit der Coprozessor zur Ausführung der geschützten Software autorisiert werden kann. Jeder Coprozessor kann zur Ausführung vieler Softwareanwendungen autorisiert werden, indem der ARE-Vorgang für jede Anwendung ausgeführt wird. Danach, wenn das System ein Softwarepaket ausführt, für das es autorisiert worden ist, arbeitet es im Modus Laden, Entschlüsseln Abarbeiten (LDR - Load, Decrypt, Run).
Figur 3 beschreibt eine Softwarekonfiguration, die gemäß der vorliegenden Erfindung verwendet wird. Wie in Figur 3 gezeigt, können die drei Dateien als Einheit (entweder auf einem magnetischen Medium oder über Nachrichtenverbindung) vertrieben werden.
Eine erste Datei ist ein verschlüsselter Software-Dechiffrierschlüssel EAK. Die zweite Datei ist die Software, die sowohl Klartext-Software (TEIL 1) als auch geschützte oder verschlüsselte Software (TEIL 2) (EAK (Software, Teil 2)) enthält. Die letzte Datei sind die verschlüsselten Tokendaten EAK(TOKENDATEN). Während die verschlüsselte Software und die verschlüsselten Tokendaten unter Verwendung eines gemeinsamen Chiffrierschlüssels (AK) verschlüsselt werden, so daß jedes Teil unter Verwendung des Dechiffrierschlüssels (AK) entschlüsselt werden kann, ist der Software-Dechiffrierschlüssel mit einem andern Schlüssel (CSK) verschlüsselt, mit dem Schlüssel des Hardwareverkäufers, der, wie beschrieben werden wird, vor dem Softwarehändler geheimgehalten werden kann. Während gemäß der in der zitierten EP-A-0 174 472 beschriebenen Erfindung, ein Schlüsselpaar unter Verwendung eines Chiffriersystems mit "öffentlichem Schlüssel" ("public key") zum Verschlüsseln und Entschlüsseln des Softwareschlüssels verwendet werden muß, ist es ein Merkmal des vorliegenden Systems, daß jedes adäquate sichere Verschlüsselungssystem einschließlich DES oder anderer "symmetrischer" Schlüsselsysteme, bei welchen derselbe Schlüssel zum Verschlüsseln und Entschlüsseln benutzt wird, eingesetzt werden kann.
Zu Beschreibungszwecken wollen wir annehmen, daß die drei Dateien von Figur 3 auf einer Diskette stehen, welche aus dem Laufwerk 17 geladen wird. Um den Coprozessor zu initialisieren, wird eine Tokenkassette 20 an den Coprozessor 15 oder den Wirtsrechner 10 gekoppelt. Die Kassette enthält die Tokendaten, gespeichert in einem Speicher, welcher, wie unten beschrieben werden wird, ihn auszeichnende Merkmale besitzt. An diesem Punkt ist es ausreichend zu bemerken, daß die Kassette 20 so organisiert ist, daß sie nur ein einziges Mal benutzt werden kann. Der Vorgang der Benutzung der Kassette 20 verändert diese so, daß sie für den beabsichtigten Zweck nicht länger eingesetzt werden kann.
Um die (geschützte) Software verwenden zu können, muß der Coprozessor 15 mit dem Dechiffrierschlüssel (AK) ausgerüstet sein, welcher dazu benötigt wird, den verschlüsselten Abschnitt der Anwendung ausführbar zu machen. Dieser Schlüssel wird auf den Coprozessor 15 des Softwarebesitzers auf solche Weise übertragen, daß der Übertragungsmechanismus nicht wiederverwendet oder reproduziert werden kann. Dies wird dadurch erreicht, daß für die wirksame Übertragung des Dechiffrierschlüssel in den nichtflüchtigen Speicher des Coprozessors 15 die Anwesenheit einer unbenutzten Tokenkassette gefordert wird. "Unbenutzt" bedeutet in diesem Zusammenhang nur, daß der Inhalt, der vom Softwareautor gelieferten Tokenkassette, nicht vor diesem Einsatz durch andere Mittel gelesen worden ist. Wie zu bemerken ist, ist das Token aus Gründen, welche später diskutiert werden, schwer zu fälschen und es wird während des Übertragungsvorgangs wirksam gelöscht. Das Token besitzt einen Informationsgehalt, welcher durch den Coprozessor 15 identifiziert werden kann, entweder weil er in einer verschlüsselten Datei aufgelistet wird, die dem Programm zugeordnet ist (oder alternativ durch eine andere Quelle bereitgestellt wird, wie unten beschrieben wird). Die Liste hat ihre Richtigkeit aufgrund der Tatsache, daß sie von dem Softwareautor geliefert worden ist. Der Beweis der Authentizität gegenüber dem Coprozessor 15 erfolgt dadurch, daß die Information mit demselben Schlüssel (AK) verschlüsselt wird, den der Softwarehändler dazu benutzt hat, um den geschützten Abschnitt der Anwendung zu verschlüsseln.
Die Kassette 20, die das Übertragungstoken speichert, wird über einen zu diesem Zweck bereitgestellten Verbinder mit dem Ein-/Ausgabe-Gerät 154 des Coprozessors (nicht dargestellt) gekoppelt oder mit dem Ein-/Ausgabe-Gerät 19 des PC (wie dargestellt) . Weil der Verbinder zur Kassette 20 offen ist und deshalb durch den Benutzer überwacht werden kann, muß der Vorgang, welcher den Verbinder verwendet, unter dem gegebenen Umstand, daß einige Daten offenbart werden, schwierig zu fälschen sein. Um diese Eigenschaft zu erhalten, sollte jeder Vorgang tatsächlich einmalig und durch den Coprozessor verifizierbar sein.
Die Kassette 20 ist sowohl physisch als auch logisch sicher. Die physische Sicherheit kann auf verschiedene Weise erreicht werden. Eine dieser Möglichkeiten ist in der EP-A-0 268 882 der Anmelderin beschrieben. Ein bevorzugtes Verfahren zur Gewährleistung physischer Sicherheit besteht darin, die Schaltungsanordnung des Tokens als einzelnen integrierten Schaltkreischip zu implementieren. Die Kassette 20 enthält Speicher, welche sich so verhalten, daß die Möglichkeit besteht, sowohl keine vorhergehende Benutzung als auch deren Authentizität zu überprüfen. Beide Überprüfungen werden vom Coprozessor benötigt, bevor der Dechiffrierschlüssel AK für eine zukünftige Verwendung akzeptiert wird. Wie unten beschrieben werden wird, kann die Kassette 20 durch eine dritte Partei gefertigt werden, solange ihr Verbinder und das Protokoll standardisiert sind. Ihr Informationsgehalt muß durch den Softwareautor oder durch deren Repräsentanten bestimmt und geladen werden. Die Daten werden unter Verwendung eines Frage/Antwort-Protokolls von der Kassette zum Coprozessor übertragen. Die Anfrage ist eine Zufallszahl und diese bestimmt in Kombination mit den Tokendaten die Tokenantwort. Die zugängigen Informationen, die über den ungesicherten Übertragungsweg zwischen Coprozessor 15 und Kassette 20 laufen sind die Zufallszahl und die Antwort der Kassette, von denen keine die Tokendaten offenbart. Der Coprozessor hat Zugriff auf eine Kopie der Tokendaten (zum Beispiel durch Entschlüsseln der verschlüsselten Tokendaten von dem Softwareverteilungsmedium) . Somit kann der Coprozessor unabhängig die "korrekte" Antwort bestimmen und kann die tatsächliche Antwort von der Kassette 20 mit seiner eigenen, unabhängig bestimmten, "korrekten" Antwort vergleichen. Folglich werden während dieses Vorgangs nur die Zufallszahl-Anfrage und die aktuelle Antwort offengelegt. Die komplette Tokeninformation, die benötigt wird, um durch Kombination mit der Anfrage die Antwort zu erhalten, wird nicht offenbart. Zur gleichen Zeit, in der die Kassette 20 ihre Antwort erzeugt, verändert sie auch ihren Inhalt, so daß die Kassette nicht wiederverwendet werden kann. Dies wird dadurch erreicht, daß in der Kassette 20 ein Speicherbereich bereitgestellt wird, der sich bei einer Leseoperation nicht wie ein normaler Speicher verhält. (Ein Blockschaltbild mit einer geeigneten Architektur für die Kassette 20 wird in Figur 2 gezeigt). Kurz gesagt, die Kassette 20 enthält mindestens zwei Speichersegmente, beide können beschrieben werden, als wären sie konventionelle Schieberegister mit serieller Eingabe. Wenn jedoch eine Leseoperation ausgeführt wird, verändern sich die Zugriffsparameter der beiden Regionen. Während des Lesens werden beide Speichersegmente aktiviert und erzeugen Daten am Ausgang, wie es ein normales Schieberegister mit seriellem Ausgang machen würde. Beide Ausgangssignale werden an einen Multiplexer gesendet. Der Multiplexer wählt über den Zustand der Steuerleitung, die im Verbinder enthalten ist und die vom Coprozessor mit der Zufallszahl angesteuert wird, aus, welche Daten aus den beiden (oder aus mehreren) Segmenten zum Verbinder (und somit zum Coprozessor) geleitet werden. Wenn der Speicherbereich der Kassette ausgelesen wird, wird der Inhalt in beiden Segmenten gelöscht. Dies sichert, daß ein Hacker, der den Vorgang zwischen dem Coprozessor und der Tokenkassette überwacht, nur einen Teil des Informationsgehaltes der Kassette gewinnen kann. Dieser Teil der Tokeninformation genügt dem Coprozessor zur Verifikation ob ein gültiges Token vorliegt, welches den Coprozessor autorisiert, das Softwarepaket zu benutzen, aber er ist bei weitem nicht dazu ausreichend, es einem Hacker zu ermöglichen, den Originalinhalt des Tokens zu rekonstruieren, um einen Coprozessor so irrezuführen, daß dieser einen Schlüssel akzeptiert, der nicht rechtmäßig erworben ist.
In einer Ausführungsform der Kassette 20, welche oben beschrieben wurde, werden zwei Schieberegister eingesetzt, so daß während eines Lesens die ausgewählten 50% des Speicherinhalts offengelegt werden. Für alternative Versionen kann vorgeschlagen werden, größere Speichersegmente oder eine größere Auswahltiefe als ein Bit oder die Verwendung adressierbarer, gespeicherter Daten zur Beantwortung der Anfragen zu verwenden. Diese Variationsmöglichkeiten bieten dem Systementwickler, der sich mit dem Verhältnis Kosten zu Sicherheit beschäftigt, Kompromißmöglichkeiten.
Während dieser Leseoperation wird ein Teil des Tnhalts der Kassette 20 zum Coprozessor übertragen. Die Abschnitte, die ausgewählt werden, werden durch eine Zufallszahl bestimmt, die durch den Coprozessor erzeugt wird. Sowohl die Zufallszahl als auch die Antwort von der Kassette 20 werden dann im Coprozessor gespeichert. Diese Information kann dann mit den Tokendaten (Datei 3, Figur 3) verglichen werden, welche vom Softwareverteilungsmedium ebenfalls zum Coprozessor übertragen werden. Stimmen die Tokendaten nicht mit den erwarteten Tokendaten überein, wird dies als Beweis für die Fälschung der Tokenkassette angesehen und führt dazu, daß der Coprozessor den Dechiffrierschlüssel bezüglich weiterer Benutzung abweist. Natürlich kann die geschützte Software nur dann ausgeführt werden, wenn der Dechiffrierschlüssel für die zukünftige Benutzung akzeptiert wird,
Figur 2 ist ein Blockschaltbild einer Ausführungsform der Kassette 20. In dieser Ausführungsform wird das Tokenelement aus Kostengründen und aus Gründen der physischen Sicherheit als einzelner integrierter Schaltkreischip 25 in Silizium CMOS-Technologie implementiert. Dieser Chip ist geeignet verkappt, so daß die Datenspeicherelemente 120 und 220 durch die Batterie 26 kontinuierlich mit Energie versorgt werden. Integrierte CMOS-Schaltungen können mit so geringen statischen Verlustleistungen gebaut werden, daß erwartet werden kann, daß die in diesen Registern gespeicherten Daten, wenn sie nicht gelesen werden, fast solange erhalten bleiben, wie die Lagerfähigkeitsdauer der Batterie ist. In dem Fall, daß die Daten gelesen werden, werden die anderen Bauteile, die benötigt werden, um die Leseoperation zu beeinflussen, von einer externen Quelle über die externen Energie- und Masseleitungen 27 mit Strom versorgt. Wie in Figur 2 dargestellt ist, wird die Kassette 20 mit dem Coprozessor oder dem PC über den Verbinder 23 gekoppelt, der die Leitungen Takt, Auswahl, Dateneingang, Datenausgang, Externe Spannungsversorgung und Externe Masse besitzt. Die Kassette 20 enthält zwei Speichersegmente in Form von Serielle Eingabe-, Serielle Ausgabe-, Links Schieben-Schieberegistern 120 und 220, ein erstes Segment, das die Zellen 121 bis 12n umfaßt und ein zweites Segment, das die Zellen 221 bis 22n umfaßt. Schieberegister dieser Art haben die Eigenschaft, daß der Zustand der Bits, die in den am weitesten links stehenden Zellen (121, 221) stehen, sich im Zustand ihrer Ausgangsleitungen (D1, D2) widerspiegelt. Sie haben die weitere Eigenschaft, daß sich mit der fallenden Flanke des Takt impulses an ihren Taktleitungen (C1, C2) der Zustand jeder Zelle derart verändert, daß er den Zustand der davon unmittelbar rechts stehenden Zelle annimmt, so daß das Bitmuster in dem Register nach links geschoben wird. Im Fall der am weitesten rechts stehenden Zellen (12n, 22n) bewirkt die fallende Flanke des Taktimpulses, daß diese Zellen den Zustand der Dateneingabeleitungen (D3, D4) annehmen. Die Zellen können dadurch mit raten gefüllt werden, daß an jede der beiden Dateneingabeleitungen ein Datenbit angelegt wird und daß dann ein Taktimpuls gegeben wird. Wenn dieser Vorgang für n Taktimpulse wiederholt wird, werden alle n Bits des Registers gefüllt werden. Dann könnte eine verschlüsselte Kopie (unter AK) dieser Bits gemacht werden und auf einer Diskette gespeichert werden, um so die verschlüsselte Beschreibung der Tokendaten zu liefern. Dieser Ablauf wird von einem Softwareautor verfolgt, um damit die Autorisierung eines Coprozessors zum Akzeptieren eines AK vorzubereiten.
Wenn eine Leseoperation durchgeführt wird, wird jedes Bit der vom Coprozessor erzeugten Zufallszahl aufeinanderfolgend auf die Auswahlleitung gegeben. Jedem Setzen der Auswahlleitung 21 folgt ein Taktimpuls. Beide Schieberegister schieben bei jedem Taktimpuls ihren Inhalt nach links. Die Daten vom ersten Schieberegister werden auf die Leitung D1 und die Daten vom zweiten Schieberegister auf die Leitung D2 gegeben. Beides sind Eingangssignale für einen Multiplexer 22, welcher der Reihe nach durch die Auswahlleitung 21 vom Coprozessor oder vom PC gesteuert wird. Die Auswahlleitung 21 bestimmt, welches der zwei Signale D1 oder D2 über den Zwischenspeicher (Latch) 24 auf den Ausgang DATEN geschaltet wird. Der Zwischenspeicher wird verwendet, um zu verhindern, daß ein Hacker die Tokendaten dadurch gewinnen kann, daß er bei jedem Taktimpuls das Auswahlsignal zweimal ändert. Die Folge dieser Anordnung ist, daß für jedes Bit, welches am Datenausgang erscheint, zwei Bits aus den Registern herausgeschoben worden sind und zwei Bits hineingeschoben worden sind, die für den Prozeß der Autorisierung nutzlos sind.
Dementsprechend und unter der Annahme, daß der gesamte Speicherinhalt der Kassette 20 ausgelesen wurde, würde man beim Beobachten der Eingangssignale auf der Auswahlleitung 21 und des DATEN-Ausgangs gerade maximal 50% des Inhalts der Kassette 20 erhalten. Der Coprozessor weiß aus der verschlüsselten Tokeninformation exakt, welche Bits in diesen 50% erscheinen sollten, so daß er über genügend Information verfügt, um die Gültigkeit der Autorisierung festzustellen, einem Hacker, dem jedoch die zerstörten 50% fehlen, ist es unmöglich, eine derartige Autorisierung zu fälschen.
Wenn der Coprozessor 15 aufgefordert wird, einen AK zu erwerben (ARE> , wird ein bestimmter Prozeß gestartet (siehe Figur 5) Dieser beginnt, wenn der verschlüsselte Software-Dechiffrierschlüssel (Datei 1) und die verschlüsselten Tokendaten (Datei 3) in den RAM 151 oder den temporären Speicher 15T geladen werden. Zusätzlich wird eine Zufallszahl (3) durch den Coprozessor erzeugt und bei der Durchführung einer Leseoperation der Kassette 20 verwendet, wie es im vorhergehenden beschrieben wurde. Die Zufallszahl wird verwendet, um auszuwählen, welche Bits aus welchen Speichersegmenten zum Durchgang durch den Multiplexer 22 wirksam werden. Der Coprozessor 15 speichert die Zufallszahl im RAM 151 zusammen mit den resultierenden DATEN (4) von der Kassette 20.
Es sollte vom Fachmann verstanden werden, daß es eine sehr große Zahl Variationsmöglichkeiten bei der Konstruktion der Tokenkassette gibt. Alle haben die Eigenschaften, daß die Daten, die von der Kassette gelesen werden, als Funktion sowohl der Anfragebits als auch des Inhalts der Tokendaten transformiert sind und daß die resultierende Antwort des Tokens vorhersagbar ist, wenn der komplette Tokeninhalt bekannt ist.
Der Coprozessor entschlüsselt den Software-Dechiffrierschlüssel ECSK (AK) und der resultierende Software-Dechiffrierschlüssel (AK) wird dazu verwendet, zur Erzeugung der Klartext-Tokendaten die Tokendaten zu entschlüsseln. In dem Fall, daß es eine Vielzahl von CSKs gibt, könnte der verschlüsselte Softwareschlüssel mit einem Bezug auf den korrekten CSK im Nachrichtenvorsatz geliefert werden. Ein solcher Nachrichtenvorsatz könnte einen Index bereitstellen, der auf den richtigen CSK in Klartext verweist oder ein Erkennungszeichen, das beim Entschlüsseln nur dann ein erwartetes Bitmuster liefert, wenn der richtige CSK verwendet wird. Viele andere Verfahren sind möglich. Wenn der Coprozessor den EAK mit dem richtigen CSK entschlüsseit hat, kann er die gespeicherte Zufallszahl oder Anfrage mit den Klartext-Tokendaten kombinieren und unabhängig die "richtige" Antwort bestimmen. Die tatsächliche Antwort (die DATEN, die von der Kassette 20 empfangen wurden) kann dann mit der "richtigen" Antwort verglichen werden. Wenn der Vergleich der zwei Größen positiv ausfällt, wird dies als Anzeige dafür betrachtet, daß die Kassette 20 den Coprozessor autorisiert, den AK (5) im nicht-flüchtigen RAM oder in dem Festspeicher 15P für die zukünftige Verwendung zu speichern. Der Benutzer kann jetzt den Coprozessor mit Erfolg dazu auffordern, die geschützte Software mit dem neu erlangten AK auszuführen. Es sollte beachtet werden, daß der Schlüssel AK vor dem Speichern durch den Prozessor erneut verschlüsselt werden kann. Dieser Schritt der Neu-Verschlüsselung könnte einen verbesserten Schutz des gespeicherten Schlüssels hervorbringen oder er könnte, wenn richtig verwendet, das Speichern des Schlüssels außerhalb des Coprozessors unterstützen.
Andererseits, wenn der Vergleich der "richtigen" und der tatsächlichen Antwort der Kassette nicht positiv ausfällt, wird der Software-Dechiffrierschlüssel (AK) verworfen, und der Coprozessor ist nicht in der Lage, die verschlüsselte Software ordnungsgemäß auszuführen, weshalb das Anwendungsprogramm nicht ordnungsgemäß ablaufen wird.
Es sollte ebenfalls deutlich werden, daß dieser Vorgang den Inhalt der Kassette 20 (siehe Figur 6) zerstört, so daß sie zur Autorisierung irgendeines anderen Coprozessors zum Abarbeiten dieser Anwendung oder irgendeines anderen Anwendungsprogramms nicht wiederverwendet werden kann.
Die enorme Anzahl von Auswahlmöglichkeiten des Inhalts der unterschiedlichen Segmente der Kassette, die von dem Coprozessor vorgegeben werden können und die Tnformationsmenge, die von dem Hacker durch "Trial and Error" rekonstruiert werden muß, sind die Barrieren gegen eine erfolgreiche Rekonstruktion der Kassette 20 durch einen Hacker. Die Wahrscheinlichkeit für eine erfolgreiche Fälschung (P(Fälschung)) ist eine Funktion det Wahrscheinlichkeit, daß der Coprozessor bei der Anforderung von jedem gegebenen Bit dieselbe Auswahl trifft (P(gleich)), von der Wahrscheinlichkeit, daß der Hacker die "verlorenen" Daten eines Beobachtungsvorganges richtig errät (P(erraten)) und von der Anzahl der Bits, die in dem Prozeß der Überprüfung der Gültigkeit vom Coprozessor abgefragt werden (AnzBits). P(Fälschung) = (P(gleich) + (1 - P(gleich)) (P(erraten))) hoch AnzBits. Wenn P(gleich) = 0,5 und P(erraten) = 0,5 und AnzBits = 128 ist, was in der Praxis mit einem kleinen integrierten Schaltkreischip leicht erreicht werden kann, dann wird P(Fälschung) ungefähr 10 hoch -16. Wenn die Geschwindigkeit, mit der ein Hacker seine Versuche testet, Eins pro Sekunde ist, dann würde selbst eine so kleine Kassette eine durchschnittliche Suchdauer von mehr als zweihundert Millionen Jahren bewirken. Der Coprozessor ist folglich in der Lage, zuverlässig festzustellen, ob eine Kassette, die er liest, vom Softwarehändler zum Zweck der Begründung des Besitzrechtes geliefert wurde oder ob sie eine Fälschung ist, ohne daß Informationen offengelegt werden, die zum Erzeugen einer erfolgreichen Fälschung notwendig sind. Der Coprozessor wird einen Dechiffrierschlüssel (AK) zur späteren Verwendung nur nach Überprüfung der Kassette speichern.
Figur 4 zeigt, wie der Softwarehändler ein vertriebsfähiges Softwareprodukt erstellen kann, das auf einem magnetischen Medium oder über Nachrichtenverbindung verteilt werden soll. Der Softwarehändler beginnt mit den drei Komponenten:
A. Anwendungssoftware,
B. einem Software-Dechiffrierschlüssel AK (der nur dem Softwarehändler bekannt ist) und
C. Tokendaten (eine Zufallszahl, die nur dem Softwarehändler bekannt ist)
Der Softwarehändler verwendet in einer ersten Funktion (F1) nur seinen eigenen (geheimen) Chiffrierschlüssel AK, um aie Tokendaten sowie kritische Teile (Teil 2) der Anwendungssoftware zu verschlüsseln. Das Ergebnis dieses Verschlüsselungsprozesses werden die verschlüsselten Tokendaten [EAK(TOKENDATEN)], welche vertrieben werden und die verschlüsselte Anwendungssoftware [E- -AK(Software)] sein.
Die unkritischen Teile der Anwendungssoftware (Teil 1) bilden eine weitere Komponente des vertriebsfähigen Softwareproduktes.
Zum Schluß wird der Software-Dechiffrierschlüssel (AK) in einer Funktion F2 unter Benutzung des Chiffrierschlüssels CSK des Hardwareverkäufers verschlüsselt. Das Ergebnis dieses Prozesses ist der verschlüsselte Schlüssel [ECSK(AK)], der die letzte Kornponente des vertriebsfähigen Softwareproduktes bildet.
Figur 4 zeigt die Funktion F2 in einem doppelten Rechteck, um darauf hinzuweisen, daß der Verschlüsselungsprozeß im Coprozessor des Softwarehändlers stattfindet, so daß der Chiffrierschlüssel des Hardwareverkäufers (welcher im Coprozessor enthalten ist) dem Softwarehändler unbekannt ist.
Auf diese Weise wird verhindert, daß der Softwarehändler Wissen über die Chiffrierschlüssel des Hardwareverkäufers erlangt. Die Softwarehändler können auswählen, auf welchen Coprozessoren der Hardwareverkäufer sie gewillt sind, ihre Schlüssel installieren zu lassen, indem verschlüsselte Softwareschlüssel (EAKs) vorbereitet werden und das nur auf Coprozessoren, die von vertrauenswürdigen Herstellern geliefert werden. Es liegt klar im obersten Interesse der Hardwarehersteller, daß die Wirksamkeit ihrer eigenen Produkte nicht dadurch zerstört wird, daß ihre eigenen CSKs oder die Benutzung ihrer eigenen CSKs die AKs der Softwarehändler offenbart. Dementsprechend brauchen keine "geheimen" Daten zwischen dem Hardware- und dem Softwarehändler geteilt werden.
Ein Vergleich der Figuren 5 und 6 offenbart, daß in Folge des ARE-Prozesses die Tokendaten der Tokenkassette 20 gelöscht, entfernt oder überschrieben wurden, so daß nicht länger auf diese zugegriffen werden kann. Figur 6 zeigt die Register in der Kassette als "leer" in dem Sinn, daß die Klartext-Tokendaten, welche vor dem ARE-Prozeß dort standen, durch die Daten ersetzt wurden, welche am Verbinder 23 (siehe Figur 2) über die Leitungen D3 und D4 angelegt wurden. Diese Daten sind für den Anerkennungsprozeß bedeutungslos, und somit sind bezüglich des Informationsgehaltes die Register der Tokenkassette 20 tatsächlich "leer". Bei erfolgreichem Abschluß des ARE-Prozesses ist der Software-Dechiffrierschlüssel AK, der vom Coprozessor 15 in verschlüsselter Form ECSK(AK) empfangen wurde, entschlüsselt worden und als Reaktion auf die erfolgreiche Beendigung von ARE, ist der AK in den Festspeicher 15P des Coprozessors 15 übertragen (5) worden. Figur 6 zeigt auch die Operationen des Coprozessors während LDR. Während dieses Prozesses wird der Software-Dechiffrierschlüssel AK (5) in den temporären Speicher 15T kopiert. Die Klartextsoftware (Datei 2) wird zum Wirtsrechner 10 übertragen, wo sie insofern ausführbar ist, als sie in Klartextform vorliegt. Die verschlüsselte Software (8) wird zum Coprozessor 15 übertragen und befindet sich im temporären Speicher IST. An diesem Punkt wird die verschlüsselte Software unter Benutzung des Software-Dechiffrierschlüssel AK entschlüsselt (9), so daß sie durch den Coprozessor 15 ausführbar ist.
Weil der Coprozessor 15 gesichert ist, ist die geschützte Klartext-Software für den Benutzer oder jeden anderen nicht zugängig, obwohl sie im Speicher des Coprozessors steht. Die Software ist jedoch durch den Coprozessor ausführbar, und die Ergebnisse dieser Ausführung können an den Wirtsrechner 10 weitergegeben werden. Als Ergebnis dessen, arbeiten der Wirtsrechner 10 und der Coprozessor 15 bei der Ausführung des Anwendungssoftwarepaketes zusammen, der Wirtsrechner oder PC 10 führt den Klartext-Abschnitt aus, obwohl wenn es gewünscht wird die ganze Anwendung geschützt werden und nur auf dem Coprozessor 15 laufen könnte.
Die Figuren 3 bis 6 illustrieren eine Ausführungsform und Anwendung der vorliegenden Erfindung, wobei die verschlüsselten Tokendaten dem Benutzer auf demselben Medium bereitgestellt werden, welches auch die Software trägt. Wenn dieses Medium auch magnetisch sein könnte, so liegt es ebenfalls in der Absicht der Erfindung, daß das Medium eine Nachrichtenverbindung sein könnte.
Indem die verschlüsselten Tokendaten der Software zugeordnet werden, erfordert dies, daß das Softwareverteilungsmedium mindestens zu einem gewissen Teil einzigartig oder relativ einzigartig ist (durch die Anwesenheit der verschlüsselten Tokendaten] Wie oben erwähnt gibt es jedoch Vorteile, wenn das vertriebsfähige Softwaremedium allgemeingültig aufgebaut ist und in dieser Ausführungsform der Erfindung erscheinen die verschlüsselten Tokendaten nicht auf dem Softwareverteilungsmedium (oder sind bei einer Übertragung über Nachrichtenverbindung nicht der Anwendungssoftware zugeordnet) Jedoch ist noch wesentlich, daß die verschlüsselten Tokendaten an den Coprozessor 15 geleitet werden, weil diese Information wesentlich für die Erlangung des Rechts auf Ausführung ist. In dieser alternativen Ausführungsform der Erfindung wird die Hardwarekassette 20 so modifiziert, daß sie mindestens ein Register enthält, das die Aufgabe hat, die verschlüsselten Tokendaten zu speichern. Der Coprozessor l5 erzeugt dann zusätzlich zum Zugriff oder der Anfrage auch ein spezielles Kommando sowie geeignete Taktimpulse, um die verschlüsselten Tokendaten in den Coprozessor 15 zu übertragen. In dieser alternativen Ausführungsform der Erfindung speichert die Hardwarekassette 20 nicht nur Klartext-Tokendaten (in den Schieberegistern 120 und 220), sondern speichert auch verschlüsselte Tokendaten in einem dritten Register (in Figur 2 nicht dargestellt).
Figur 7 ist ein Flußdiagramm, das die Funktionen zeigt, die im Wirtsrechner 10 entsprechend der vorliegenden Erfindung ausgeführt werden. Die in Figur 7 dargestellten Dienste sind spezifisch für die Erfindung. Andere konventionelle Dienste werden nicht dargestellt. Wie in Figur 7 gezeigt wird, wird durch eine Anfangsbestimmung Hl festgestellt, ob der-ARE-Prözeß angefordert wird oder nicht. Beim ersten Lauf jedes speziellen Anwendungspaketes wäre gemäß vorliegender Erfindung diese Anforderung aktiv. Dementsprechend wird dann Funktion H2 aufgefordert, diese Anforderung an den Coprozessor 15 zu senden. Dann wird in eine aus H3 und H4 bestehende Schleife eingetreten, in welcher der Wirtsrechner 10 Coprozessoranforderungen bedient, bis der Coprozessor 15 anzeigt, daß er den ARE-Prozeß beendet hat. Bei der Beendigung der Schleife, geht die Verarbeitung zurück zur Funktion H1.
Nachfolgend auf die Durchführung der Schritte H1 bis H4, oder zu jedem Zeitpunkt, zu dem der LDR-Prozeß ausgeführt werden soll (bei der zweiten und jeder folgenden Ausführung der Anwendungssoftware entsprechend der Erfindung), leitet die FunktionH1 die Verarbeitung an die Funktion H5 weiter. H5 bestimmt, ob der LDR-Prozeß angefordert wird. Wenn der LDR-Prozeß nicht angefordert wird, bestimmt die Funktion H6, ob das Verlassen dieser Dienste angefordert wird, wenn nicht, verzweigt die Verarbeitung zurück zum Block H1. Wenn ein Verlassen angefordert wird, dann wird der in Figur 7 gezeigte Verarbeitungsprozeß beendet (ENDE)
Andererseits wird, wenn bei der Funktion H5 eine LDR-Anforderung erkannt wurde, die Funktion H7 ausgeführt, um die LDR-Anforderung an den Coprozessor 15 zu senden.
Dann wird in eine aus den Funktionen H8 und H9 bestehende Schleife eingetreten, welche der Schleife H3 - H4 vollkommen gleicht. Wenn der Coprozessor H9 anzeigt, daß die LDR-Verarbeitung beendet wurde, dann wird die Funktion H10 ausgeführt, um das entsprechende Programm im Wirtsrechner 10 (beispielsweise das Anwendungsprogramm) zu informieren, daß die LDR-Verarbeitung beendet ist.
Wenn die Funktion H2 ausgeführt wird, wird der Coprozessor 15 angeregt, seinen Teil des Prozesses zur Erlangung des Rechtsauf-Ausführung abzuarbeiten. Diese Funktionen werden in Figur 8 dargestellt. Der ARE-Prozeß läuft auf der hoheren der zwei im vorigen beschriebenen privilegierten Ebenen, weil es seine Aufgabe ist, zum Schutz des Softwarehändlers die Weiterverbreitung des Rechts auf Ausführung zu verhindern.
Wie in Figur 8 dargestellt, fordert die Funktion C1 den verschlüsselten Software-Dechiffrierschlüssel vom Wirtsrechner 10 an. Der Wirtsrechner 10 hat vom Softwareverteilungsmedium aus (oder von der Nachrichtenverbindung, falls die Software in dieser Form vertrieben wird) Zugriff auf diese Information. Die Funktion C2 entschlüsselt den verschlüsselten Software-Dechiffrierschlüssel, weil sie Zugriff zum CSK hat. Der CSK ist zum Zeitpunkt der Herstellung vom Produzenten des Coprozessors 15 im Festspeicher installiert worden. Wie schon gezeigt wurde, kann mehr als ein einzelner CSK vorhanden sein. In diesem Fall würde die Datei mit dem verschlüsselten Software-Dechiffrierschlüssel einen Nachrichtenvorsatz enthalten, einen Index oder eine Adresse, um damit den geeigneten CSK zu identifizieren. Die Funktion C3 fordert dann die verschlüsselten Tokendaten vom Wirtsrechner an. Für den Fall, daß die verschlüsselten Tokendaten mit demselben Softwareverteilungsmedium verbunden sind wie die Anwendung, hat der Wirtsrechner 10 Zugriff auf diese. Alternativ dazu könnten die verschlüsselten Tokendaten in der Hardwarekassette 20 gespeichert sein. Wie aber schon beschrieben wurde, kann der Wirtsrechner 10 Zugriff auf die Hardwarekassette 20 haben und wenn nicht, hat der Coprozessor 15 direkten Zugriff auf die Hardwarekassette 20.
Die Funktion C4 entschlüsselt die verschlüsselten Tokendaten unter Benutzung des schon verfügbaren Software-Dechiffrierschlüssels. Die entschlüsselten Tokendaten werden dann in dem temporären Speicher 15T aufbewahrt.
Die Funktion C5 erzeugt dann eine Zufallszahl, welche die Tokenanfrage bildet. Funktion C6 kombiniert die Zufallszahl und die Tokendaten, um die Tokenantwort zu simulieren und erzeugt die berechnete Antwort, welche genauso in dem temporären Speicher 15T aufbewahrt wird.
Die Schlüssel C7 fordert dann den Wirtsrechner auf, die Hardwarekassette 20 mit der Zufallszahl (der Tokenanfrage) abzufragen. Wenn der Coprozessor 15 direkten Zugriff auf die Hardwarekassette 20 hat, ist es natürlich besser, diese Funktion direkt auszuführen als indirekt über den Wirtsrechner 10. Die Funktion C8 fordert dann den Wirtsrechner auf, die Tokenantwort zu liefern, welche ebenfalls in dem temporären Speicher 15T gespeichert wird. Dann vergleicht die Funktion C9 die tatsächliche Antwort mit der berechneten oder erwarteten Antwort. Funktion C10 ist eine Verzweigung auf der Basis des Vergleichs von Funktion C9. Wenn der Vergleich der berechneten und der tatsächlichen Antwort des Tokens positiv ausgefallen ist (typischerweise werden sie gleich sein), wird dies als Beweis dafür genommen, daß das Token echt ist. Die Funktion C13 schafft danach den Software-Dechiffrierschlüssel in den Festspeicher (5). Dann schickt die Funktion C14 über den Wirtsrechner 10 eine Nachricht, um den Benutzer darüber zu informieren, daß der ARE-Prozeß erfolgreich abgeschlossen wurde und stellt für den Wirtsrechner 10 eine Information bereit, mit der er den Platz des Software-Dechiffrierschlüssels, der dieser Anwendung entspricht, identifizieren kann. Danach wird der ARE-Prozeß beendet.
Andererseits wird dann, wenn der Vergleich der tatsächlichen und der berechneten Tokenantwort nicht erfolgreich war (zum Beispiel die Antworten waren ungleich), anstatt der Ausführung der Funktionen C13 und C14 die Funktion C11 ausgeführt, um an den Benutzer die Information zu geben, daß das Recht-auf-Ausführung nicht erlangt wurde. Es sollte beachtet werden, daß in diesem Fall, obwohl der Software-Dechiffrierschlüssel im temporären Speicher 15T vorhanden ist, dieser nicht in den Festspeicher 15P übertragen wird. Dementsprechend ist der Software-Dechiffrierschlüssel nicht benutzbar, und das Anwendungspaket wird nicht ausgeführt werden.
Figur 9A zeigt die Funktionen, die im Wirtsrechner während eines typischen LDR-Prozesses ablaufen. Den LDR-Prozeß zu initiieren ist Aufgabe der Funktion H11, welche das Anwendungsprogramm startet. Bei Feststellung, daß das Programm geschützt ist, wird die Funktion H12 ausgeführt, die zusammen mit der Information zur Bestimmung des Platzes des AK, z.B. des Platzes im Festspeicher des Coprozessors 15, auf welchem sich der benötigte Software-Dechiffrierschlüssel befindet, eine Anforderung für eine LDR-Bestellung an das DOS gibt. Diese Information ist dem Wirtsrechner durch die Funktion C14 bei erfolgreichem Abschluß des vorhergehenden ARE-Prozesses bereitgestellt und zusammen mit dem Anwendungsprogramm gespeichert worden.
Die Funktion H13 ist dann nur eine Verzögerung, die auf die Nachricht vom DOS-Dienst wartet (siehe Figur 7) . Bei dieser Nachricht (H10 - Figur 7) wird Funktion ?114 ausgeführt, um die Anwendung unter Verwendung des Codes, der wie benötigt im Coprozessor 15 ausgeführt wird, abzuarbeiten. Um zu sehen, wie die geschützte Software im Coprozessor 15 ausgeführt wird, wird auf Figur 9B verwiesen.
Wie in Figur 3 dargestellt ist, wird, wenn der Coprozessor 15 eine LDK-Anforderung empfängt, Funktion C15 ausgeführt, um die in Figur 9B gezeigten Funktionen auszulösen. Die LDR-Anforderung wird in Funktion H7 ausgelöst (siehe Figur 7). Funktion C16 fordert den Wirtsrechner auf, Informationen bereitzustellen, um den AK zu lokalisieren. Diese Anforderung wird an den DOS-Dienst (Figur 7) weitergegeben, welcher mit der Information antwortet, die durch Funktion H3 bereitgestellt wurde. Mit der Indexinformation erhält die Funktion C17 eine Kopie des Software-Dechiffrierschlüssels aus dem Festspeicher und lädt diese in den temporären Speicher 15T des Coprozessors 15. Die Funktion C18 fordert dann die geschützte Software vom Wirtsrechner an. Die geschützte Software, die in verschlüsselter Form im temporären Speicher enthalten ist, wird in der Funktion C19 unter Benutzung des Software-Dechiffrierschlüssels, der in Funktion C17 übergeben wurde, entschlüsselt. Das Ergebnis von Funktion C19 ist die Klartextversion der geschützten Software. Diese verbleibt im temporären Speicher IST des Coprozessors 15. Der Schutz, der durch die physische und logische Sicherheit des Coprozessors 15 gegeben ist, verhindert die Enthüllung des Klartext-Abschnittes der geschützten Software vor dem Benutzer oder irgend einem anderen. Funktion C20 informiert dann den Wirtsrechner, daß der LDR-Prozeß abgeschlossen wurde und die Funktion C21 führt dann die geschützte Software aus. Die Funktionen C17 bis C19 werden als zur höheren privilegierten Ebene zugehörig betrachtet, weil sie mit der Verwendung des Rechts auf Ausführung, dem AK, befaßt sind. Andererseits ist die Funktion C21 ein Beispiel für die niedrigere privilegierte Ebene. Es sollte dem Fachmann klar sein, daß die Funktionen H14 und C21 unter Verwendung einer Vielzahl verschiedener Techniken zusammenarbeiten können, so daß das Nettoresultat die komplette Ausführung der Anwendungssoftware ist. Es liegt im Bereich der Erfindung, daß die gesamte Anwendungssoftware geschützt werden kann. Während der Ausführung der geschützten Software durch den Coprozessor 15 werden dann nur die Resultate dieser Ausführung dem Wirtsrechner zur Verfügung gestellt. Es sollte deutlich werden, daß die Ergebnisse der Ausführung, welche für den Benutzer zugängig sind, keine adäquate Basis dafür bilden, den Klartext oder die geschützte Software zu rekonstruieren.
Die Erfindung erfüllt also die oben dargelegten Aufgaben. Im besonderen kann das Softwareverteilungsmedium frei kopiert oder zur Sicherheit dupliziert werden. Es wird jedoch nicht ausgeführt werden, außer auf zusammengesetzten Systemen, die einen Coprozessor wie den Coprozessor 15 enthalten. Selbst dann wird es nur auf einem zusammengesetzten System ausgeführt werden, in welchem der Coprozessor 15 Zugriff auf den benötigten Software-Dechiffrierschlüssel hat. Desweiteren wird eine authentische Kassette 20 benötigt, um dem Coprozessor 15 Zugriff auf den Software-Dechiffrierschlüssel zu verschaffen und diese Information im Festspeicher zu behalten. Die Kassette 20 ist so organisiert, daß es schwierig ist, sie zu fälschen oder zu simulieren und sie ist nur einmal benutzbar. Daraus ergibt sich mit Notwendigkeit, daß eine geeignete Hardwarekassette 20 einen und nur einen einzigen Coprozessor 15 autorisieren kann. Während nur ein einzelner Coprozessor 15 autorisiert werden kann, ist es von entscheidender Bedeutung, daß er portabel ist, so daß er mit jedem geeigneten Wirtsrechner 10 zusammen verwendet werden kann, um die geschützte Software abzuarbeiten. Somit erreicht der Softwarehändler das wünschenswerte Resultat, daß das Recht zur Ausführung von der geschützten Anwendungssoftware getrennt wird.
Sein Kunde, der Benutzer, kann soviele Kopien von der geschützten Software anlegen, wie er möchte, kann sie zu jedem beliebigen Zeitpunkt aber nur auf einem einzigen zusammengesetzten System ausführen lassen.

Bedingtes Recht auf Ausführung

Der Schutzmechanismus für den Softwarebesitz installiert, wie oben kurz beschrieben, ein unbedingtes Recht auf Ausführung im Coprozessor 15. Es ist jedoch eines der Merkmale der vorliegenden Erfindung, daß das Recht auf Ausführung mit Bedingungen verknüpft werden kann, und Beispiele für Bedingungen sind Enddaten und Zeiten oder eine Anzahl von Ausführungen. Die Figuren 10A bis 10C zeigen den Fall, in welchem der geschützte Abschnitt der Anwendungsdatei ein Prüfkriterium für die Ausführung enthält, z.B. wenn das Beendigungsdatum und/oder die Zeit hinter dem momentanen Datum liegt, wird die Ausführung gestattet. Bei der Eingabe eines durch den Softwarevertrieb erworbenen Datensatzes in das kombinierte Datenverarbeitungssystem bestehend aus dem Wirtsrechner 10 und dem Coprozessor 15, wie in Figur 10A gezeigt, verläuft die Installation des Rechts auf Ausführung genau wie oben beschrieben. Der Coprozessor 15 überprüft (und zerstört) mit Hilfe des Wirtsrechners 10 das Token 20, indem er dessen Klartextinhalt (T&sub1;) mit einer verschlüsselten Version der Datei EAK(T&sub1;) vergleicht, die er von der Platte 46 gelesen hat. Bei der Überprüfung der Authentizität und Unbenutztheit des Tokens 20 speichert der Coprozessor 15 den Software-Dechiffrierschlüssel AK in den Festspeicher 15P ein. Die Bedingungen für die Ausführung können in derselben Datei gespeichert sein wie der AK und können gleichzeitig mit dem AK installiert werden. In dem in Figur 10A dargestellten Fall speichert der Coprozessor 15 das Datum, welches als ein Abschlußdatum und/oder Zeit interpretiert werden kann. Diese Interpretation wird durch den geschützten Abschnitt der Anwendung bei jeder Benutzung durchgeführt. Das Speichern des Abschlußdatums ist mit dem Software-Dechiffrierschlüssel AK verbunden, wie in Figur 10B dargestellt. Im besonderen ist Figur 10B mit Figur 10A weitgehend identisch, außer daß dargestellt ist, daß der Software-Dechiffrierschlüssel AK und das Abschlußdatum und/oder die Zeit in dem Festspeicher des Coprozessors 15 gespeichert sind und daß angezeigt wird, daß das Token 20 geleert wurde. Danach verwendet die geschützte Anwendung jedes Mal, wenn sie auf dem Coprozessor 15 läuft, das Kriterium, das in der verschlüsselten Anwendungsdatei steht und das aussagt, daß das aktuelle Datum und/oder die Zeit nicht hinter dem Abschlußdatum und/oder der Zeit liegen soll und autorisiert die Ausführung nur in dem Fall, daß das Kriterium erfüllt ist. Das aktuelle Datum und/oder die Zeit wird auf Kommando durch den Coprozessor 15 an die laufende Anwendung gegeben.
Figur 10C gleicht Figur 10B, außer daß die Bedingung, die in der verschlüsselten Anwendungsschlüsseldatei steht, die verbleibende Anzahl autorisierter Ausführungen angibt. Bei der Installation des Rechts auf Ausführung wird der Software-Dechiffrierschlüssel AK mit einem Zählerstand C verbunden. Jedes Mal, wenn die Ausführung der Anwendung angefordert wird, wird der Inhalt des Zählers C mit einem Kriterium überprüft, daß die Anzahl der verbleibenden autorisierten Ausführungen größer als Null sein muß. Der Zählerstand C wird dann dekrementiert. Nur solange C größer als Null ist, wird die Ausführung gestattet.
Unabhängig davon, ob die Bedingung ein Abschlußdatum und/oder eine Zeit oder eine Anzahl von Ausführungen ist, kann es ratsam sein, dem Coprozessor 15 Befehle zur Verfügung zu stellen, mit denen der zugeordnete Software-Dechiffrierschlüssel AK gelöscht wird, wenn die Anfangsbedingungen nicht länger erfüllt sind. Somit wird der Software-Dechiffrierschlüssel AK automatisch aus dem Festspeicher entfernt und folglich ist das Recht auf Ausführung erloschen. Weitere Details zu bedingten Ausführüngsrechten werden in der EP-A-0 268 139 beschrieben, welche durch Bezugnahme hier aufgenommen wird.

Claims

1. Verfahren zur Sicherung geschützter Software (46) gegen unbefugte Benutzung, ohne daß existierende Kanäle zur Softwareverteilung zerstört werden und gleichzeitig ohne daß die unbeschränkte Herstellung von Sicherungskopien der geschützten Software durch den Benutzer gestört wird, wobei das Verfahren die Schritte umfaßt:

a) Bereitstellen eines physisch sicheren Coprozessors (15) und Koppeln des Coprozessors mit einem Wirtsrechner (host) (10) des Benutzers, um zwischen diesen Computern einen bidirektionalen Informationsaustausch mit dem Ziel zu unterhalten, ein zusammengesetztes Datenverarbeitungssystem zu erzeugen, das den Wirtsrechner und den Coprozessor umfaßt;

b) Bereitstellen logischer Sicherheitsvorkehrungen für den Coprozessor durch:

1) Bereitstellen einer ersten privilegierten Ebene, zur Ausführung der geschützten Software, die einen sicheren Speicher (151) der ersten Ebene und Operationsbefehle der ersten Ebene (152) enthält, welche gegen Zugriff und Veränderung durch den Benutzer gesichert sind;

c) Verteilen der geschützten Software (46) in einer Form, in welcher zumindest ein Teil durch den Wirtsrechner unausführbar ist;

d) Verteilen eines weiteren greifbaren, von der geschützten Software getrennten Elementes (20), das das Recht darstellt, die geschützte Software auszuführen;

e) Herstellen des Zugriffs des zusammengesetzten Datenverarbeitungssystems auf die geschützte software und auf das weitere greifbare Element; dadurch gekennzeichnet, daß:

Schritt b) weiterhin den Schritt umfaßt:

2) Bereitstellen einer zweiten privilegierten Ebene zur Überwachung des Befugnisses zur Ausführung der geschützten Software durch die erste privilegierte Ebene, enthaltend einen sicheren Speicher der zweiten Ebene (153) und Operationsbefehle der zweiten Ebene (152), welche gegen Zugriff und Veränderung durch den Benutzer oder irgendeinen Autor von geschützter Software gesichert sind;

daß die geschützte Software, wie sie entsprechend Schritt

c) verteilt wird, durch den Coprozessor ausführbar ist, aber nur über die Ermächtigung durch die zweite privilegierte Ebene;

und daß das Verfahren des weiteren die Schritte umfaßt:

f) Überprüfen der Authentizität des weiteren greifbaren Elementes durch den Coprozessor auf der zweiten privilegierten Ebene;

g) Verändern des sicheren Speichers der zweiten Ebene auf eine besondere Weise, damit eine Feststellung der Authentizität des greifbaren Elementes durch die zweite privilegierte Ebene wiedergegeben wird und

h) Ausführen der geschützten Software solange, wie die Veränderung des sicheren Speichers der zweiten privilegierten Ebene erkannt wird und Ablehnen einer entsprechenden Anforderung, wenn diese Veränderung nicht vorhanden ist.

2. Verfahren nach Anspruch 1, dadurch gekenhzeichnet, daß

die Software (46), wie sie entsprechend Schritt c) verteilt wird, mindestens einen verschlüsselten Abschnitt besitzt;

die zweite privilegierte Ebene nachfolgend auf den Schritt f) Zugriff auf einen Dechiffrierschlüssel (AK) hat, und

Schritt h) bei jeder folgenden Anforderung des Benutzers nach Ausführung der geschützten Software die folgenden Schritte ausführt:

Reagieren auf der zweiten privilegierten Ebene, um die Veränderung des sicheren Speichers der zweiten Ebene zu überprüfen, und wenn diese Veränderung vorhanden ist, Anerkennen der Programmanforderung durch:

a) Starten der Entschlüsselung der geschützten Software und Speichern der entschlüsselten Software im sicheren Speicher der ersten Ebene,

b) Erteilen der Befugnis zur Ausführung der entschlüsselten Software durch die erste privilegierte Ebene und Starten der Arbeit der ersten privilegierten Ebene

und wenn diese Veränderung nicht vorhanden ist, Ablehnen der Programmanforderung.

3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die geschützte Software (46), wie sie in Schritt c) verteilt wird, einen Abschnitt enthält, der mittels eines Softwareschlüssels chiffriert worden ist, welcher wiederum selbst mit einem anderen Schlüssel verschlüsselt verteilt wird und wobei die zweite privilegierte Ebene Zugriff auf diesen anderen Schlüssel hat, so daß der verschlüsselte Softwareschlüssel durch die zweite privilegierte Ebene entschlüsselt werden kann, und wobei dar Schrift g) enthält:

1) Entschlüsseln des Softwareschlüssels mit dem zweiten Schlüssel und

2) Verändern des sicheren Speichers der zweiten privilegierten Ebene dadurch, daß der Softwareschlüssel dort eingeschrieben wird.

4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß das zusammengesetzte Datenverarbeitungssystem mit Informationen versehen wird, mit denen das greifbare Element überprüft werden kann, und wobei der Schritt d) enthält:

1) Versehen des greifbaren Elementes mit physischen Sicherheitsvorkehrungen;

2) Versehen des greifbaren Elementes mit einem elektronischen Speicher, der eine zerstörende Lesefunktion besitzt, und

3) Speichern einer überprüfbaren Einheit in dem elektronischen Speicher.

5. Verfahren nach den Ansprüchen 1 bis 4, dadurch gekennzeichnet, daß die Ausführung der geschützten Software (46) nur dann gestattet wird, wenn eine Bedingung erfüllt ist, wobei das Verfahren weiterhin folgende Schritte umfaßt:

a) Bereitstellen einer Anweisung mit mindestens einer Bedingung für den Coprozessor ;

b) Bereitstellen von mit dieser Bedingung verbundenen Daten zum Speichern in dem sicheren Speicher zusammen mit dem Speichern des Softwareschlüssels;

c) Anweisen des Coprozessors, vor jeder Erteilung einer Befugnis zur Nutzung des Softwäreschlüssels oder der geschützten Software auf die Anweisung und die Daten zuzugreifen, und

d) des weiteren Anweisen des Coprozessors, die Anweisung und die Daten zu vergleichen, um daraus zu bestimmen, ob die Bedingung erfüllt ist, und Erteilen der Benutzungsbefugnis nur dann, wenn die Bedingung erfüllt ist.

6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß

e) die Anweisung eine Benutzungsbefugnis zur Ausführung der geschützten Anwendung nicht häufiger als N-mal repräsentiert, wobei N eine ganze Zahl ist;

f) die Daten des sicheren Speichers entweder einen Zählerstand C repräsentieren, der jedes Mal erhöht wird, wenn der Coprozessor die Befugnis zur Ausführung der geschützten Software erteilt, oder aber die ganze Zahl N, die jedes Mal verringert wird, wenn der Coprozessor die Befugnis zur Ausführung der geschützten Software erteilt, und

g) der Coprozessor entweder C mit N oder N mit Null vergleicht und daß der Coprozessor die Befugnis zur Ausführung nur dann erteilt, wenn N > C oder N > 0 ist.

7. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß

e) die Anweisung eine Benutzungsbefugnis zur Ausführung der geschützten Software bis zu einem Zeitpunkt repräsentiert, an dem das momentane Datum und/oder die Zeit ein Beendigungsdatum und/oder eine Beendigungszeit erreicht;

f) die Daten des Sicherungsspeichers ein Beendigungsdatum und/oder eine Beendigungszeit repräsentieren, ünd

g) der Coprozessor das momentane Datum und/oder die Zeit mit dem Beendigungsdatum und/oder der Beendigungszeit vergleicht und die Befugnis zur Ausführung nur dann erteilt, wenn das momentane Datum und/oder die Zeit vor dem Beendigungsdatum und/oder der Beendigungszeit liegen.