DE102014113441A1

DE102014113441A1 - Schutz vor Software-Komponenten mittels Verschlüsselung

Info

Publication number: DE102014113441A1
Application number: DE102014113441.9A
Authority: DE
Inventors: Chee How Tan; Sergio Rossi
Original assignee: Infineon Technologies Austria AG
Current assignee: Infineon Technologies Austria AG
Priority date: 2014-09-17
Filing date: 2014-09-17
Publication date: 2016-03-17

Abstract

Es wird ein System zum Schutz von Software gegen unautorisierte Verwendung beschrieben. Gemäß einem Beispiel der Erfindung umfasst das System ein Zielgerät, welches einen geheimen Schlüssel speichert, und eine Toolchain, welche Software-Tools zur Entwicklung von Software und Erzeugung von ausführbaren Binärcode enthält, der auf dem Zielgerät ausgeführt werden soll. Die Software-Tools der Toolchain sind dazu ausgebildet, Code-Dateien vor der Speicherung zu verschlüsseln und gespeicherten Code zu entschlüsseln. Eines der Software-Tools ist dazu ausgebildet, Binärcode, der auf dem Zielgerät ausgeführt werden soll, mittels eines öffentlichen Schlüssels, der mit dem geheimen Schlüssel korrespondiert, zu verschlüsseln und den verschlüsselten Binärcode in das Zielgerät oder in einen von dem Zielgerät verwendeten Speicher hochzuladen. Das Zielgerät ist dazu ausgebildet, den verschlüsselten Binärcode mittels des geheimen Schlüssels vor der Ausführung des Binärcodes zu entschlüsseln.

Description

