Sichere Rechnerarchitektur Trennung von Daten und Befehlen schützt gegen Malware

Redakteur: Franz Graser

Der Ingenieur Friedhelm Becker aus Waddewarden hat eine Rechnerarchitektur entwickelt, die resistent gegen Malware sein soll. Sie basiert auf dem Prinzip der strikten Trennung von Befehlen und Daten im Speicher.

Firmen zum Thema

Sichere Rechner: Das patentierte Datenverarbeitungssystem des deutschen Ingenieurs Friedhelm Becker unterscheidet strikt zwischen Befehlen und drei verschiedenen Datentypen. Da sich Malware-Programme nicht mehr als Daten maskieren können, bleiben sie wirkungslos.
Sichere Rechner: Das patentierte Datenverarbeitungssystem des deutschen Ingenieurs Friedhelm Becker unterscheidet strikt zwischen Befehlen und drei verschiedenen Datentypen. Da sich Malware-Programme nicht mehr als Daten maskieren können, bleiben sie wirkungslos.
(Bild: gemeinfrei/Pixabay / CC0 )

Häufig wird Schadsoftware in Rechnersysteme eingeschleust, die sich als harmloses Dokument tarnt. Dies kann mit der unter (Patentnummer DE 10 2013 005 971 B3) patentierten Rechnerarchitektur so nicht passieren, da sie strikt zwischen Programmcode und Daten trennt. Friedhelm Becker, Projektingenieur bei Atlastitan und zuvor fast 30 Jahre bei einem Unternehmen der Luft- und Raumfahrtbranche tätig, konzipierte diese Architektur. Er stellt sie im Gespräch mit ELEKTRONIKPRAXIS vor.

Die Architektur, die Sie entwickelt haben, sieht die Trennung zwischen Programmcode und Programmdaten vor. Ist das korrekt?

Richtig. Aber es geht noch weiter: auch die Daten werden getrennt. Und zwar gibt es neben den Instruktionen drei Datenkategorien. Ich rede immer von vier Datenkategorien, von denen eine dann die Instruktionen sind. Eine Datenkategorie ist die Kategorie der Adressdaten. Wenn Sie zum Beispiel ein Icon auf Ihrem Bildschirm anklicken, damit eine bestimmte Funktion ausgeführt wird, dann möchten Sie ja, dass genau diese Funktion ausgeführt wird.

Ein Angriffspunkt ist zum Beispiel, dass solche hinterlegten Adressen verbogen werden und dann ganz andere Programme ausgeführt werden. Darum sind diese Daten gesondert von den übrigen. Und dann bleiben noch zwei Kategorien: Eine sind Daten, die von Programmen gebraucht werden, und zwar als Teil des Programms – als mitkompilierte, vom Compiler erzeugte Daten. Und die vierte und letzte Kategorie sind die Daten, die Sie bearbeiten sollen – auf die haben Sie normalerweise keinen großen Einfluss.

Da kriegen Sie eine Datei vorgelegt, Sie schreiben einen Brief, Sie füllen ein Formblatt aus, was auch immer. Das sind die Daten, die Sie auch über externe Speicher austauschen, unter Umständen über das Internet austuschen. Das sind die Daten, die möglicherweise infiziert sein können. Die anderen drei Kategorien sind durch die Software-Lieferung, die Sie ganz offiziell bekommen haben, ja quasi abgedeckt.

Denn das sind Bestandteile der eingekauften Software, die unterliegen der Konfigurationskontrolle oder es kann eine durchgeführt werden. Und die unterliegen auch, wenn es handelsübliche Software ist, einer Qualitätskontrolle des Software-Suppliers.

Bildergalerie

Spezifische Zugriffsattribute lassen sich nicht überschreiben

Friedhelm Becker, Entwickler einer Malware-resistenten Rechnerarchitektur.
Friedhelm Becker, Entwickler einer Malware-resistenten Rechnerarchitektur.
(Bild: privat)

Häufig werden ja feindselige Instruktionen als zu bearbeitende Daten maskiert. In dem Moment, in dem ich das betrieblich voneinander trenne, ist die Gefahr, dass die maskierten Instruktionen Schaden anrichten, geringer oder gleich Null.

Die ist gleich Null, und zwar deshalb, weil die Instruktionen für sich in einem Speicher sind, auf den der Instruktions-Bus Ihres Prozessors zugreifen kann. Auf alle drei anderen Datenkategorien kann der Instruktions-Bus nicht zugreifen. Also können über diese Datenkategorien keine verschleierten Instruktionen untergeschoben werden.

Wie müsste man denn jetzt einen Computer umbauen, damit man diese Datenkategorien operativ trennen kann, dass man diese Sicherheit erhält?

Wir haben in unseren herkömmlichen Computern nur einen Arbeitsspeicher. Der kann durchaus aus mehreren Chips bestehen, aber es ist ein durchgängiger Speicher, in dem alle einzelnen Zellen gleich adressiert werden können. In meiner Architektur hätten wir vier solcher Speicherbereiche, von denen jeder eigene Zugriffsattribute hat.

Und über diese jeweils eigenen Zugriffsattribute wird die Sicherheit gewährleistet. So sind zum Beispiel die Adressdaten nicht überschreibbar. Aus dem Grunde, den ich vorher schon nannte: Sie wollen nicht, dass hier Adressen verbogen werden in eine Richtung, in die sie nicht zeigen sollen.

