DE602004002241T2 - Schutz eines auf ausführungwartenden Programms in einem Speicher für einen Mikroprozessor - Google Patents

Schutz eines auf ausführungwartenden Programms in einem Speicher für einen Mikroprozessor Download PDF

Info

Publication number
DE602004002241T2
DE602004002241T2 DE200460002241 DE602004002241T DE602004002241T2 DE 602004002241 T2 DE602004002241 T2 DE 602004002241T2 DE 200460002241 DE200460002241 DE 200460002241 DE 602004002241 T DE602004002241 T DE 602004002241T DE 602004002241 T2 DE602004002241 T2 DE 602004002241T2
Authority
DE
Germany
Prior art keywords
program
memory
signature
lines
application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE200460002241
Other languages
English (en)
Other versions
DE602004002241D1 (de
Inventor
Stephan Courcambeck
Claude Anguille
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
STMicroelectronics SA
Original Assignee
STMicroelectronics SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by STMicroelectronics SA filed Critical STMicroelectronics SA
Publication of DE602004002241D1 publication Critical patent/DE602004002241D1/de
Application granted granted Critical
Publication of DE602004002241T2 publication Critical patent/DE602004002241T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14Protection against unauthorised use of memory or access to memory
    • G06F12/1458Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1466Key-lock mechanism
    • G06F12/1475Key-lock mechanism in a virtual system, e.g. with translation means
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)