TECHNISCHES GEBIET
Die vorliegende Offenbarung betrifft ein System und ein Verfahren zum Schutz von Softwarekomponenten wie z.B. Quellcode, Objekt-Code und ausführbaren Binärcode vor unautorisierter Benutzung.
HINTERGRUND
Heutzutage wird eine große Mehrheit der elektronischen Geräte mittels programmierbarer Prozessoren (z.B. Mikrocontroller, digitale Signalprozessoren, etc.) gesteuert, welche geeignete Software ausführen. Abhängig vom Produkt befindet sich in den Softwarekomponenten ein signifikanter Anteil an Knowhow, und in der Produktentwicklung werden signifikante Bemühungen für die Softwareentwicklungen aufgewendet. Die während des Produktentwicklungsprozesses entwickelte Software kann für den Eigentümer folglich ein wertvolles Kapital darstellen.
Aus diesem Grund sind Softwarekomponenten (z.B. Quellcode, Objektcode, vorkompilierte Bibliotheken, ausführbarer Binärcode, Firmware, etc.) wertvolle Geschäftsgeheimnisse; unautorisierte Benutzung der Software (z.B. durch einen Wettbewerber oder beliebige andere Dritte) kann es unautorisierten Dritten ermöglichen, externes Knowhow von dem rechtmäßigen Eigentümer der Software wirksam zu einzusetzen. In dieser Hinsicht soll der Begriff „unautorisierte Verwendung“ alle Verwendungsarten abdecken, die von dem rechtmäßigen Eigentümer der Software nicht erwünscht oder genehmigt wurden, inklusive Diebstahl, jegliche Art der Modifikation, Wiederverwendung, etc.
Um den Diebstahl der Software zu vermeiden, haben Hersteller versucht, den physischen Zugang zu dem (nicht-flüchtigen) Speicher, in dem ausführbare Softwarekomponenten (z.B. Firmware) gespeichert sind, zu beschränken. Das kann einen Download der Software von einem elektronischen Gerät schwieriger machen, jedoch verhindert es nicht zuverlässig die Extraktion der Software (Firmware) aus dem Gerät durch Dritte; es ist folglich keine sichere Maßnahme um die unautorisierte Wiederverwendung von Software zu verhindern.
Quellcode ist üblicherweise designed, um die Portabilität der Software von einem Zielgerät (target device) auf ein anderes zu ermöglichen oder zu vereinfachen. Anders als ausführbarer Binärcode ist Quellcode üblicherweise nicht an eine bestimmte Hardware (ein Zielgerät) gebunden und kann in Verbindung mit einer großen Vielfalt von Zielgeräten verwendet werden. Folglich hat der Schutz von Quellcode eine besondere Relevanz.
Es besteht ein allgemeiner Bedarf an der Zurverfügungstellung eines Systems und dazu in Beziehung stehenden Verfahren zum verbesserten Schutz von Softwarekomponenten gegen unautorisierte Wiederverwendung.
ZUSAMMENFASSSUNG
Es wird ein System zum Schutz von Software gegen unautorisierte Verwendung beschrieben. Gemäß einem Beispiel der Erfindung umfasst das System ein Zielgerät, welches einen geheimen Schlüssel speichert, und eine Toolchain, welche Software-Tools zur Entwicklung von Software und Erzeugung von ausführbaren Binärcode enthält, der auf dem Zielgerät ausgeführt werden soll. Die Software-Tools der Toolchain sind dazu ausgebildet, Code-Dateien vor der Speicherung zu verschlüsseln und gespeicherten Code zu entschlüsseln. Eines der Software-Tools ist dazu ausgebildet, Binärcode, der auf dem Zielgerät ausgeführt werden soll, mittels eines öffentlichen Schlüssels, der mit dem geheimen Schlüssel korrespondiert, zu verschlüsseln und den verschlüsselten Binärcode in das Zielgerät oder in einen von dem Zielgerät verwendeten Speicher hochzuladen. Das Zielgerät ist dazu ausgebildet, den verschlüsselten Binärcode mittels des geheimen Schlüssels vor der Ausführung des Binärcodes zu entschlüsseln.
KURZE BESCHREIBUNG DER ABBILDUNGEN
Die Erfindung lässt sich anhand der folgenden Beschreibungen und Abbildungen besser verstehen. Die in den Figuren dargestellten Komponenten sind nicht notwendigerweise maßstabsgetreu; vielmehr wird Wert darauf gelegt, die der Erfindung zugrunde liegende Prinzipien darzustellen. Des Weiteren bezeichnen gleiche Bezugszeichen in den Figuren korrespondierende Teile. In den Abbildungen:
1 illustriert die Anwendung eines beispielhaften Verfahrens zur verschlüsselten Programmierung eines Zielgeräts gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
2 illustriert die Anwendung eines weiteren beispielhaften Verfahrens zur verschlüsselten Programmierung eines Zielgeräts gemäß einem weiteren Ausführungsbeispiel der vorliegenden Erfindung;
3 illustriert einige Komponenten eines beispielhaften Zielgeräts, welches verwendet wird, um in dem Zielgerät gespeicherten, verschlüsselten Programmcode zu entschlüsseln und auszuführen;
4 illustriert in einem Flussdiagramm die Bootsequenz des Zielgeräts gemäß 3; und
5 fasst in einem Flussdiagramm die Verwendung der Toolchain aus 1 zur Softwareentwicklung und Programmierung des Zielgerätes zusammen.
DETAILIERTE BESCHREIBUNG
Um die Softwareentwicklung für ein bestimmtes Target-Device wie z.B. einen Microcontroller, einen digitalen Signalprozessor oder ein beliebiges anderes programmierbares Bauelement zu erleichtern stellen der Originalhersteller (original equipment manufacturer, OEM) oder ein Dritter üblicherweise eine so-genannte „Toolchain“ zur Verfügung. Im Allgemeinen umfasst eine Gruppe von Programmierwerkzeugen, die zur Erstellung eines Softwareprodukts (z.B. ausführbaren Programmcode) verwendet werden können. Die Programmierwerkzeuge werden typischerweise nacheinander (d.h. in einer Kette, chain) verwendet, sodass der Output eines jeden Werkzeugs zum Input für das nächste wird. Jedoch kann der Begriff Toolchain auch allgemein eine gruppe von Programmierwerkzeugen bezeichnen, welche zur Softwareentwicklung verwendet werden können und zur Erbringung einer bestimmten Funktionalität zusammenwirken.
Einfache Toolchains umfassen zumindest einen Compiler oder einen Assembler. Moderne Toolchains umfassen typischerweise jedoch einen Compiler zur Übersetzung von in einer höheren Programmiersprache (wie z.B. C, C++, Java und dgl.) geschriebenem Code in Objektcode sowie einen Linker, der eine oder mehrere Dateien mit Objektcode und (optional) zusätzliche Softwarebibliotheken verbindet, um ausführbaren Programmcode zu erzeugen. Die zuvor erwähnten Softwarebibliotheken können auch in der Toolchain enthalten sein; sie sind üblicherweise vorkompilierte Standardsoftwareroutinen, die aufgerufen werden können, wenn das Zielgerät in Betrieb ist. Des Weiteren kann eine Toolchain Softwaretools enthalten wie z.B. einen Texteditor zum Schreiben von Quellcode, einen Debugger, einen (In-Circuit-)Emulator, etc.
In den hier beschriebenen Beispielen kommt sowohl in der zur Softwareentwicklung verwendeten Toolchain als auch in dem Zielgerät Verschlüsselung zum Einsatz. Die Kombination von beidem, Verschlüsselung in der Toolchain und dem Zielgerät, macht den gesamten Prozess (d.h. die Softwareentwicklung, die nachfolgende Speicherung und Verteilung der Software und die Programmierung des Zielgeräts) sicher im Hinblick auf eine unautorisierte Wiederverwendung der Software.
Gemäß den vorliegenden Beispielen, kann ein asymmetrisches Kryptosystem (auch als „Public-Key-Kryptosystem“ bezeichnet) zur Sicherung der Software in der Toolchain und dem Zielgerät verwendet werden. Asymmetrische Kryptosysteme betreffen eine Klasse von kryptographischen Algorithmen, welche zwei separate Schlüssel benötigen. Einer der beiden Schlüssel ist gemein (auch als „privat“ bezeichnet) und der andere ist öffentlich. Obwohl sie unterschiedlich sind, sind der öffentliche Schlüssel und der korrespondierende private Schlüssel mathematisch verbunden. Der öffentliche Schlüssel kann zur Verschlüsselung von Daten oder zur Verifizierung von digitalen Signaturen verwendet werden, wohingegen der private Schlüssel zur Entschlüsselung von verschlüsselten Daten oder zur Erzeugung einer digitalen Signatur verwendet werden kann. Der Begriff „asymmetrisch“ bezieht sich auf die Verwendung zweier unterschiedlicher Schlüssel, um diese komplementären Funktionen umzusetzen. Im Gegensatz dazu kommt in einem symmetrischen Kryptosystem für die Ver- und Entschlüsselung von Daten der gleiche Schlüssel zum Einsatz.
Asymmetrische Kryptosysteme stützen sich auf die Tatsache, dass es gegenwärtig sehr schwierig ist (rechnerisch unmöglich) einen ordnungsgemäß erzeugten privaten Schlüssel aus seinem korrespondierenden öffentlichen Schlüssel zu ermitteln. Der öffentliche Schlüssel kann daher veröffentlicht werden ohne die Sicherheit zu gefährden, wohingegen der private Schlüssel niemandem preisgegeben werden darf, der nicht zur Entschlüsselung geschützter (d.h. verschlüsselter) Daten oder zur Erzeugung digitaler Signaturen autorisiert ist. Asymmetrische Kryptosysteme benötigen, anders als symmetrische Kryptosysteme, keinen anfänglichen sicheren Austausch von einem oder mehreren geheimen Schlüsseln zwischen den Beteiligten.
1 illustriert ein einfaches Beispiel eines Verfahrens zur sicheren Programmierung eines Zielgeräts; das Beispiel umfasst die sichere Entwicklung von Software, das sichere Hochladen des Binärcodes (ausführbarer Programmcode) auf das Zielgerät sowie die sichere Speicherung des Binärcodes in dem Zielgerät. Gemäß dem Beispiel aus 1 verwendet der Softwareingenieur 10 einen bestimmten öffentlichen Schlüssel für den Zugang zur Toolchain 20, welche zur Entwicklung von Software für das Zielgerät 30 verwendet wird. Die Programmierwerkzeuge der Toolchain 20 werden üblicherweise auf einem Standard-Personal-Computer ausgeführt. Der Softwareingenieur 10 kann einen in der Toolchain 20 enthaltenen Quellcodeeditor 10 zum Schreiben von Quellcode verwenden, sowie einen Compiler und einen Linker zum Erzeugen von Binärcode (d.h. Objektcode und ausführbaren Programmcode). Gemäß dem hier beschriebenen Ausführungsbeispiel ist die Toolchain eine vollintegrierte Softwareentwicklungsumgebung, welche das Kopieren von Quellcode hin zu Programmen außerhalb der Toolchain nicht zulässt. Beispielsweise ist die Kopieren/Einfügen-(Copy/Paste)Funktion, die in fast allen Betriebssystemen zur Verfügung steht, deaktiviert. Das Kopieren von Quellcode hin zu Programmen von Drittanbietern mittels der Kopieren/Einfügen-Funktion wird verhindert. Jedes Mal, wenn Code (Quellcode, Objektcode, ausführbarer Programmcode) in eine Datei auf einem nicht-flüchtigen Speicher (z.B. einer Festplatte eines PCs) gespeichert wird, verschlüsselt der Softwareingenieur 10 den Code mittels des zuvor erwähnten öffentlichen Schlüssels. Jeglicher Code wird verschlüsselt, unabhängig davon, ob er in einer temporären oder einer permanenten Datei gespeichert wird. Ein korrespondierender privater Schlüssel kann zur Entschlüsselung des verschlüsselten Codes verwendet werden jedes Mal, wenn eine Entschlüsselung nötig ist, um in dem Softwareentwicklungsprozess voranzukommen (z.B. vor dem Kompilieren des Quellcodes oder wenn man in die Toolchain einloggt, um die Arbeit am Quellcode fortzusetzen). Der private Schlüssel kann z.B. in einer Smart-Card gespeichert und zusätzlich passwortgeschützt sein. Alternativ kann der private Schlüssel auf einer Massenspeichereinrichtung gespeichert sein, welches für den Personal-Computer, der die Toolchain ausführt, zugänglich ist. In diesem Fall wird der Passwortschutz des privaten Schlüssels dringend empfohlen. Das Konzept, jeglichen Code for dessen Speicherung zu verschlüsseln stellt sicher, dass Dateien, die Code enthalten, für unautorisierte Personen (z.B. im Falle einer unautorisierten Kopie) unbrauchbar sind, solange nicht auch der private Schlüssel gestohlen wird. Wie oben erwähnt können die in der Toolchain 20 enthaltenen Programmierwerkzeuge dazu ausgebildet sein, das Kopieren von Text (Quellcode) hin zu anderen Texteditoren oder Textverarbeitungsprogrammen mittels der Verwendung der üblichen Kopieren/Einfügen-Funktion des Betriebssystems zu verhindern. Für unterschiedliche Softwareentwicklungsprojekte, unterschiedliche Software-Entwickler 10 oder unterschiedliche Teams von Softwareentwicklern können separate Paare öffentlicher und privater Schlüssel verwendet werden.
Der einzige Weg, um eine unautorisierte Kopie des Quellcodes zu bekommen, würde es erfordern, dass eine Person einen Screenshot oder eine Fotographie des Bildschirms macht, auf dem eine Seite Code angezeigt wird und den Text mittels OCR (optical character recognition, optische Zeichenerkennung) ermittelt. Dies ist jedoch ein sehr mühsamer Weg, Quellcode zu stehlen, der aus hunderten oder tausenden Seiten Text besteht. Des Weiteren scheint es sehr unwahrscheinlich, dass ein solcher Versuch unentdeckt bliebe; dies ist daher ein eher theoretisches Szenario.
Wie oben erwähnt ist die Verschlüsselung von Code, die bei der Softwareentwicklung in der Toolchain 20 verwendet wird, nur ein Aspekt des vorliegenden in 1 gezeigten Beispiels. Gemäß einem zweiten Aspekt wird Verschlüsselung, wie unten erklärt, auch in dem Zielgerät 30 verwendet. Zu diesem Zweck wird von dem OEM oder einem vertrauenswürdigen Dritten (z.B. dem für den Kunden zuständigen Distributor oder Lieferanten, etc.) ein kundenspezifischer privater Schlüssel K_SEC auf das Zielgerät hochgeladen. Der kundenspezifische private Schlüssel K_SEC kann in einem einmalig programmierbaren (one time programmable, OTP) Speicher oder einem anderen, in dem Zielgerät 30 enthaltenen, nicht-flüchtigen Speicher (non-volatile memory, NVM) programmiert werden. Dieser NVM kann hardwaremäßig lesegeschützt, so dass ein herunterladen des geheimen Schlüssels von dem Zielgerät 30 unmöglich oder zumindest nur sehr schwer zu bewerkstelligen ist. The korrespondierende kundenspezifische öffentliche Schlüssel K_PUB wird wie oben diskutiert zusammen mit der Toolchain 20 vertrieben. Die Toolchain 20 umfasst ein Software-Tool zum hochladen von ausführbaren Programmcode BIN (Binärcode) auf das Zielgerät 20. Jedoch wird durch das Software-Tool sichergestellt, dass ausführbarer Programmcode BIN mittels des kundenspezifischen öffentlichen Schlüssels K_PUB verschlüsselt wird, bevor dieser auf das Zielgerät hochgeladen und in dem nicht-flüchtigen Programmspeicher des Zielgeräts 30 gespeichert wird. Das Zielgerät 30 ist dazu ausgebildet, den gespeicherten verschlüsselten Programmcode BIN vor der Ausführung zu entschlüsseln. Der entschlüsselte Programmcode BIN ist jedoch nur in dem (flüchtigen) Arbeitsspeicher (Random-Access Memory, RAM) des Zielgeräts verfügbar und verlässt das Zielgerät 30 nie. Da die Schlüssel K_SEC und K_PUB kundenspezifisch sind, kann Programmcode, der mit dem öffentlichen Schlüssel eines bestimmten Kunden verschlüsselt wurde, nicht mit einem Zielgerät entschlüsselt werden, das mit dem privaten Schlüssel eines anderen Kunden ausgestattet ist. Jeder größere Kunde (oder Distributor) kann mit einem Zielgerät beliefert werden, das einen vorprogrammierten, kundenspezifischen privaten Schlüssel enthält. Dieses Vorprogrammieren wird üblicherweise durch den OEM oder einem vertrauenswürdigen Dritten (z.B. einem vertrauenswürdigen Distributor) vorgenommen.
In vielen Anwendungen hängt das Verhalten der in dem Zielgerät 30 ausgeführten Software von Parametern ab, die nicht in dem Programmcode BIN enthalten sind, sondern separat als Eingangsparameter, die von dem Programmcode während der Ausführung verwendet werden, zur Verfügung gestellt werden. Eine beispielhafte Kategorie von Anwendungen sind digitale Regler, welche mit einem generischen Reglerprogrammcode programmiert werden können, der für eine bestimmte Gruppe von Regelungsanwendungen verwendet wird, wobei eine bestimmte Menge von Regelungsparametern PAR, die von dem generischen Programmcode verwendet wird, separat für die bestimmte Anwendung bereitgestellt wird. In einem einfachen Beispiel kann der ausführbare Programmcode einen digitalen PID-Regelungsalgorithmus (PID = proportional-integral-derivative) repräsentieren, der die Verstärkungswerte G_P, G_I und G_D für den proportionalen (P), den integrierenden (I) bzw. den differenzierenden (D) Anteil des Regelungsalgorithmus verwendet. Diese Verstärkungswerte können in der Menge von Regelungsparametern PAR enthalten sein. Durch Anpassen der Regelungsparameter PAR kann das Zielgerät als PID-Regler für eine große Auswahl an Anwendungen verwendet werden, ohne den ausführbaren Programmcode BIN ändern zu müssen. Diese Situation ist in dem Beispiel gemäß 2 dargestellt. Das Beispiel gemäß 2 ist im Wesentlichen identisch mit dem vorhergehenden Beispiel aus 1 mit der zusätzlichen Fähigkeit, in dem Zielgerät eine Menge von Parametern PAR verschlüsselt zu speichern. Für die folgende Diskussion wird angenommen, dass verschlüsselter Binärcode BIN bereits auf das Zielgerät hochgeladen wurde wie unter Bezugnahme auf 1 erläutert. Ein Produktingenieur hat Zugang zu einer Benutzerschnittstelle (User Interface, UI), welche an einem Personal-Computer das Setzen oder Anpassen von einem oder mehreren Parametern aus der Menge von Parametern ermöglicht. Die UI 40 ist ein Computerprogramm, das auf einem Personal-Computer ausgeführt wird, wie die oben erwähnte Toolchain 20. Die UI kann von dem OEM des Zielgeräts oder irgendeinem vertrauenswürdigen Dritten (Lieferanten und Distributoren) bereitgestellt werden. Die UI ist dazu ausgebildet, Parameter PAR in den nicht-flüchtigen Speicher, der in dem Zielgerät inkludiert sein kann, hochzuladen. Der Speicher kann jedoch auch extern und nicht in dem Zielgerät 30 enthalten sein. Gemäß dem vorliegenden Beispiel werden die Parameter auch mit dem kundenspezifischen öffentlichen Schlüssel K_PUB, der mit dem permanent in das Zielgerät programmierten privaten Schlüssel K_SEC korrespondiert, verschlüsselt (bevor sie auf das Zielgerät oder den externen Speicher hochgeladen werden). Demnach ist die endgültige Menge von Parametern PAR ebenfalls gesichert, wenn sie mit dem Zielgerät 30 ausgeliefert werden. Die UI kann dazu ausgebildet sein, Parametermengen zu verschlüsseln, bevor diese lokal auf dem Personal-Computer gespeichert werden in der gleichen Weise wie die Toolchain Quellcode mit behandelt, der wie oben diskutiert ebenfalls vor dem Speichern verschlüsselt wird.
Im vorliegenden Beispiel wird zum Verschlüsseln und Entschlüsseln von Binärcode BIN und Parameter PAR dasselbe Paar aus öffentlichem und privatem Schlüssel K_SEC und K_PUB verwendet. Jedoch können auch unterschiedliche Schlüsselpaare für diese Zwecke verwendet werden. In diesem Fall müssten zwei geheime Schlüssel in das Zielgerät 30 einprogrammiert sein. Wie oben erwähnt ist die Toolchain 20 dazu ausgebildet, alle codebezogenen Dateien in verschlüsselter Form zu speichern. Diese Verschlüsselung/Entschlüsselung kann durch die Verwendung eines separaten Paars aus öffentlichem und privatem Schlüssel erfolgen, die sich von den Schlüsseln K_SEC und K_PUB zur Verschlüsselung des Binärcodes vor dem Hochladen auf das Zielgerät 30 unterscheiden.
3 illustriert einige relevante Komponenten des Zielgerätes 30 detaillierter. Das Zielgerät 30 kann beispielsweise ein Mikrocontroller (µC), ein digitaler Signalprozessor (DSP), ein beliebiger anderer Mikroprozessorbaustein, eine programmierbare Logik (field-programmable gate array [FPGA]) oder eine andere fest-verdrahtete Logik wie z.B. ein endlicher Automat oder ähnliches sein. Im vorliegenden Beispiel ist das Zielgerät ein Mikrocontroller, der eine zentrale Recheneinheit 31 (Central Processing Unit, CPU) aufweist sowie Random-Access-Speicher 32 (Random Access Memory, RAM), Nur-Lese-Speicher 34 (Read-Only Memory, ROM), in dem Bootloader-Programmcode BL gespeichert ist, nicht-flüchtigen Speicher 33 (z.B. lesegeschütztes OTP NVM), in dem der kundenspezifische private Schlüssel K_SEC gespeichert ist, und einen weiteren nicht-flüchtigen Speicher 35 (z.B. einen elektrisch löschbaren programmierbaren Nur-Lese-Speicher, EEPROM), in dem der verschlüsselte Binärcode BIN und die verschlüsselten Parameter PAR gespeichert sind. All diese Komponenten können in einem einzigen Chip oder Chipgehäuse (chip package) integriert sein. Der nicht-flüchtige Speicher 35 kann jedoch in einem separaten Chip integriert sein. Des Weiteren kann auch das ROM 34 als separater Baustein vorgesehen sein. In eine anderen Beispiel kann der Bootloader-Programmcode BL in einem Teil des nicht-flüchtigen Speichers 35 gespeichert sein. Um verschlüsselten Binärcode BIN und verschlüsselte Parameter PAR zu speichern, können auch verschiedene Speicherbausteine können verwendet werden.
4 illustriert mittels eines Flussdiagramms ein Beispiel einer Boot-sequenz des Zielgerätes 30 aus 3. Beim Hochfahren lädt die CPU 31 die in dem Bootloader-Programmcode BL definierten Instruktionen aus dem ROM 34 und führt das Bootloader-Programm aus (Schritt 50). Die tatsächlichen Mechanismen zum Laden uns Ausführen des Bootloader-Programmcodes können für verschiedene Typen von Zielgeräten unterschiedlich sein. Das Bootloader-Programm ist dazu ausgebildet, den kundenspezifischen privaten Schlüssel KSEC aus dem NVM 33 zu lesen (Schritt 51) und ihn zu verwenden, um den Binärcode BIN, der aus dem EEPROM 35 gelesen wird, zu entschlüsseln und den entschlüsselten Binärcode im RAM 32 zu speichern (Schritt 52). In ähnlicher Weise werden die verschlüsselten Parameter PAR aus dem EEPROM gelesen und werden unter Verwendung des privaten Schlüssels K_SEC entschlüsselt und in dem RAM 32 gespeichert (Schritt 53). Schließlich initiiert das Bootloader-Programm die Ausführung des entschlüsselten, im RAM 32 gespeicherten Binärcodes (Schritt 54).
5 ist ein Flussdiagramm, das die Verwendung der Toolchain 20 (siehe 1) zusammenfasst. Wie unter Bezugnahme auf 1 und 2 diskutiert, wird die Toolchain 20 zur Entwicklung von Software und zur Programmierung des Zielgerätes 30 verwendet. Ein Nutzer (Softwareingenieur 10; siehe 1) authentifiziert sich an der Toolchain 20 (z.B. einem Nutzermanagement-Modul der Toolchain). Die Authentifizierung kann beispielsweise mittels eines Passworts erfolgen (Schritt 60). Im Falle, dass der Nutzer an einem zuvor gespeicherten Quellcode weiterarbeiten möchte, müssen die relevanten Quellcode-Dateien mit dem geheimen Schlüssel K_SEC,TC der Toolchain 20 entschlüsselt werden, der von dem kundenspezifischen geheimen Schlüssel K_SEC, der in das Zielgerät 30 einprogrammiert ist, verschieden sein kann (jedoch nicht sein muss) (Schritt 61). Der geheime Schlüssel K_SEC,TC kann beispielsweise in einer Smartcard gespeichert sein, die in ein korrespondierendes Smartcard-Lesegerät eingeführt ist, das mit dem Personal-Computer, auf dem die Toolchain 20 ausgeführt wird, verbunden ist. Gemäß einem weiteren Ausführungsbeispiel ist der geheime Schlüssel K_SEC,TC in der ausführbaren Programmdatei (.exe-Datei in MS Windows-Umgebungen) des Toolchain-Programms, das auf dem Personal-Computer ausgeführt wird, enthalten (versteckt). Sobald ein zuvor gespeicherter Quellcode entschlüsselt wurde, kann der Nutzer an dem Quellcode arbeiten (d.h. den existierenden Code ändern oder neuen Code hinzufügen [Schritt 62]). Von Zeit zu Zeit könnte der Nutzer einer Speicherung der aktuellen Version des Quellcodes wollen. Wie bereits erwähnt wird der Quellcode vor der Speicherung in einem beliebigen nicht-flüchtigen Speicher wie z.B. der Festplatte des Personal-Computers verschlüsselt (Schritt 63). Der öffentliche Schlüssel K_PUB,TC, der von der Toolchain 20 für die Verschlüsselung verwendet wird, korrespondiert mit dem zuvor erwähnten geheimen Schlüssel K_SEC,TC. Im Fall, dass der Nutzer nach der Speicherung seiner/ihrer Arbeit ausloggt (Schritt 69), kann ein neuer Nutzer vor der Fortsetzung der Arbeit authentifiziert werden.
Die Toolchain 20 ermöglicht es dem Nutzer, den Quellcode zu kompilieren und Binärcode zu erzeugen, welcher auf dem Zielgerät 30 ausführbarer Programmcode ist (Schritt 64). Jedoch wird der Binärcode in keinem nicht-flüchtigen Speicher (wie z.B. der Festplatte des Personal-Computers) gespeichert, sofern er nicht unter Verwendung des öffentlichen Schlüssels K_PUB,TC verschlüsselt worden ist (Schritt 65). Wie bereits erwähnt kann die Toolchain 20 Software-Tools zur Simulation der Ausführung des erzeugten Binärcodes (zum Zwecke des Testens) und zum Debugging enthalten (Schritt 68). Zum Hochladen des Binärcodes auf das Zielgerät wird dieser mittels des öffentlichen Schlüssels K_PUB verschlüsselt (Schritt 66), der mit dem kundenspezifischen geheimen Schlüssel K_SEC korrespondiert, der in das Zielgerät (siehe auch 3) einprogrammiert ist. Verschlüsselter Binärcode BIN kann gespeichert und auf das Zielgerät 30 hochgeladen werden (Schritt 67).
Der öffentliche und der private Schlüssel K_PUB,TC und K_SEC,TC, die von den Software-Tools der Toolchain 20 verwendet werden, können die gleichen sein wie die der öffentliche und der private Schlüssel K_PUB, K_SEC, die zur Verschlüsselung und Entschlüsselung der Binärdateien, die auf das Zielgerät hochgeladen und von diesem ausgeführt werden sollen, verwendet werden. Kein Quellcode oder Binärcode (Objektcode, Binärbibliotheken, ausführbarer Programmcode) wird gespeichert, sofern er nicht zuvor entweder mit dem öffentlichen Schlüssel K_PUB,TC der Toolchain oder durch den kundenspezifischen öffentlichen Schlüssel K_PUB verschlüsselt wurde. Die Software-Tools der Toolchain 20 können jedoch ausnahmsweise die Speicherung von unverschlüsseltem Code (Quellcode oder Binärcode) zulassen, sofern der Nutzer als Administrator authentifiziert ist.
Eine weniger sichere Alternative zur Verschlüsselung von Binärcode vor dem Hochladen auf das Zielgerät besteht in dem Hinzufügen einer digitalen Signatur zu dem Binärcode. Die digitale Signatur kann mittels des privaten Schlüssel K_SEC, der in das Zielgerät 30 einprogrammiert ist, verifiziert werden. Der Bootloader ist dazu ausgebildet, die Ausführung des Binärcodes zu verweigern, wenn die Verifizierung der digitalen Signatur fehlschlägt.
Obwohl verschiedene Ausführungsbeispiele der Erfindung beschrieben wurden, wird es für Fachleute augenscheinlich, dass viele weitere Ausführungsbeispiele und Implementierungen im Schutzbereich der Erfindung möglich sind. Demnach soll die Erfindung nicht beschränkt werden außer im Lichte der angefügten Ansprüche und deren Äquivalente. Hinsichtlich der verschiedenen Funktionen, die von den oben beschriebenen Bauelementen oder Strukturen (Baugruppen, Vorrichtungen, Schaltungen, Systemen, usw.) durchgeführt werden, sowie der Bergriffe (einschließlich eines Bezugs auf ein "Mittel"), die verwendet werden, um solche Bauelemente zu beschreiben, sollen diese, sofern nicht anders angegeben, jeglichem Bauelement oder Struktur entsprechen, die die erwähnte Funktion des beschriebenen Bauelements durchführen (d.h. die funktionell gleichwertig sind), auch wenn diese nicht der offenbarten Struktur, welche die Funktion in den hier dargestellten beispielhaften Implementierungen der Erfindung durchführen, strukturell gleich ist.