Bildergalerie

Es muss ja aber immer eine gewisse Interaktion zwischen den Datenkategorien geben, also zum Beispiel zwischen den Instruktionen und den zu bearbeitenden Daten vorhanden sein. Wie wird das gewährleistet?

Gehen wir einmal davon aus, dass wir einen Prozessor haben, der einen Instruktionsbus und einen Datenbus oder Operandenbus hat. Der Datenbus dieses Prozessors hat Zugriff auf alle Datenkategorien außer den Instruktionen. Und da die Datenkategorien einzelne Speicherbereiche belegen, die voneinander getrennt sind, so bilden sie doch einen durchgängigen Adressraum.

Für das Programm ist es unerheblich, wo die Daten stehen, die es bearbeiten soll. Es wird über die korrekte Adresse auf die korrekten Daten zugreifen. Das ist lediglich eine Frage der Software-Instanziierung, des Bootens, wenn Sie so wollen.

Bitmuster-basierte Ansätze haben „jämmerlich versagt“

Bevor Sie mir das erklärt hatten, hatte ich vermutet, dass das System anhand von Bitmustern erkennt, ob es sich um eine Instruktion oder ob es sich um Daten handelt.

Nein. Diese Verfahren verwenden ja die Antiviren-Programme heutiger Art und die haben jämmerlich versagt. Denn diese Verfahren setzen allesamt voraus, dass es irgendein Bitmuster gibt, an dem Schadsoftware erkannt werden kann.

Bei meiner Lösung ist es so, dass Schadsoftware, wenn überhaupt, nur in der vierten Datenkategorie landen kann. Unter dieser Datenkategorie hat sie keinen Anschluss an den Instruktionsbus. Programme, die dort landen, können nicht ausgeführt werden. Und das ist die Sicherheit vor Schadsoftware, die auch unbekannte, noch nicht identifizierte und sogar zukünftige Schadsoftware einschließt.

Müsste man denn bestehende Software größtenteils umschreiben, um sie auf Ihrer Architektur lauffähig zu bekommen?

Wenn Sie mit „umschreiben“ umprogrammieren meinen: Das brauchte man nicht, mit Ausnahme natürlich des Betriebssystems. Das muss diese Architektur in sich repräsentieren. Aber Anwendersoftware bräuchte nur in diese drei Datenkategorien und die Instruktionen sortiert und im Speicher abgelegt werden.

Eine Software, die direkt für meine Architektur geschrieben wäre, ist direkt rückwärtskompatibel bei gleichem Prozessor. Denn die heutigen Prozessoren prüfen gar nicht, ob die Daten sortiert sind oder nicht.

Bildergalerie

Ein IT-Security-Experte, mit dem ich mich über die von Ihnen entwickelte Sicherheitsarchitektur unterhalten habe, sagte mir, dass ihn das Konzept sehr an die sogenannte Harvard-Rechnerarchitektur erinnere, die 1944 entwickelt wurde. Die habe die auch bereits eine Trennung der Speicherbereiche zwischen Instruktionen und Daten vorgesehen. Worin würden Sie den Hauptunterschied beziehungsweise die Verbesserung Ihrer Entwicklung gegenüber der Harvard-Architektur sehen?

Die Harvard-Architektur ist zugegeben ähnlich. Sie trennt aber nur Instruktionen von Daten, ohne die Daten weiter zu unterteilen. Geboren wurde diese Architektur in der Zeit der Wort-Adressierung aus der Überlegung, dass Daten mehr Bits pro Wort beanspruchen als Instruktionen. So hat man die teure Ressource Speicherplatz gespart, und zugleich ein bisschen an Geschwindigkeit gewonnen, weil Daten- und Instruktions-Zugriffe getrennte Busse nutzen konnten.

Heute ist von dieser Architektur nur die Trennung von Daten- und Instruktionsbus geblieben. Durch Byte-weise Zugriffe und preiswerte Speicher-Chips ist die Wortlängenproblematik nicht mehr so wichtig und nahezu vergessen. Leider hat das dazu geführt, dass die physische Trennung von Daten und Instruktionen innerhalb der Speicher wieder aufgehoben wurde. Damit wurde das Sicherheitsrisiko der von-Neumann-Architektur wieder eingeführt.

Wie sind Sie auf diese Architektur gekommen?

Darauf bin ich 2011 gekommen. Im Frühjahr dieses Jahres gab es einen Hackerangriff auf die amerikanische Firma RSA, bei dem die Algorithmen entwendet wurden, mit denen die RSA-Sicherheitsdongles programmiert wurden. Das ist eine Second-Source-Identifizierung. Diese Identifizierung hat mein damaliger Arbeitgeber auch benutzt.

Und weil aufgrund dieses Angriffes diese Dongles sofort eingezogen wurden, waren wir eine Zeit von ungefähr drei Wochen ohne die mögliche Nutzung unseres VPN zwischen den einzelnen Firmenstandorten, was unsere Arbeit sehr stark behindert hat. Und diese Behinderung habe ich zum Anlass genommen, zu überlegen: Da muss es doch etwas geben, was keine solch kräftige Nebenwirkung hat. Und so bin ich letzten Endes auf diese Lösung gekommen.

(ID:44326364)