Description

  • Die vorliegende Erfindung betrifft das Gebiet der Mikroprozessoren und näherhin die Multitask-Schaltungen, die wenigstens vom Benutzer aus betrachtet mehrere Programme gleichzeitig auszuführen vermögen. In der Praxis wird jeweils eine einzige Anweisung bzw. Vorschrift eines Programms in jedem Zeitpunkt durch eine zentrale Verarbeitungseinheit verarbeitet, jedoch sind mehrere Programme oder Programmabschnitte in einem RAM-Speicher gespeichert, auf den die Zentraleinheit zugreifen kann, welche Zeilen des auszuführenden Programms in einen ihr zugeordneten Cache-Speicher überträgt.
  • 1 veranschaulicht in sehr schematischer Weise und in Blockform ein Beispiel einer vereinfachten Architektur des Typs, auf welchen sich die vorliegende Erfindung bezieht. Eine mit einem Cache-Speicher 2 (CACHE) ausgerüstete zentrale Verarbeitungseinheit 1 (CPU) ist über einen oder mehrere Kommunikations-Bus 3 (Daten, Adressen, Befehle) mit Peripherie-Elementen verbunden. Von diesen Peripherie-Elementen ist ein RAM-Speicher 4 (RAM), der zur Aufnahme der Daten (Operanden) der in Verarbeitung befindlichen Programme sowie der Code-Zeilen dieser Programme (wenigstens nach Blöcken) bestimmt ist, mit dem Bus 3 verbunden. In der Praxis kommen die in dem Speicher 4 enthaltenen Programme im allgemeinen von einem Masse-Speicher 5 (MMEN), beispielsweise einer Festplatte. Dieser Masse-Speicher enthält die durch die Zentraleinheit ausführbaren Programme sowie sichergestellte Daten, wenn diese Programme nicht in Ausführung befindlich sind. Selbstverständlich können mehrere Masse-Speicher (CDROM, Disketten usw.) mit dem Bus 3 verbunden werden.
  • Um mehrere verschiedene, zeitweilig in dem Speicher 4 gespeicherte Anwendungen oder Programme ausführen zu können, muss die Zentraleinheit 1 über eine Korrespondenztabelle zwischen sogenannten virtuellen Programm-Adressen, die unabhängig von ihrer Speicherstelle sind, und sogenannten physischen Adressen, entsprechend den physischen Adressen in dem Speicher, beispielsweise dem Speicher 4, wo die verschiedenen Zeilen des Programms gespeichert sind, verfügen. Diese Korrespondenztabelle ist im allgemeinen in Pufferregistern gespeichert und wird im allgemeinen mit ihrer angelsächsischen Bezeichnung TLB (Translation Look Aside Buffer, Adressenübersetzungs-Umsetzpuffer) bezeichnet werden.
  • 2 veranschaulicht in sehr schematischer und funktionaler Weise eine Korrespondenztabelle 10 und die Austauschvorgänge zwischen dem diese Tabelle enthaltenden Cache-Speicher oder -Register und den verschiedenen hierauf zugreifenden Elementen.
  • Auf Seiten der zentralen Verarbeitungseinheit 1 erfolgt jedes Mal, wenn eine Instruktion eines in dem RAM-Speicher 4 gespeicherten Programms ausgeführt werden soll, der Aufruf dieser Instruktion unter Verwendung der virtuellen Adresse VirtAD dieser Instruktion entsprechend der in dem Programm enthaltenen Adresse. Diese virtuelle Adresse wird in der Tabelle 10 in eine physische Adresse PhysAD konvertiert, unter welcher sich diese Instruktion in dem RAM-Speicher 4 befindet. Der Speicher 4 liefert dann die entsprechende Instruktion auf dem Bus (3, 1) mit Bestimmung für die Zentraleinheit.
  • Wenn die Tabelle 10 die Korrespondenz zwischen den beiden Adressen nicht enthält, berechnet die Zentraleinheit oder genauer ein Rechenprogramm (Block 11, CALC) ihres Betriebssystems eine neue Korrespondenzzeile zwischen virtueller und physischer Adresse und schreibt sie in die Tabelle 10 ein.
  • Jedes Mal, wenn eine in dem RAM-Speicher 4 enthaltene Anwendung durch die Zentraleinheit ausgeführt werden soll, übernimmt das Betriebssystem und berechnet unter Verwendung seiner internen Strukturen die Korrespondenztabelle für das betreffende Programm.
  • 3 veranschaulicht die Tatsache, dass zwei verschiedene Anwendungen APPL1 und APPL2, die in dem RAM-Speicher 4 unter verschiedenen physischen Adressen (PhysAD(k) bis PhysAD(m) für das erste Programm und (PhysAD(n) bis PhysAD(p) für das zweite Programm) gespeichert sind, sich identische virtuelle Adressen (VirtAD(1), VirtAD(2), VirtAD(i), usw.) teilen. Jedes Mal, wenn ein Programm in den Vordergrund tritt, d. h. bei Ausführung durch die Zentraleinheit 1 (gegebenenfalls nach Überführung in den Cache-Speicher 2), dient die Korrespondenztabelle 10 zur Umwandlung seiner virtuellen Adressen in physische Adressen in dem Speicher 4.
  • Aus Gründen der Sicherheit im Ablauf der Programme ist es wichtig, dass zwei identische virtuelle Adressen von zwei verschiedenen Anwendungen nicht auf dieselbe physische Adresse in dem Speicher 4 zeigen. Tatsächlich gestattet dies den Schutz des Codes des Programms sowie der Daten der Anwendungen untereinander. Falls beispielsweise ein sensibles Datum (geheime Größe, geheimes Ergebnis, usw.) einer ersten Anwendung unter einer zwischen den Adressen k und m in dem Speicher 4 enthaltenen physischen Adresse gelegen ist, während dem Datum eine virtuelle Adresse i zugewiesen wird, darf vor allem keine andere Anwendung auf die entsprechende physische Adresse unter Wiederverwendung der virtuellen Adresse i zugreifen. In einer Architektur des Typs wie der von 2 muss die Korrespondenztabelle jedes Mal beim Übergang von einer Anwendung zu einer anderen reinitialisiert werden. Dies erfordert die Neuberechnung der Korrespondenztabelle jedes Mal, wenn eine Anwendung zur Ausführung im Vordergrund gelangt, d. h. dass eine ihrer Befehlsinstruktionen von der Zentraleinheit ausgeführt werden muss.
  • Ein offenkundiger Nachteil ist, dass dies Zeit in Anspruch nimmt.
  • 4 veranschaulicht in sehr schematischer Weise die Architektur einer herkömmlichen Lösung, welche die jedesmalige Neuberechnung der Korrespondenztabelle jedes Mal, wenn eine Anwendung in den Vordergrund tritt, zu erübrigen gestattet. Bei dieser Lösung findet ein zusätzliches Feld in der Korrespondenztabelle 10 Anwendung, das für jede Zeile zusätzlich zu der virtuellen und physischen Adresse einen Identifikator ASID der Anwendung enthält. Hierdurch kann im Prinzip ausgeschlossen werden, dass eine Anwendung die Korrespondenz einer physischen Adresse einer anderen verwendet.
  • Zur Anwendung dieser Lösung verwendet die Schaltung ein Register 20 (ASIDREG), das den Identifikator der laufenden Anwendung enthält. Dieses Register ist ein Zustandsregister der Zentraleinheit 1.
  • Diese Lösung bietet gegenüber der von 2 den Vorteil, dass es nicht erforderlich ist, jedes Mal bei einer Änderung der Vordergrund-Aufgabe bzw. -Task die Korrespondenztabelle zu reinitialisieren oder zu leeren.
  • Ein Nachteil verbleibt jedoch, insofern es das Betriebssystem ist, das die Identifikatoren ASID den verschiedenen Anwendungen zuweist, wenn eine Anwendung zur Ausführung in den RAM-Speicher geladen wird. Die einer suspendierten Anwendung (im Hintergrund) zugeordnete Zone des RAM-Speichers 4 wird daher für eventuelle Angriffe verwundbarer. Tatsächlich ist es von dem Zeitpunkt an, wo die Korrespondenztabelle nicht integral neu berechnet wird, wenn eine Anwendung in den Vordergrund gelangt, möglich, den RAM-Speicher durch einen Emulator zu ersetzen oder die Signale auf dem Bus 3 zu modifizieren, um einen operativen Code einer Anwendung im Hintergrund zu modifizieren und einen Piraterie-Befehl (vom Typ Virus oder trojanisches Pferd') in den operativen Code einzuführen. Wenn daher die Anwendung wieder in den Vordergrund gelangt, kann sie auf die physischen Adressen zugreifen, die in der Korrespondenztabelle bei der vorhergehenden Ausführung der Anwendung (bevor die Tabelle geändert wurde) präsent geblieben sind.
  • Diese Verwundbarkeit einer Anwendung im Hintergrund wird durch den Umstand erhöht, dass man nicht synchron mit der Zentraleinheit zu sein braucht, um die Zeilen dieses Speichers zu ändern.
  • Ein ähnliches Problem stellt sich für den Masse-Speicher 5, wenn das Programm nicht integral in den RAM-Speicher 4 geladen wird und seine Ausführung Aufrufe an Datenleitungen in dem Masse-Speicher 5 erfordert.
  • Das Dokument ‚Hardware mechanisms for memory integrity checking' von G. E. SUH et al., Technical report MIT-LCS-TR-872, S. 1-18, vom 18. 11. 2002 (XP002265630) beschreibt einen Mechanismus zur Verifizierung der Integrität eines Speichers in Multitask-Anwendungen unter Verwendung einer Korrespondenztabelle zwischen virtuellen Adressen der Zeilen verschiedener Programme und physischen Adressen dieser Zeilen in einem RAM-Speicher.
  • Die Dokumente ‚Enhancing security in the memory management unit' von T. Gilmont et al., Konferenz EUROMICRO, 1999, Proceedings 25th Milan, Italy 8-10 Sept. 1999, Los Alamitos, CA, USA IEEE Comput. Soc. Press US, 8. September 1999, p. 449-456 (XP010352217), und ‚Architectural support for transation table management in large address space machines' von J. Huck et al., Proceedings of the Annual International Symposium on Computer Architecture, San Diego, Mai 16-19, 1999, Los Alamitos, IEEE Comput. Soc. Press, US, vol Symp 20, vom 16. 5. 1993, p. 39-50 (XP00039895), beschreiben Systeme zum Management eines Speichers mit einer Übersetzung physischer in virtuelle Adressen und beziehen sich auf das TLB-Gebiet (Translation Look Aside Buffer).
  • Die vorliegende Erfindung betrifft ein Verfahren zur Autorisierung des Zugriffs auf eine Korrespondenztabelle, das die Nachteile der bekannten Lösungen vermeidet. Insbesondere bezweckt die Erfindung die Erübrigung einer jedesmaligen systematischen Neuberechnung einer Korrespondenztabelle bei jedem Laden einer auszuführenden Anwendung in den Vorder grund, ohne hierdurch die Anwendung verwundbarer zu machen, wenn sie sich im Hintergrund in einem RAM-Speicher befindet.
  • Die Erfindung bezweckt gleichfalls die Schaffung einer Lösung, welche mit den herkömmlichen Anwendungen der Korrespondenztabellen kompatibel ist.
  • Zur Erreichung dieser und anderer Ziele sieht die vorliegende Erfindung vor ein Verfahren zur Autorisierung des Zugriffs auf eine Adressen-Korrespondenztabelle wie in Anspruch 1 definiert.
  • Gemäß einer Ausführungsform der vorliegenden Erfindung wird die genannte Signatur durch Implementierung einer Hash-Funktion berechnet.
  • Gemäß einer Ausführungsform der vorliegenden Erfindung ist der genannte Speicher ein RAM-Speicher, in welchen Programmzeilen aus einem Masse-Speicher geladen werden.
  • Die Erfindung sieht auch einen Prozessor zur Multitask-Ausführung mehrerer Programme wie in Anspruch 4 definiert vor.
  • Diese und weitere Ziele, Gegenstände, Eigenschaften, Merkmale und Vorteile der vorliegenden Erfindung werden in der folgenden nicht-einschränkenden Beschreibung spezieller Ausführungsbeispiele im einzelnen auseinandergesetzt, unter Bezugnahme auf die beigefügten Zeichnungsfiguren; in diesen zeigen:
    die bereits beschriebenen 1 bis 4 Darlegungen des Standes der Technik und der Problemstellung,
  • 5 in sehr schematischer Weise und in Blockform eine Ausführungsform einer Mikroprozessor-Architektur zur Ausübung des erfindungs gemäßen Verfahrens der Autorisierung des Zugriffs auf eine Korrespondenztabelle.
  • In den verschiedenen Figuren sind gleiche Elemente mit denselben Bezugsziffern bezeichnet. Aus Gründen der Klarheit und Übersichtlichkeit sind in den Figuren dargestellt, und werden im folgenden beschrieben, nur die Verfahrensstufen und -schritte und die Elemente des Prozessors, die zur Erläuterung der Erfindung notwendig sind. Insbesondere ist die Berechnung der Korrespondenztabelle als solche nicht im einzelnen detailliert und bildet nicht Gegenstand der vorliegenden Erfindung, da diese mit den herkömmlich verwendeten Rechenmitteln erfolgen kann.
  • Ein charakteristisches Merkmal der vorliegenden Erfindung ist, bei jeder Kontextänderung (Überführung einer neuen Anwendung in den Vordergrund) den Identifikator der Anwendung mit Hilfe eines Algorithmus zu berechnen, der eine Hash-Funktion oder analoge Funktion ausführt zur Berechnung einer Signatur wenigstens eines Teils des Codes der in dem RAM-Speicher und/oder in einem Masse-Speicher gespeicherten Anwendung.
  • Ein anderes charakteristisches Merkmal der Erfindung ist, die Übereinstimmung dieser berechneten laufenden Signatur relativ mit einer zuvor berechneten und in der Korrespondenztabelle registrierten Bezugssignatur zu verifizieren bzw. zu testen. Die Berechnung der Bezugssignatur erfolgt bei jeder Berechnung einer neuen Korrespondenz zwischen einer virtuellen und einer physischen Adresse. Diese Signatur bleibt jedoch stets dieselbe für ein und dieselbe Anwendung.
  • 5 veranschaulicht in sehr schematischer Weise und in Blockform eine Ausführungsform der vorliegenden Erfindung. Die Darstellung von 5 zeigt hauptsächlich die funktionellen Verbindungen zwischen den verschiedenen Elementen.
  • Die Erfindung benutzt eine Architektur des Typs der zuvor in Verbindung mit 4 beschriebenen Architektur, d. h. unter Verwendung eines jeweils jeder Korrespondenzzeile der Tabelle 10 zwischen einer virtuellen Adresse VirtAD und einer physischen Adresse PhysAD zugeordneten Identifikators ASID der Anwendung oder des Programms. Wie zuvor dient diese Korrespondenztabelle 10 zur Umwandlung der virtuellen Adressen einer Anwendung, die von einer mit einem Register 20 von Anwendungs-Identifikatoren (ASIDREG) versehenen zentralen Verarbeitungseinheit 1 (CPU) angefordert wird, in eine physische Adresse PhysAD eines RAM-Speichers 4, in welchem die betreffende Anwendung gespeichert ist. Die zentrale Verarbeitungseinheit umfasst materielle bzw. Hardware-Mittel oder Softwäre-Mittel (Block 11, CALC), um durch ihr Betriebssystem die physischen Adressen berechnen zu lassen, und zwar entweder beim Laden einer Anwendung oder beim erstmaligen Aufruf einer virtuellen Adresse.
  • Gemäß der vorliegenden Erfindung berechnet man jedes Mal, wenn eine in dem Speicher 4 (oder in einem nicht dargestellten Masse-Speicher) enthaltene Anwendung (beispielswise ein Programm oder ein Sub-Programm) in den Vordergrund treten soll, d. h. dass wenigstens eine seiner Befehlsinstruktionen durch die Zentraleinheit 1 ausgeführt werden soll, eine Signatur (Block 30, HASH) wenigstens eines Teils der in dem Speicher 4 gespeicherten Programmzeilen. Diese Signatur liefert einen in dem Register 20 gespeicherten laufenden Anwendungs-Identifikator (CURASID). Der Inhalt dieses Registers 20 wird sodann verglichen (Block 32, COMP) mit dem Identifikator ASID, der in der Zeile der Tabelle 10 gespeichert ist, welche der betreffenden Anwendung, welche man verwenden möchte, entspricht. Das Ergebnis dieses Vergleichs gestattet die Verifizierung bzw. Überprüfung, dass der Operations-Code der Anwendung in dem RAM-Speicher nicht modifiziert wurde, während sich diese Anwendung im Hintergrund befand. Der Vergleichsblock 32, der ein Hardware- oder ein Software-Element sein kann, liefert ein Autorisierungs- oder Authentifizierungssignal AUT mit Bestimmung für die Zentraleinheit 1, die geeigneten Maßnahmen zu unternehmen. In der Praxis führt die Zentraleinheit die in dem RAM-Speicher 4 gespeicher ten Programmbefehle nur aus, oder überführt sie in den Cache-Speicher zur Ausführung nur, wenn der Komparator 32 bestätigt hat, dass der Operations-Code, seit er in den Speicher 4 geladen wurde, nicht modifiziert wurde.
  • Vorzugsweise erfolgt die Signaturberechnung an einem feststehenden und signifikanten Teil des in dem RAM-Speicher gespeicherten Programm-Codes. Unter ‚feststehendem Teil' ist dabei zu verstehen, dass die Zeilen vermieden werden, welche durch das Programm verarbeitete Daten enthalten und deren Inhalt sich daher ändern und die Signatur modifizieren kann, selbst wenn keine Piraterie stattgefunden hat. Unter ‚signifikant' ist zu verstehen, dass, je größer die Zahl von Code-Zeilen ist, die bei der Signaturberechnung in Betracht bezogen werden, umso wirkungskräftiger die Authentifizierung sein wird. Beispielsweise kann man die Signatur unter Heranziehung einer Zeile von zehn Zeilen, einer Zeile von zwanzig oder einer Zeile von dreißig Zeilen des Operations-Codes berechnen.
  • Ein Vorteil der Erfindung ist, dass eine Modifikation des Operations-Codes eines im Hintergrund befindlichen in einem RAM-Speicher gespeicherten Programms schwierig wird, wenn man seinen Operations-Code unter gleichzeitiger Respektierung der Signatur modifizieren muss, deren Berechnungsalgorithmus im Prinzip unbekannt ist. Zur Gewährleistung der Sicherheit des Systems und aus Gründen der Schnelligkeit wird vorzugsweise die HASH-Funktion in materieller, d. h. Hardware-Weise in einer integrierten Schaltung ausgeführt.
  • Die jeweils in Ausführung befindliche Anwendung befindet sich notwendigerweise im Cache-Speicher des Mikroprozessors, der eine als für einen Piraten unzugänglich betrachtete Zone bildet. Erst wenn die Anwendung sich in Wartestellung in einem RAM-Speicher befindet, besteht eine Pirateriegefahr.
  • Es sei darauf hingewiesen, dass, wenn die Gesamtheit eines Programms beim Laden der Anwendung nicht aus dem Masse-Speicher (5, 1) in den RAM-Speicher überführt wird, die Berechnung der Signatur unter Verwen dung von noch in dem Masse-Speicher befindlichen Programmzeilen erfolgen kann. Die sich hieraus ergebenden Modifizierungen zu dem oben dargelegten liegen im Bereich des fachmännischen Könnens.
  • Ein Vorteil der Erfindung ist, dass ohne die Notwendigkeit einer neuen Berechnung der Korrespondenztabelle 10 bei jeder Überführung einer neuen Anwendung in den Vordergrund gewährleistet ist, dass ein Operations-Code nicht einer Piraterie unterliegt, während er sich in einer Multitask-Verarbeitung im Hintergrund befindet. Selbstverständlich kann der Inhalt der Zeilen der Tabelle 10 während der Auffüllung überschrieben werden, wie dies herkömmlicherweise in der in Verbindung mit 4 dargelegten Lösung der Fall war.
  • Es kann jeder beliebige herkömmliche Algorithmus zur Ausführung einer Funktion vom HASH-Typ Anwendung finden. Unter den bekannten Algorithmen sei beispielsweise der unter der Bezeichnung SHA-1 bekannte Algorithmus erwähnt, der auf Blöcke von 512 Bits wirkt und eine Signatur von 160 Bits am Ausgang liefert. Für die Anwendung eines derartigen Algorithmus wird der Code oder Code-Teil, von dem man eine Signatur wünscht, in Blöcke von 512 Bits aufgetrennt, für welche man jeweils fünf verkettete Worte zu 32 Bits entsprechend der Signatur des Blocks berechnet. In diesem Fall kann man beispielsweise ein einziges Wort aus den fünf 32-Bit-Worten der Signatur verwenden und jeweils die ersten Worte mehrerer für verschiedene Blöcke berechneter Signaturen hinzufügen, zur Bildung des laufenden Codes CURASID der Anwendung.
  • Selbstverständlich ist die vorliegende Erfindung verschiedenen Abwandlungen und Modifikationen zugänglich, welche sich für den Fachmann ergeben. Insbesondere hängt die Wahl des Rechen-Algorithmus für die Signatur vorzugsweise von der Größe bzw. dem Umfang der in der Korrespondenztabelle verwendeten Anwendungs-Identifikatoren ab sowie von dem für das System gewünschten Sicherheitsniveau. Des weiteren liegt die Wahl der für die Berechnung der Signatur in Betracht zu ziehenden Zeilen des Operations- Codes im Rahmen des fachmännischen Könnens, ausgehend von den vorstehenden funktionellen Angaben und Hinweisen. Schließlich wird eine materielle, d. h. Hardware-Realisierung der Signaturberechnung vorgezogen, jedoch schließt die Erfindung eine Software-Realisierung nicht aus.

Claims (4)

  1. Verfahren zur Authorisierung des Zugriffs auf eine Adressen-Korrespondenz-Tabelle (10) zwischen einer für Multitaskbetrieb ausgelegten Zentralen Verarbeitungseinheit (Zentraleinheit) CPU (1) und wenigstens einem mehrere Programme enthaltenden Speicher (4, 5), wobei die Tabelle Korrespondenzen zwischen virtuellen Adressen (VirtaD der Zeilen der verschiedenen Programme und physischen Adressen (PhysaD) dieser Zeilen in dem Speicher enthält und wobei jede Korrespondenz jeweils einem Identifikator (ASID) des betreffenden Programms zugeordnet ist, dadurch gekennzeichnet, dass das Verfahren zu jeder Task-Änderung der Zentraleinheit CPU durch Übergang des Programms in den Vordergrund Verfahrensschritte wie folgt umfasst: Berechnen (30) einer laufenden aktuellen Signatur (CURASID) wenigstens eines Teils der Befehlszeilen des Programms; Vergleichen (32) dieser Signatur mit einer Bezugssignatur (ASID), die in der genannten Kossespondenztabelle (10) bei einer vorhergehenden Ausführung des betreffenden Programms ausgehend von denselben Befehlszeilen aufgezeichnet wurde und den Identifikator des Programms konditioniert; Authorisieren des Zugriffs auf die Tabelle im Falle der Identität zwischen den Signaturen.
  2. Verfahren nach Anspruch 1, bei welchem die Berechnung der Signatur durch Implementierung einer Hash-Funktion erfolgt.
  3. Verfahren nach Anspruch 1 oder 2, bei welchem der genannte Speicher ein RAM-Speicher (4) ist, in welchen Programmzeilen aus einem Massespeicher (5) geladen werden.
  4. Prozessor für die Ausführung mehrerer Programme im Multitask-Betrieb, unter Verwendung einer Korrespondenztabelle (10) zwischen virtuellen Adressen (VirtaD) der Zeilen der verschiedenen Programme und physischen Adressen (PhysaD) dieser Zeilen in wenigstens einem Speicher (4, 5), wobei jede Korrespondenz einem Identifikator (ASID) des betreffenden Programms zugeordnet ist, dadurch gekennzeichnet, dass der Prozessor zu jeder Task-Änderung der Zentraleinheit durch Übergang des genannten Programms in den Vordergrund umfasst: Mittel (30) zum Berechnen einer laufenden bzw. aktuellen Signatur (CURASID) wenigstens eines Teils der Befehlszeilen des Programms; Mittel (32) zum Vergleichen dieser laufenden bzw. aktuellen Signatur (CURASID) mit einer Bezugssignatur (ASID), welche das in der Korrespondenztabelle gespeicherte Programm identifiziert und durch eine Signaturberechnung auf der Grundlage derselben Befehlszeilen berechnet ist; Mittel, welche im Falle der Identität der laufenden Signatur und des Programm-Identifikators die Zentraleinheit zur Ausführung des Befehls des betreffenden Programms authorisieren.
DE200460002241 2003-04-03 2004-04-01 Schutz eines auf ausführungwartenden Programms in einem Speicher für einen Mikroprozessor Expired - Lifetime DE602004002241T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0304149 2003-04-03
FR0304149 2003-04-03

Publications (2)

Publication Number Publication Date
DE602004002241D1 DE602004002241D1 (de) 2006-10-19
DE602004002241T2 true DE602004002241T2 (de) 2007-07-19

Family

ID=33396538

Family Applications (1)

Application Number Title Priority Date Filing Date
DE200460002241 Expired - Lifetime DE602004002241T2 (de) 2003-04-03 2004-04-01 Schutz eines auf ausführungwartenden Programms in einem Speicher für einen Mikroprozessor

Country Status (3)

Country Link
US (1) US8996874B2 (de)
EP (1) EP1489517B1 (de)
DE (1) DE602004002241T2 (de)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8079084B1 (en) 2007-08-10 2011-12-13 Fortinet, Inc. Virus co-processor instructions and methods for using such
US8286246B2 (en) 2007-08-10 2012-10-09 Fortinet, Inc. Circuits and methods for efficient data transfer in a virus co-processing system
US9100319B2 (en) 2007-08-10 2015-08-04 Fortinet, Inc. Context-aware pattern matching accelerator
US8375449B1 (en) * 2007-08-10 2013-02-12 Fortinet, Inc. Circuits and methods for operating a virus co-processor
US8281229B2 (en) * 2008-12-30 2012-10-02 Intel Corporation Firmware verification using system memory error check logic
FR2974920B1 (fr) * 2011-05-04 2013-11-29 St Microelectronics Rousset Protection d'une memoire volatile contre des virus par modification du contenu d'une instruction
FR2974919B1 (fr) 2011-05-04 2013-12-13 St Microelectronics Rousset Protection d'une memoire volatile contre des virus par changement d'instructions
FR2977342A1 (fr) * 2011-06-30 2013-01-04 Proton World Int Nv Verification d'integrite d'un programme execute par un circuit electronique
CN103593299B (zh) * 2013-11-12 2016-02-24 飞天诚信科技股份有限公司 一种节省存储空间的数据处理方法
US9749319B2 (en) * 2015-05-20 2017-08-29 Google Inc. Address validation using signatures

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5757915A (en) * 1995-08-25 1998-05-26 Intel Corporation Parameterized hash functions for access control
JP2001005726A (ja) * 1999-04-20 2001-01-12 Nec Corp メモリアドレス空間拡張装置及びプログラムを記憶した記憶媒体
US6834386B1 (en) * 1999-07-16 2004-12-21 Microsoft Corporation Method and system for regulating background tasks using performance measurements
US7082615B1 (en) * 2000-03-31 2006-07-25 Intel Corporation Protecting software environment in isolated execution
AU2002232817A1 (en) * 2000-12-21 2002-07-01 Digimarc Corporation Methods, apparatus and programs for generating and utilizing content signatures
SG140467A1 (en) * 2001-02-16 2008-03-28 Sony Corp Data processing method and its apparatus
DE10162291A1 (de) * 2001-12-19 2003-07-03 Philips Intellectual Property Verfahren und Anordnung zur Verhinderung unbefugten Ausführens von Computerprogrammen sowie ein entsprechendes Computerprogrammprodukt und ein entsprechendes computerlesbares Speichermedium
US7496757B2 (en) * 2002-01-14 2009-02-24 International Business Machines Corporation Software verification system, method and computer program element
US7346780B2 (en) * 2002-04-03 2008-03-18 Microsoft Corporation Integrity ordainment and ascertainment of computer-executable instructions
US7086088B2 (en) * 2002-05-15 2006-08-01 Nokia, Inc. Preventing stack buffer overflow attacks

Also Published As

Publication number Publication date
EP1489517B1 (de) 2006-09-06
US8996874B2 (en) 2015-03-31
US20040255124A1 (en) 2004-12-16
EP1489517A3 (de) 2005-01-12
EP1489517A2 (de) 2004-12-22
DE602004002241D1 (de) 2006-10-19

Similar Documents

Publication Publication Date Title
DE69531112T2 (de) Mechanismus zum verknüpfen von dateien auf einem emulierten system mit dem zentralsystem für den zugriff durch emulierte systembenutzer
DE3851049T2 (de) Ein Sicherheitswegmechanismus für ein Betriebssystem.
DE10397004B4 (de) Verfahren und Vorrichtung zum Laden eines vertrauenswürdigen Betriebssystems
DE69230778T2 (de) Dynamische Programmverknüpfung zwischen Programmadressbereichen im Nicht-Überwachungsmodus
DE69706440T2 (de) Schutzmittel in einem verteilten rechnersystem
DE69529092T2 (de) Einrichtung zur sicherheit eines hauptrechnersystems mit doppeldekor
DE112011102876T5 (de) Ressourcenverwaltungs- und Sicherheitssystem
WO2021078602A1 (de) Verfahren und vorrichtung zum betreiben einer recheneinrichtung
DE102014002181B4 (de) Chip und Verfahren zum Betreiben eines Chips
DE602004002241T2 (de) Schutz eines auf ausführungwartenden Programms in einem Speicher für einen Mikroprozessor
DE102018132970A1 (de) Verfahren und Vorrichtung zur Isolation von sensiblem nichtvertrauenswürdigem Programmcode auf mobilen Endgeräten
DE69710034T2 (de) Verfahren und Vorrichtung zum Schützen von Speicherteilen
DE112020005949T5 (de) Informationsverarbeitungsvorrichtung, Anomalieerfassungsverfahren und Computerprogramm
EP4078415A1 (de) Verfahren und vorrichtung zum betreiben einer recheneinrichtung
EP3655876B1 (de) Ein-chip-system, verfahren zum betrieb eines ein-chip-systems und kraftfahrzeug
EP4364015A1 (de) Ausführen von privilegierten operationen in einem container
DE60212169T2 (de) Laden von software
DE60017438T2 (de) System zur betriebsmittelzugriffsteuerung
DE102007005207A1 (de) Software-Duplikation
EP3588340B1 (de) Computerimplementiertes verfahren zum betreiben einer datenspeichereinrichtung
DE102017219241A1 (de) Verfahren und Halbleiterschaltkreis zum Schützen eines Betriebssystems eines Sicherheitssystems eines Fahrzeugs
DE112005002314T5 (de) Mechanismus zum Erzeugen eingeschränkter und uneingeschränkter Ausführungsumgebungen
DE3855616T2 (de) Vorrichtung und Verfahren mit Benutzung von Lockout für Zugriffssynchronisation auf Hauptspeichersignalgruppen in einem Multiprozessordatenverarbeitungssystem
EP4170490A1 (de) Priorisieren eines zugriffs von einer containerinstanz auf eine datei in einer dateisystemressource
EP3391279B1 (de) Mikrocontrollersystem und verfahren zur kontrolle von speicherzugriffen in einem mikrocontrollersystem

Legal Events

Date Code Title Description
8364 No opposition during term of opposition