Некоторое содержание этого приложения в настоящий момент недоступно.
Если эта ситуация сохраняется, свяжитесь с нами по адресуОтзывы и контакты
1. (WO2019038052) METHOD AND APPARATUS FOR PROTECTING A DEVICE
Примечание: Текст, основанный на автоматизированных процессах оптического распознавания знаков. Для юридических целей просьба использовать вариант в формате PDF

Beschreibung

Titel

Verfahren und Vorrichtung zum Schützen eines Gerätes

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.

Kurze Beschreibung der Zeichnungen

Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:

Figur 1 das Flussdiagramm eines Verfahrens gemäß einer Ausführungsform.

Figur 2 schematisch einen ersten Prozess des Verfahrens.

Figur 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 Figur 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 linkabie formet, ELF) für den Dateizugriff vorinstaliierte Bibliotheken mittels des LD_PRELOAD-Mechanismus des dynamischen Laders zu ersetzen. Eine auf assoziativer Dateiverwaltung (,. Daten bankdateisysterrf) 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- odul 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>

1 1 #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 7tmp/shadow"

17

18 // max file and folder length

19 #define AX_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 szFiie[ AX_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 whiie (*path==T) path++;

30 sprintf( szFiie, "%s/%s%s", SHADOW_FOLDER,

DEViCE_SPECIFIC_SECRET, path );

31 return stat( szFiie, stbuf );

32 }

33

34 static int my_readdir(const char *path, void *buf, fuse_fiil_dir_t filier,

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)K 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 }

52 static int my_open(const char *path, struct fuse_fiie_info *fi) {

53 char szFile[MAX_CHAR] = {0};

54 whiie(*path==T) path++;

55 sprintf( szFile, "%s/%s%s", SHADOW_FOLDER,

DEVICE_SPECIFIC_SECRET, path );

56 if ((fi->fh = open( szFiie, 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_getat.tr, .open = my_open,

70 .read = my_read, .readdir = my_readdir,

71 };

72

73 // deiegate main call to libfuse

74 int main(int arge, 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 .

1 1 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 „ZQXkl U uTLkxQzfcfl JtTJegal .txf und eine ungültige Datei mit dem Dateinamen Jllegal.txt". Die vorliegende Implementierung des Dateisystems akzeptiert nur Dateien mit dem Präfix„ZQXklUuTLkxQzfcflJtTJ1. 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 Figur 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 Figur 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.