Claims

Ein System zum Schutz von Software gegen unautorisierte Verwendung; das System umfasst: ein Zielgerät, welches einen geheimen Schlüssel enthält; eine Toolchain, welche Software-Tools zur Entwicklung von Software und Erzeugung von ausführbaren Binärcode enthält, der auf dem Zielgerät ausgeführt werden soll; zumindest eines der Software-Tools der Toolchain ist dazu ausgebildet, Code-Dateien vor der Speicherung zu verschlüsseln und gespeicherte Code-Dateien zu entschlüsseln; eines der Software-Tools ist dazu ausgebildet, Binärcode, der auf dem Zielgerät ausgeführt werden soll, mittels eines öffentlichen Schlüssels, der mit dem geheimen Schlüssel korrespondiert, zu verschlüsseln und den verschlüsselten Binärcode in das Zielgerät oder in einen von dem Zielgerät verwendeten Speicher hochzuladen.; und das Zielgerät ist dazu ausgebildet, den verschlüsselten Binärcode mittels des geheimen Schlüssels vor der Ausführung des Binärcodes zu entschlüsseln.
Das System gemäß Anspruch 1, wobei das Zielgerät nicht-flüchtigen Speicher zum Speichern des geheimen Schlüssels aufweist.
Das System gemäß Anspruch 2, wobei der nicht-flüchtige Speicher ein einmalig programmierbarer Speicher (OTP) ist.
Das System gemäß Anspruch 1, das weiter einen Personal-Computer aufweist zum Ausführen der in der Toolchain enthaltenen Software-Tools; der Personal-Computer ist im Betrieb an eine Massenspeichereinrichtung zur Speicherung verschlüsselter Code-Dateien gekoppelt.
Das System gemäß Anspruch 1, wobei das Zielgerät einen nicht-flüchtigen Speicher zur Speicherung des verschlüsselten Binärcodes aufweist.
Das System gemäß Anspruch 1, das weiter aufweist: ein Softwareprogramm, das eine Benutzerschnittstelle zur Eingabe von Daten zur Verfügung stellt, die Eingangsparameter repräsentieren; das Softwareprogramm ist dazu ausgebildet, die Eingangsparameter unter Verwendung des öffentlichen Schlüssels zu verschlüsseln und die verschlüsselten Eingangsparameter auf das Zielgerät hochzuladen oder auf einen von dem Zielgerät benutzen Speicher; das Zielgerät ist dazu ausgebildet, die Eingangsparameter unter Verwendung des geheimem Schlüssels vor der Ausführung des Binärcodes zu entschlüsseln.
Das System gemäß Anspruch 6, wobei das Zielgerät einen nicht-flüchtigen Speicher zur Speicherung der verschlüsselten Eingangsparameter aufweist.
Das System gemäß Anspruch 6, wobei das Zielgerät einen ersten nicht-flüchtigen Speicher zur Speicherung des verschlüsselten Binärcodes und einen zweiten nicht-flüchtigen Speicher zur Speicherung der verschlüsselten Eingangsparameter aufweist.
Das System gemäß Anspruch 6, wobei das Softwareprogramm inklusive der Benutzerschnittstelle dazu ausgebildet ist, die Eingangsparameter in verschlüsselter Form zu speichern.
Das System gemäß Anspruch 1, wobei die Verschlüsselung und die Entschlüsselung der Code-Dateien mittels asymmetrischer Kryptographie erfolgen.
Das System gemäß Anspruch 1, wobei das Zielgerät dazu ausgebildet ist, entschlüsselten Binärcode nur in flüchtigem Speicher zu speichern, sodass er gelöscht wird, sobald das Zielgerät zurückgesetzt oder ausgeschaltet wird.
Ein Verfahren zum Schutz von Software gegen unautorisierte Verwendung; das Verfahren umfasst folgendes: Verwenden einer Toolchain, welche Software-Tools zur Entwicklung von Software und Erzeugung von ausführbaren Binärcode enthält, der auf dem Zielgerät ausgeführt werden soll, wobei zumindest eines der Software-Tools der Toolchain ist dazu ausgebildet, Code-Dateien vor der Speicherung zu verschlüsseln und gespeicherte Code-Dateien zu entschlüsseln; Verschlüsseln von Binärcode, der auf dem Zielgerät ausgeführt werden soll, mittels eines öffentlichen Schlüssels, der mit einem geheimen, in dem Zielgerät gespeicherten Schlüssel korrespondiert; Hochladen des verschlüsselten Binärcodes auf das Zielgerät oder auf einen von dem Zielgerät benutzen Speicher; und Entschlüsseln des verschlüsselten Binärcodes mittels des geheimen Schlüssels des Zielgeräts vor der Ausführung des Binärcodes.