-
Die vorliegende Erfindung betrifft ein Verfahren zum Schützen eines Gerätes. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
-
Stand der Technik
-
Als Sicherheitslücke wird auf dem Gebiet der Informationssicherheit jedweder Fehler in einer Software bezeichnet, durch welchen ein Programm mit Schadwirkung (malware) oder ein Angreifer in ein Computersystem eindringen kann.
-
Sicherheitslücken stellen eine Bedrohung für die Sicherheit eines Computersystems dar. Es besteht das Risiko, dass die betreffende Sicherheitslücke ausgenutzt und das betroffene Computersystem kompromittiert werden kann. Sicherheitslücken entstehen unter anderem durch den unzureichenden Schutz eines Computers vor Angriffen aus dem Netz (beispielsweise mangels Firewall oder anderer Sicherheitssoftware) sowie durch Programmierfehler im Betriebssystem, Webbrowser oder anderen Softwareanwendungen, die auf dem System betrieben werden.
-
DE102015225651A1 offenbart ein Verfahren zum Schützen eines Gerätes. Hierbei erzeugt ein Prüfer eine erste Zufallszahl und eine zweite Zufallszahl, errechnet anhand der zweiten Zufallszahl mittels einer emulierten oder zuvor ausgemessenen Hardwarefunktion des Gerätes einen kryptografischen Schlüssel, verschlüsselt die Software mit dem Schlüssel in ein Kryptogramm, sendet das Kryptogramm und die erste Zufallszahl an das Gerät, empfängt eine Prüfsumme von dem Gerät, errechnet anhand der ersten Zufallszahl und eines nachgebildeten Arbeitsspeichers des Gerätes mittels der emulierten oder zuvor ausgemessenen Hardwarefunktion und einer vorgegebenen kryptografischen Hashfunktion einen Bezugswert, unterzieht die Prüfsumme einer Prüfung anhand des Bezugswertes und sendet, falls die Prüfung gelingt, die zweite Zufallszahl an das Gerät.
-
Offenbarung der Erfindung
-
Die Erfindung stellt ein Verfahren zum Schützen eines Gerätes, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes maschinenlesbares Speichermedium gemäß den unabhängigen Ansprüchen bereit.
-
Der erfindungsgemäße Ansatz fußt hierbei auf der Erkenntnis, dass bekannte Sicherheitslücken oder Schwachstellen typischerweise deswegen zu einem massiven Angriff genutzt werden können, da alle Instanzen der fehlerhaften Software die gleiche Sicherheitslücke aufweisen. Dies wiederum ermöglicht es einem Angreifer, eine einzelne Datei oder anderweitige Eingabe zu erstellen, die dann verwendet werden kann, um irgendeines der anfälligen Geräte (oder alle auf einmal) anzugreifen.
-
Der nachfolgend vorgestellten Lösung liegt daher der Gedanke zugrunde, ein neuartiges Verfahren zum Härten von miteinander verbundenen Vorrichtungen gegen diese Art von massiven Angriffen zu schaffen, das die für einen Angriff erforderlichen Anstrengungen deutlich erhöht.
-
Zwei Vorzüge dieser Lösung liegen in der erhöhten Widerstandsfähigkeit erfindungsgemäß gehärteter Systeme gegen softwarebasierte Angriffe, d. h. Angriffe, die Software-Schwachstellen ausnutzen, sowie ihrem minimalen Zusatzaufwand in Bezug auf Rechenleistung, Kodeumfang und Kode-Komplexität.
-
Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So kann vorgesehen sein, dem zu schützenden Gerät zufällig den Wert eines Dateiattributes zuzuordnen, anhand derer Gerät und vorgesehene Datei individualisiert werden.
-
Angenommen, ein Hacker rekonstruiert ein auf diese Weise geschütztes Gerät bestimmten Typs, z. B. einen Haus- oder Heizungs-Controller oder eine IP-basierte Kamera. Selbst wenn er eine ausnutzbare Software-Schwachstelle findet, hindert der einzigartige, zufällig generierte Wert des Attributes ihn daran, die entdeckte Sicherheitslücke auf anderen Geräten desselben Typs auszunutzen.
-
Gemäß einem weiteren Aspekt kann vorgesehen sein, den zufällig erzeugten Attributwert in einer Datenbank dem jeweiligen Gerät zuzuordnen. Infolgedessen steigt der Aufwand des Hackers für einen erfolgreichen Angriff im Wesentlichen linear mit der Anzahl der Geräte, die er angreifen möchte. Dies folgt aus dem Umstand, dass der Hacker - sofern er die Datenbank nicht kompromittiert hat - jedes Gerät, das er anzugreifen versucht, nachentwickeln (reverse-engineer) müsste. Das wiederum bedeutet, dass jedes System, das Schwachstellen in der Software solchermaßen ausnutzt, eine schlechte Skalierbarkeit aufweist. Somit vermag eine entsprechende Ausführungsform der Erfindung insbesondere die durch Vielanfragen in cyberphysikalischen Systemen verbreitete Verweigerung von Internetdiensten (distributed denial of service, DDoS) wirkungsvoll abzuwenden.
-
Im Ergebnis lassen sich die Sicherheitsrisiken für beliebige miteinander verbundene Systeme auf die beschriebene Weise beträchtlich mindern, indem von vornherein der ökonomische Anreiz zum Angriff auf diese Systeme beseitigt wird.
-
Figurenliste
-
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
- 1 das Flussdiagramm eines Verfahrens gemäß einer Ausführungsform.
- 2 schematisch einen ersten Prozess des Verfahrens.
- 3 schematisch einen zweiten Prozess des Verfahrens.
-
Ausführungsformen der Erfindung
-
Im Folgenden wird der Begriff „Datei“ in einem weiten Sinne für die Eingabedaten eines vernetzten Gerätes verwendet. Als Beispiele für Dateien seien etwa ein Software-Update, eine Multimediadatei oder eine - möglicherweise eine Anforderung an das Gerät enthaltende - Textdatei genannt. Im Allgemeinen besteht jede Datei aus Kopfdaten und Nutzdaten. Die Nutzdaten der Datei betreffen deren eigentlichen Inhalt, z. B. ein Bild, einen Film oder einen Text. Der Kopf der Datei enthält deren sogenannte Metadaten wie ihr Format, die Version der Werkzeuge, die zu ihrer Erstellung verwendet wurden usw.
-
Ein grundlegender Aspekt der Erfindung besteht darin, eine gegebene Datei so an ein bestimmtes Gerät zu binden, dass die Datei ausschließlich auf diesem vorgesehenen Gerät korrekt verarbeitet (d. h. gelesen und interpretiert) werden kann. Eine Übersicht der hierzu vorgeschlagenen Methode ist in 1 dargestellt.
-
Aus Gründen der Einfachheit sei eine prototypische Umsetzung dieses Konzeptes nunmehr anhand eines mit Nutzerrechten ausführbaren Dateisystems (Filesystem in Userspace, FUSE) illustriert. Das Prinzip lässt sich leicht an alle anderen Dateizugriffsmechanismen anpassen. Alternative Implementierungen könnten darauf basieren, die Dateizugriffs-Programmierschnittstelle (application programming interface, API) des Gerätes zu modifizieren oder etwaige in einem ausführbaren und ladbaren Format (executable and linkable format, ELF) für den Dateizugriff vorinstallierte Bibliotheken mittels des LD_PRELOAD-Mechanismus des dynamischen Laders zu ersetzen. Eine auf assoziativer Dateiverwaltung („Datenbankdateisystem“) fußende Implementierung indes mag sich etwa gerätespezifischer SQL-Anweisungen bedienen, ohne den Rahmen der Erfindung zu verlassen.
-
FUSE im Besonderen ist eine Software-Schnittstelle für Unix-ähnliche Betriebssysteme, die nicht-privilegierten Benutzern die Erstellung eigener Dateisysteme ohne Bearbeitung des Kernel-Codes erlaubt. Erreicht wird dies durch mit Standardrechten ausgestatteten Dateisystemcode, indem das FUSE-Modul lediglich eine Brücke zu den eigentlichen Kernel-Schnittstellen schlägt.
-
Zu diesem Zweck wird für ein bestimmtes Gerät (d) ein einzigartiges Schnittstellenmodul erzeugt. Eine mögliche Realisierung dieses Schnittstellenmodules ist folgendem C-Quelltextmodul zu entnehmen:
- 1 // simple fuse filesystem expecting a fixed prefix in filename
- 2 // to open file written by Heiko Baur & Paul Duplys
- 3 #define FUSE_USE_VERSION 26
- 4 #include <fuse.h>
- 5 #include <string.h>
- 6 #include <sys/types.h>
- 7 #include <sys/stat.h>
- 8 #include <unistd.h>
- 9 #include <dirent.h>
- 10 #include <errno.h>
- 11 #include <stdio.h>
- 12 #include <stdarg.h>
- 13
- 14 // this string is used in a single device only
- 15 #define DEVICE_SPECIFIC_SECRET „ZQXklUuTLkxQzfcflJtT_“
- 16 #define SHADOW_FOLDER „/tmp/shadow“
- 17
- 18 // max file and folder length
- 19 #define MAX_CHAR 512
- 20
- 21 // helper returning the current error
- 22 #define my_error() (-errno)
- 23
- 24 static int my_getattr(const char *path, struct stat *stbuf) {
- 25 char szFile[MAX_CHAR] = {0};
- 26 if ( (strcmp(path,".")==0) || (strcmp(path,".,")==0))
- 27 return stat(path, stbuf);
- 28 if (strcmp(path,"/")==0) return stat(SHADOW_FOLDER, stbuf);
- 29 while (*path==‚/‘) path++;
- 30 sprintf(szFile, „%s/%s%s“, SHADOW_FOLDER, DEVICE_SPECIFIC_SECRET, path);
- 31 return stat(szFile, stbuf);
- 32 }
- 33
- 34 static int my_readdir(const char *path, void *buf, fuse_fill_dir_t filler,
- 35 off_t offset, struct fuse_file_info *fi) {
- 36 DIR *dp; struct dirent *dirp; char szFolder[MAX_CHAR] = {0};
- 37 sprintf(szFolder, „%s/%s“, SHADOW_FOLDER, path);
- 38 dp = opendir(szFolder);
- 39 if (dp==0) return my_error();
- 40 while ((dirp = readdir(dp)) != NULL) {
- 41 if ((strcmp(dirp->d_name,".")==0) || (strcmp(dirp->d_name,".,")==0)){
- 42 filler(buf, dirp->d_name, NULL, 0);
- 43 }else{
- 44 if (strncmp(dirp->d_name, DEVICE_SPECIFIC_SECRET, strlen(DEVICE_SPECIFIC_SECRET))==0)
- 45 filler(buf, &dirp->d_name[strlen(DEVICE_SPECIFIC_SECRET)], NULL, 0);
- 46 }
- 47 }
- 48 closedir(dp);
- 49 return 0;
- 50 }
- 51
- 52 static int my_open(const char *path, struct fuse_file_info *fi) {
- 53 char szFile[MAX_CHAR] = {0};
- 54 while(*path==‚/‘) path++;
- 55 sprintf(szFile, „%s/%s%s“, SHADOW_FOLDER, DEVICE_SPECIFIC_SECRET, path);
- 56 if ((fi->fh = open(szFile, fi->flags))<0)
- 57 return my_error();
- 58 return 0;
- 59 }
- 60
- 61 static int my_read(const char *path, char *buf, size_t size, off_t offset,
- 62 struct fuse_file_info *fi) {
- 63 if (lseek(fi->fh,offset,SEEK_SET)==-1) return my_error();
- 64 return read(fi->fh,buf,size);
- 65 }
- 66
- 67 // override the user functions for the fiesystem
- 68 static struct fuse_operations fuse_example_operations = {
- 69 .getattr = my_getattr, .open = my_open,
- 70 .read = my_read, .readdir = my_readdir,
- 71 };
- 72
- 73 // delegate main call to libfuse
- 74 int main(int argc, char *argv[]){
- 75 return fuse_main(argc, argv, &fuse_example_operations, NULL);
- 76 }
-
Diese Implementierung akzeptiert nur Dateien, deren Namen ein bestimmtes (eindeutiges) zufälliges Präfix - im vorliegenden Beispiel die Zeichenkette „ZQXklUuTLkxQzfcflJtT“ - aufweisen. Nur Dateien mit derartigen Dateinamen werden so in dieser Ausgestaltung des Schnittstellenmodules als gültig anerkannt.
-
Die Wirkung dieser Umsetzung ist der folgenden Sequenz von Unix-Kommandozeilen und der hierdurch hervorgerufenen Standardausgabe zu entnehmen:
- 1 $> mkdir /tmp/fuse /tmp/shadow/
- 2 $> echo „illegal file“ > /tmp/shadow/illegal.txt
- 3 $> echo „legal device specific file“ >
/tmp/shadow/ZQXklUuTLkxQzfcflJtT_legal.txt
- 4 $> Is -al /tmp/fuse/
- 5 total 16
- 6 drwxrwxr-x 2 hba2pl hba2pl 4096 Mar 4 21:41 .
- 7 drwxrwxrwt 13 root root 12288 Mar 4 21:41 ..
- 8 $> Is -al /tmp/shadow/
- 9 total 24
- 10 drwxrwxr-x 2 hba2pl hba2pl 4096 Mar 4 21:43 .
- 11 drwxrwxrwt 13 root root 12288 Mar 4 21:43 ..
- 12 -rw-rw-r-- 1 hba2pl hba2pl 13 Mar 4 21:42 illegal.txt
- 13 -rw-rw-r-- 1 hba2pl hba2pl 27 Mar 4 21:43 ZQXklUuTLkxQzfcflJtT_legal.txt
- 14 $> # now starting the fuse filesystem mapping /tmp/shadow to /tmp/fuse
- 15 $> ./secretfs /tmp/fuse/
- 16 $> # there only the legal files will appear without the prefix
- 17 $> Is -al /tmp/fuse/
- 18 total 8
- 19 drwxrwxr-x 2 hba2pl hba2pl 4096 Mar 4 21:43 .
- 20 -rw-rw-r-- 1 hba2pl hba2pl 27 Mar 4 21:43 legal.txt
- 21 $> cat /tmp/fuse/legal.txt
- 22 legal device specific file
- 23 $> # trying to access the illegal file will fail
- 24 $> cat /tmp/fuse/illegal.txt
- 25 cat: /tmp/fuse/illegal.txt: Operation not permitted
-
Zu Demonstrationszwecken dienen hier zwei Dateien: eine (per Definition des beispielhaften FUSE-Schnittstellenmoduls) gültige Datei mit dem Dateinamen „ZQXklUuTLkxQzfcflJtT_legal.txt“ und eine ungültige Datei mit dem Dateinamen „illegal.txt“. Die vorliegende Implementierung des Dateisystems akzeptiert nur Dateien mit dem Präfix „ZQXklUuTLkxQzfcflJtT_“. Während also die gültige Datei geöffnet, ihr Inhalt betrachtet und mittels beliebiger auf dem Gerät installierter Anwendungen verarbeitet werden kann, wird der Versuch eines Zugriffes auf die ungültige Datei verhindert.
-
In einem in 2 gezeigten Geräteindividualisierungsschritt (Prozess 20) wird eine Quelle (21) von (Pseudo-)Zufälligkeit verwendet, um solch einen zufälligen Attributwert (a) für ein bestimmtes Gerät (d) zu erzeugen. Das hierbei gewählte Attribut kann ein beliebiges Attribut einer Datei sein, das auf der Abstraktionsebene des Schnittstellenmodules „sichtbar“ ist. Neben dem im obigen Beispiel verwendeten Präfix des Dateinamens könnte es sich beispielsweise um die Größe der Datei oder eine Kombination aus mehreren Attributen handeln.
-
Der Attributwert (a) wird mit einer eindeutigen Kennung (identifier, ID) des jeweiligen Gerätes (d) assoziiert und dem Gerät (d) auf diese Weise in einer Datenbank (Db) für eine spätere Abfrage dauerhaft zugeordnet. Gleichzeitig wird der Attributwert (a) dem Schnittstellenmodul, das für das Gerät (d) gebaut wird, wie im obigen Beispiel gleichsam „eingeprägt“.
-
Angenommen sei nun der Fall, dass z. B. ein Software-Update durchgeführt werden soll, während sich das Gerät (d) im Einsatz befindet. Dann wird in einem in 3 gezeigten Dateianpassungsschritt (30) der Attributwert (a) für das Gerät (d) aus der Datenbank (Db) abgerufen. Das betreffende Attribut der Datei (f), die an das Gerät (d) gebunden werden soll, wird von einer Anpassungsfunktionseinheit (31) auf den gerätespezifischen Wert gesetzt oder entsprechend modifiziert. Das Ergebnis dieses Schrittes ist also eine Datei (fd), die nur vom Gerät (d) korrekt verarbeitet werden kann.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- DE 102015225651 A1 [0004]
