DE102018132970A1 - Verfahren und Vorrichtung zur Isolation von sensiblem nichtvertrauenswürdigem Programmcode auf mobilen Endgeräten - Google Patents

Verfahren und Vorrichtung zur Isolation von sensiblem nichtvertrauenswürdigem Programmcode auf mobilen Endgeräten Download PDF

Info

Publication number
DE102018132970A1
DE102018132970A1 DE102018132970.9A DE102018132970A DE102018132970A1 DE 102018132970 A1 DE102018132970 A1 DE 102018132970A1 DE 102018132970 A DE102018132970 A DE 102018132970A DE 102018132970 A1 DE102018132970 A1 DE 102018132970A1
Authority
DE
Germany
Prior art keywords
sanctuary
application
unprotected
trusted
execution environment
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.)
Pending
Application number
DE102018132970.9A
Other languages
English (en)
Inventor
Emmanuel Stapf
Patrick Jauernig
Ferdinand Brasser
Ahmad-Reza Sadeghi
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.)
Sanctuary Systems De GmbH
Bayerische Motoren Werke AG
Original Assignee
Bayerische Motoren Werke AG
Technische Universitaet Darmstadt
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 Bayerische Motoren Werke AG, Technische Universitaet Darmstadt filed Critical Bayerische Motoren Werke AG
Priority to US17/287,617 priority Critical patent/US20210397700A1/en
Priority to EP19783279.3A priority patent/EP3864548A1/de
Priority to PCT/EP2019/076774 priority patent/WO2020074354A1/de
Publication of DE102018132970A1 publication Critical patent/DE102018132970A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
    • G06F12/1425—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block
    • G06F12/1441—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block for a range
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1483—Protection against unauthorised use of memory or access to memory by checking the subject access rights using an access-table, e.g. matrix or list
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1491—Protection against unauthorised use of memory or access to memory by checking the subject access rights in a hierarchical protection system, e.g. privilege levels, memory rings
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/109—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by using specially-adapted hardware at the client
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring 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/53—Monitoring 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1052—Security improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/15—Use in a specific computing environment
    • G06F2212/152—Virtualized environment, e.g. logically partitioned system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2149—Restricted operating environment

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Storage Device Security (AREA)

Abstract

Verfahren zur Bereitstellungen von isolierten und abgesicherten Ausführungsumgebungen auf einem Endgerät, das durch einen oder mehrere Prozessoren mit einem oder mehreren Prozessorkernen gesteuert wird, wobei die Prozessoren eine erste vertrauenswürdige Ausführungsumgebung und eine zweite ungeschützte Ausführungsumgebung zur Verfügung stellen und ausführen, wobei in der vertrauenswürdigen Ausführungsumgebung mindestens eine vertrauenswürdige Anwendung (4) ausgeführt wird, die sensible Daten verarbeitet, und wobei in der ungeschützten Ausführungsumgebung eine ungeschützte Anwendung (2) ausgeführt wird, gekennzeichnet durch eine oder mehrere weitere Ausführungsumgebungen, genannt Sanktuarium Instanzen, welche isoliert von der ersten und zweiten Ausführungsumgebung sind und jeweils auf einem dedizierten Prozessor oder dedizierten Prozessorkern, wobei diese physisch oder virtualisiert vorhanden sein können, ausgeführt werden, und Sankturariumsspeicherbereichen die ausschließlich den jeweiligen Prozessoren oder Prozessorkernen zugeordnet sind, wobei in einer Sanktuarium Instanz mindestens eine Sanktuariumsanwendung (10) ausgeführt wird, wobei eine Sanktuariumsanwendung (10) sowohl mit einer oder mehreren ungeschützten Anwendungen (2) als auch mit einer oder mehreren vertrauenswürdigen Anwendungen (4) über mindestens einen Kommunikationskanal interagiert.

Description

  • Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur Bereitstellungen von isolierten und abgesicherten Ausführungsumgebungen auf einem Endgerät, das durch einen oder mehrere Prozessoren mit einem oder mehreren Prozessorkernen gesteuert wird, wobei die Prozessoren eine erste vertrauenswürdige Ausführungsumgebung und eine zweite ungeschützte Ausführungsumgebung zur Verfügung stellen und ausführen, wobei in der vertrauenswürdigen Ausführungsumgebung mindestens eine vertrauenswürdige Anwendung ausgeführt wird, die sensible Daten verarbeitet, und wobei in der ungeschützten Ausführungsumgebung eine ungeschützte Anwendung ausgeführt wird. Ein weiterer Teil der Erfindung ist ein entsprechendes Endgerät.
  • Hintergrund der Erfindung
  • Die Sicherheitsarchitekturen, die derzeit auf den meisten ARM-basierten mobilen Geräten verwendet werden, werden im Folgenden erklärt und sind Teil der Erfindung. Die Erklärungen sind aber nicht auf die ARM-Architektur beschränkt andere Architekturen wie RISC oder CISC sind ebenfalls denkbar.
  • Die überwiegende Mehrheit der heutigen mobilen Geräte enthält einen Prozessor und andere Hardwarekomponenten, die auf einem ARM-Design basieren. Aufgrund des Bedarfs an sicheren mobilen Diensten wie Mobile Banking oder eID-Diensten (Der Begriff eID-Infrastruktur bezeichnet die für die Realisierung der sicheren elektronischen Identifizierung notwendige Infrastruktur zwischen dem Besitzer eines elektronischen Personalausweis und einem Service Provider über das Internet) wurde das ARM-Design um Funktionalitäten erweitert, die es ermöglichen, die Sicherheit des Systems, das ein ARM-Design verwendet, zu erhöhen. Diese Erweiterungen betreffen den Prozessor, den Speicher und andere Systemperipheriegeräte und werden unter dem Namen ARM TrustZone angeboten. ARM TrustZone ermöglicht eine Unterteilung des Systems, orthogonal zu den Privilegien-Stufen zur Unterteilung von Anwendungs-, Betriebssystem- und Hypervisor-Modus, welche insbesondere eine systemweite Hardwareisolation für vertrauenswürdige Software bietet. Mit Hilfe von TrustZone können Hersteller von mobilen Geräten Sicherheitsarchitekturen auf ihren Geräten implementieren, die es ermöglichen, sicherheitskritischen Programmcode in einer vertrauenswürdigen Umgebung auszuführen. Diese allgemeine Sicherheitsarchitektur, die als Trusted Execution Environment (TEE) bezeichnet wird, ist in 1 dargestellt und auf modernen mobilen Geräten weit verbreitet.
    Ein TEE stellt eine sichere bzw. vertrauenswürdige Ausführungsumgebung für Anwendungen zur Verfügung. Dabei kann ein TEE isoliert auf einem separaten Prozessor, direkt auf dem Hauptprozessor(en) eines Computersystems oder aber in einem Die eines Multiprozessor-System bzw. eines Ein-Chip-System (SoC) existieren. Auf dem TEE können nur speziell dafür freigeschaltete Anwendungen ausgeführt werden.
  • Das TEE-Konzept verfeinert das Konzept des Trusted Computing. Ein oder mehrere vertrauenswürdige Ausführungsumgebungen können parallel existieren, daneben können noch weitere unsichere oder ungeschützte Umgebungen existieren.
  • Das Hauptmerkmal einer TEE-Sicherheitsarchitektur ist die Trennung des Systems in eine normale und eine sichere Welt (Normal World/Secure World). Der Grundgedanke ist, dass die normale Welt im Allgemeinen nicht vertrauenswürdig und daher auch potentiell bösartig ist. In dieser Welt sollte nur Programmcode ausgeführt werden, der keine sensiblen Daten verarbeitet und für das System nicht sicherheitsrelevant ist. Auf bestehenden Architekturen wird das ungeschützte OS /Betriebssystem (Legacy OS) (1) typischerweise durch das Betriebssystem Android und die ungeschützten Anwendungen (Legacy Apps) (2) von Android Apps repräsentiert. In der sicheren Welt hingegen läuft Programmcode, der sensible Daten verarbeitet und für das System sicherheitsrelevant ist. Programmcode, der mobile Dienste wie Mobile Banking oder eID implementiert, sollte nur in der sicheren Welt ausgeführt werden, da er sensible Daten verarbeitet. Es ist zwingend erforderlich, dass dem Code in der sicheren Welt vertraut wird, da er das gesamte System gefährden kann. Die sichere Welt besteht aus einem Betriebssystem, dem vertrauenswürdigen OS (Trusted OS) (3) und den vertrauenswürdigen Anwendungen (Trusted Apps) (4), die die mobilen Dienste implementieren. Das vertrauenswürdige OS wird in der Regel durch ein kleines benutzerdefiniertes Betriebssystem repräsentiert, das sich zwischen verschiedenen Anbietern von mobilen Geräten erheblich unterscheiden kann. Die Umschaltung zwischen normaler und sicherer Welt erfolgt durch eine vertrauenswürdige Softwarekomponente namens Monitor-Programmcode. In der Regel wird die offizielle Referenzimplementierung von ARM, die so genannte ARM Trusted Firmware (5), verwendet. Die eigentliche Trennung zwischen den beiden Welten wird durch die Sicherheitserweiterungen der TrustZone für den Prozessor und andere Peripheriegeräte erreicht. TrustZone-fähige Prozessoren können in zwei verschiedenen Sicherheitsmodi ausgeführt werden, entweder unsicher oder sicher. Im ungesicherten Modus kann der Prozessor nur auf Programmcode und Daten aus der normalen Welt zugreifen. Im sicheren Modus kann der Prozess auf Programmcode und Daten aus beiden Welten zugreifen. Die Welttrennung im Speicher wird durch einen TrustZone-fähigen Adressraum-Kontroller, den TrustZone Address Space Controller (TZASC) (6), erzwungen. In 1 ist dargestellt, dass der TZASC z.B. den Zugriff vom ungeschützten OS auf die Speicheradresse 0×D0 verhindern würde, da dieser Speicherbereich zur sicheren Welt gehört. Verfügt ein Prozessor zudem über Virtualisierungserweiterungen, kann der Prozessor auch in einen weiteren Modus, genannt Hypervisor Modus (EL-2 bei ARM Prozessoren), wechseln. In diesem Modus können die Virtualisierungsmechanismen des Prozessors konfiguriert werden.
  • Obwohl beide Welten strikt voneinander getrennt sind, ist eine Kommunikation zwischen den beiden Welten notwendig, um die in der sicheren Welt implementierten Funktionen nutzen zu können. Typischerweise stellt der Hersteller von mobilen Geräten vertrauenswürdige Anwendungen im TEE bereit, die einige grundlegende Funktionen, wie die sichere Speicherung eines Schlüssels in der sicheren Welt oder die Ver- und Entschlüsselung von Daten mit diesen Schlüsseln, bieten. In diesem Fall werden die sensiblen Daten nur innerhalb der sicheren Welt verarbeitet und sind daher nicht gefährdet, von einem Angreifer gestohlen zu werden. Diese Basisfunktionalitäten des Anbieters können von jeder ungeschützten Anwendung in der normalen Welt offen genutzt werden. Für die meisten mobilen Dienste reichen jedoch die bereitgestellten Funktionalitäten der vertrauenswürdigen Anwendungen des Anbieters nicht aus, denn die Mobilfunkanbieter verwenden eigene Algorithmen und Protokolle, z.B. für die Schlüsselverwaltung, die sensible Daten verarbeiten und zur Laufzeit geschützt werden müssen. In einer TEE-Architektur ist dies durch den Einsatz eigener vertrauenswürdiger Anwendungen im TEE möglich. Als Ergebnis würde ein Mobilfunkanbieter seinen Programmcode in sensiblen und nicht sensiblen Programmcode aufteilen. Der sensible Programmcode ist in einer vertrauenswürdigen Anwendung implementiert, der nicht sensible Programmcode in einer ungeschützten Anwendung. Wenn beide auf dem Gerät bereitgestellt werden, können sie zusammenarbeiten, um den mobilen Dienst bereitzustellen.
  • Theoretisch stellt die TEE-Architektur ein solides Konzept dar. In der Praxis hat sich jedoch ein großer Nachteil dieser Architektur entwickelt. Jeder vertrauenswürdigen Anwendung, die von einem externen Mobilfunkanbieter entwickelt wird, muss vom Hersteller des mobilen Gerätes ausdrücklich vertraut werden. Der Grund dafür ist, dass man nicht erwarten kann, dass die vertrauenswürdigen OS fehlerfrei sind. Die vertrauenswürdigen OS werden in der Regel kleiner sein als die ungeschützten OS. Sie sind jedoch immer noch komplex und groß genug, so dass Softwarefehler sehr wahrscheinlich sind und einige von ihnen wurden bereits in bestehenden Implementierungen gefunden. Das notwendige Vertrauen in den Programcode einer vertrauenswürdigen Anwendung ist auch viel höher als das Vertrauen, das ein Gerätehersteller in den Programmcode einer ungeschützten Anwendung setzen muss. Wenn es einer ungeschützten Anwendung gelingt, das ungeschützte OS zu kompromittieren, wird sie immer noch keinen Zugang zu den sensiblen Daten in der sicheren Welt erhalten. Wenn eine vertrauenswürdige Anwendung jedoch in der Lage ist, einen Fehler im vertrauenswürdigen OS auszunutzen, kann sie das gesamte System gefährden. Sie erhält Zugang zu allen sensiblen Daten in der sicheren Welt und auch zu allen Daten in der normalen Welt. In der Praxis führte dies zu folgender Situation im Ökosystem der mobilen Software:
    • Einige Hersteller von mobilen Geräten sperren ihr TEE vollständig für Programmcode von Drittanbietern, so dass keine bösartige oder fehlerhafte vertrauenswürdige Anwendung auf das Gerät gebracht werden kann und die Systemsicherheit gefährdet ist. Dies bedeutet jedoch, dass kein Mobilfunkanbieter seinen eigenen sensiblen Programmcode in einer sicheren Umgebung ausführen und schützen kann. Andere Hersteller von mobilen Geräten erlauben es, vertrauenswürdige Anwendungen von Drittanbietern für ein Gerät bereitzustellen. Dies ist jedoch mit einem hohen Managementaufwand verbunden, der für einen Mobilfunkanbieter eine erhebliche Investition bedeutet, da jeder Gerätehersteller individuell kontaktiert werden muss, um eine maßgeschneiderte Lösung in ihrem TEE zu erhalten.
  • Außerdem müssen alle vertrauenswürdigen Anwendungen gründlich getestet werden, um Vertrauen in sie zu gewinnen. Wenn ein Gerätehersteller den Bereitstellungsprozess von vertrauenswürdigen Anwendungen vereinfachen würde, indem er jede vertrauenswürdige Anwendungen in seinem TEE zulässt, würde dies die Systemsicherheit stark gefährden. Obwohl es eine hohe Nachfrage nach sicheren mobilen Diensten gibt und ARM TrustZone auf den meisten mobilen Geräten verfügbar ist, sind sichere mobile Dienste, die durch TrustZone geschützt sind, heute nicht weit verbreitet.
  • Aus dem Stand der Technik sind bekannt:
    • Intel SGX bietet Sicherheits-Funktionalitäten, ist aber nur für die x86-Plattform -und damit nicht für Mobilgeräte - verfügbar. (V. Costan and S. Devadas. Intel sgx explained. IACR Cryptology ePrint Archive, 2016:86, 2016)
    • Sanctum ähnelt SGX, schlägt aber eine komplett neue Plattformarchitektur vor und ist daher nicht praxisrelevant. (V. Costan, I. A. Lebedev, and S. Devadas. Sanctum: Minimal hardware extensions for strong software isolation. in USENIX Security Symposium, pages 857-874, 2016.)
    • Sancus erweitert die openMSP430-Architektur durch weitere Hardware um kryptographische und Speicherisolations-Primitiven. Aufgrund der Kostspieligkeit von Hardware-Änderungen ist Sancus ebenfalls nicht praxisrelevant. (J. Noorman, P. Agten, W Daniels, R. Strackx, A. Van Herrewege, C. Huygens, B. Preneel, I. Verbauwhede, and F. Piessens. Sancus: Low-cost trustworthy extensible networked devices with a zero-software trusted computing base. in 22nd USENIX Security symposium, USENIX Sec, pages 479-494, 2013. J. Noorman, J. V. Bulck, J. T. Mühlberg, F. Piessens, P. Maene, B. Preneel, I. Verbauwhede, J. Götzfried, T. Müller, and F. Freiling. Sancus 2.0: A low-cost security architecture for iot devices. ACM Transactions on Privacy and Security (TOPS), 20(3):7, 2017.)
    • TrustICE hat die gleiche Zielsetzung wie das Sanktuarium, ermöglicht aber keine parallele Ausführung des sensiblen Programmcodes mit dem ungeschützten OS, und erfordert Vertrauen in den sensiblen Programmcode, daher ist auch TrustICE nicht praxisrelevant. (H. Sun, K. Sun, Y. Wang, J. Jing, and H. Wang. Trustice: Hardwareassisted isolated computing environments on mobile devices. in Proceedings of the 2015 45th AnnuaiiEEE/IFIP International Conference on Dependable Systemsand Networks, DSN '15, pages 367-378, 2015.)
  • Überblick über die Erfindung:
  • Aufgabe ist es daher eine Lösung für die oben genannten Probleme zu finden.
    Gelöst wird die Aufgabe durch ein Verfahren und eine Vorrichtung nach einem oder mehreren der Ansprüche.
  • Insbesondere durch ein Verfahren zur Bereitstellungen von abgesicherten Ausführungsumgebungen auf einem Endgerät, das durch einen oder mehrere Prozessoren mit einem oder mehreren Prozessorkernen gesteuert wird. Hierbei soll klargestellt werden, dass physische oder virtualisierte Prozessoren oder Prozessorkerne, Einheiten darstellen, denen ein eigener Speicherbereich zugeteilt wird, und die keinerlei Überschneidungen mit anderen Anwendungen erlauben, die auf anderen Prozessoren oder Prozessorkernen abgearbeitet werden. Es soll somit eine Separierung der Anwendungen auf Prozessor bzw. Prozessorkernebene und Speicherebene erfolgen.
    Die Prozessoren führen eine erste vertrauenswürdige Ausführungsumgebung und eine zweite ungeschützte Ausführungsumgebung aus, wobei in der vertrauenswürdigen Ausführungsumgebung mindestens eine vertrauenswürdige Anwendung ausgeführt wird, die sensible Daten verarbeiten, und wobei in der ungeschützten Ausführungsumgebung eine ungeschützte Anwendung ausgeführt wird. Hierbei handelt es sich um die bekannte TEE-Architektur, wie sie zum Beispiel bei ARM-Prozessoren implementiert ist. Andere Prozessoren haben ähnliche Architekturen. Eine Beschränkung auf Prozessoren mit einem entsprechenden Design ist nicht beabsichtigt. In den Ausführungsumgebungen laufen in der Regel separate Betriebssysteme, mit separaten Anwendungen, die lediglich über klar definierte Schnittstellen miteinander kommunizieren können. Standardmäßig kommunizieren Anwendungen aus der ungeschützten Ausführungsumgebung mit Anwendungen in der vertrauenswürdigen Ausführungsumgebung über definierte Protokolle und Schnittstellen. Das Ganze wird durch eine entsprechende Architektur mit einem entsprechenden Adressraum-Kontroller umgesetzt, der die Speicherbereiche entsprechend voneinander trennt. Auch ist eine entsprechende Firmware denkbar, die als Schicht zwischen dem Prozessor und dem Adressraum-Kontroller angeordnet ist, und die Kommunikation mit der Hardware und zwischen der ungeschützten Ausführungsumgebung und der vertrauenswürdigen Ausführungsumgebung koordiniert.
  • Die Erfindung hat eine oder mehrere weitere Ausführungsumgebungen, genannt Sanktuarium Instanzen, welche isoliert von der ersten und zweiten Ausführungsumgebung sind und jeweils auf einem dedizierten Prozessor oder dedizierten Prozessorkern ausgeführt werden. Es handelt sich hierbei um andere Prozessoren oder Prozessorkerne, als diejenigen, auf denen die beiden ersten Ausführungsumgebungen ausgeführt werden. Ferner ist jeder Sanktuarium Instanz ein Sankturariumsspeicherbereich zugeordnet, der wiederum ausschließlich diesem Prozessor oder Prozessorkern zugeordnet ist.
    In einer Sanktuarium Instanz läuft in der Regel ebenfalls ein kleines Betriebssystem, das in der Lage ist Anwendungen mit den entsprechenden Hardwareressourcen zu versorgen. Dieses Betriebssystem ist minimiert und auf den Zweck ausgerichtet, um bestimmte Sanktuariumsanwendungen auszuführen. Insbesondere können in einer Sanktuarium Instanz Bibliotheken angeboten werden, die von den Sanktuariumsanwendungen genutzt werden können, um eine Interaktion mit der ungeschützten Ausführungsumgebung und/oder der vertrauenswürdigen Ausführungsumgebung zu ermöglichen. Die Sanktuarium Bibliothek stellt hierbei die nötigen Kommunikationskanäle bereit. Diese Bibliothek dient auch zum Schutz, um bösartige Sanktuariumsanwendungen in ihrem Zugriff einzuschränken. Hierbei ist die ungeschützte Ausführungsumgebung so ausgebildet bzw. sind die Anwendungen, die in der ungeschützten Ausführungsumgebung laufen, so entwickelt, dass eine Kommunikation nicht unmittelbar mit der vertrauenswürdigen Anwendung in der vertrauenswürdigen Ausführungsumgebung erfolgt, sondern es findet zuerst eine Kommunikation mit den Sanktuariumsanwendungen statt, welche dann wiederum mit den Anwendungen in der vertrauenswürdigen Ausführungsumgebung kommunizieren. Wenn z.B. die ungeschützte Anwendung eine Kommunikationsanfrage an die vertrauenswürdige Anwendung vornimmt, wird die Kommunikationsanfrage umgelenkt auf die Sanktuariumsanwendung, die dann die Kommunikationsanfrage unter Durchführung einer Kommunikation mit der vertrauenswürdigen Anwendung verarbeitet.
    Die Kommunikation der ungesicherten Ausführungsumgebung mit einer Sanktuarium Instanz kann entweder automatisch durch entsprechende Kernelmodule erfolgen oder die Anwendungen verwenden entsprechende Bibliotheken und Routinen, die in der ungesicherten Ausführungsumgebung bereitgestellt werden, um eine Kommunikation mit dem Sanktuarium zu ermöglichen.
    Es ist zu beachten, dass die Anwendungen in einer Sanktuarium Instanz nicht notwendiger Weise auf Anwendungen in der vertrauenswürdigen Ausführungsumgebung zugreifen müssen. Sie können auch alleine in einer Sanktuarium Instanz ablaufen.
  • Hierbei ist vorzugsweise die Software, umfassend das vertrauenswürdige OS und die auf dem vertrauenswürdigen OS laufenden vertrauenswürdigen Anwendungen, nach der initialen Konfiguration des Endgerätes nicht mehr bzw. sehr aufwendig änderbar. D. h. zum Zeitpunkt der Auslieferung an den Endkunden besteht keinerlei Updatemöglichkeit für den Endkunden selbst. Hierdurch soll sichergestellt werden, dass Software in der vertrauenswürdigen Ausführungsumgebung beim Endkunden nicht mehr geändert werden kann bzw. eine Änderung nur mit Hilfe des Endgeräteherstellers erfolgen kann. Hierdurch wird sichergestellt, dass ein Angriff auf Software hardwareseitig stark eingeschränkt wird. Da auch Fehler in der vertrauenswürdigen Ausführungsumgebung behoben werden müssen, hat der Endgerätehersteller die Möglichkeit diese zu updaten. Um auf Anpassungen der vertrauenswürdigen Ausführungsumgebung reagieren zu können und um eigene Fehler beheben zu können, sind die Sanktuariumsanwendungen nach Auslieferung des Endgeräts auch durch Endbenutzer bzw. Drittanbieter, die Sanktuariumsanwendungen entwickeln, austauschbar. Hierdurch kann eine schnellere Reaktion auf Fehler und eine höhere Unabhängigkeit vom Endgerätehersteller erreicht werden.
    Der Austausch kann hierbei entweder über ein Funknetz erfolgen oder durch aufspielen von Software über Kabelverbindungen. Der Austausch kann sowohl lediglich die Sanktuariumsanwendungen betreffen als auch das Betriebssystem, das in einer Sanktuarium Instanz ausgeführt wird oder die entsprechenden Bibliotheken.
    In einer bevorzugten Ausführungsform wird in der vertrauenswürdigen Ausführungsumgebung eine Anwendung ausgeführt, vorzugsweise als Kernelmodul, die überprüft, ob eine Sanktuarium Instanz korrekt eingerichtet ist, um nur dann eine Kommunikation mit den Anwendungen in der vertrauenswürdigen Ausführungsumgebung zu erlauben, wenn eine korrekte Einrichtung der Sanktuarium Instanz vorliegt.
  • Diese Überprüfung kann auf der Basis von Signaturen oder Hash-Werten erfolgen. Somit wird sichergestellt, dass lediglich dann eine Interaktion erfolgt, wenn eine Sanktuarium Instanz bzw. deren Anwendungen nicht korrumpiert wurden. Die entsprechenden Signaturen oder Hash- Werte können in der vertrauenswürdigen Ausführungsumgebung abgelegt werden und zum Beispiel aus dem Netzwerk abgerufen werden. Somit kann sichergestellt werden, dass die Integrität des Gerätes gegeben ist. Auch kann zum Beispiel die Ausführung einer Sanktuarium Instanz erst dann erfolgen, wenn eine Überprüfung erfolgreich durchgeführt wurde.
  • In einer bevorzugten Ausführungsform stellt eine Sanktuarium Instanz eine Sanktuariumsbibliothek bereit, die grundlegende Prozess- und Speicherverwaltungs-, und Kommunikationsfunktionen bereitstellt, insbesondere um mit der vertrauenswürdigen Anwendung und den ungeschützten Anwendungen zu kommunizieren. Somit wird der Umfang der Programmierung der Sanktuariumsanwendungen reduziert und die Kommunikation standardisiert, wodurch bösartige Angriffe reduziert werden können.
  • In der bevorzugten Ausführungsform ist das Endgerät ein mobiles Endgerät, wie es in bekannten zellbasierten Mobilfunknetzen umfassend GSM und LTE verwendet wird. Somit sind die Sanktuariumsanwendungen z.B. nach Auslieferung des Endgeräts durch einen Betreiber des Mobilfunknetzwerks über das Mobilfunknetzwerk austauschbar. Der Austausch der Anwendungen in einer Sanktuarium Instanz kann zum Beispiel so gesteuert werden, dass lediglich Anwendungen, die in der vertrauenswürdigen Ausführungsumgebung laufen, berechtigt sind, ein Überschreiben der Anwendungen in einer Sanktuarium Instanz vorzunehmen. Auch ist es denkbar, dass die Anwendungen in einer Sanktuarium Instanz selbst regelmäßig nach Updates suchen, um sich selbst zu ersetzen. Die Anwendungen in der vertrauenswürdigen Ausführungsumgebung überprüfen dann, ob die Updates zulässig sind oder nicht. Aufgrund der Tatsache, dass auf die vertrauenswürdigen Anwendungen nur über eine Sanktuarium Instanz zugegriffen werden kann, wird sichergestellt, dass ein unmittelbarer Angriff auf die vertrauenswürdigen Anwendungen verhindert wird.
  • Eine Sanktuarium Instanz wird vorzugsweise einem physischen oder virtualisierten Prozessor oder Prozessorkern zugewiesen und auf diesem ausgeführt. Der Prozessor bzw. Prozessorkern wird zum Beispiel auf Basis von Prozessor-Identifikatoren ausgewählt. Der Sanktuariumsspeicherbereich wird ausschließlich diesem Prozessor oder Prozessorkern zugewiesen.
    Die Sanktuarium Instanzen, die ungeschützte Ausführungsumgebung und die vertrauenswürdige Ausführungsumgebung werden durch geeignete Isolationsmechanismen voneinander isoliert. Die Isolation erfolgt durch die Kontrolle der Zugriffe auf die Speicherbereiche, die den einzelnen Sanktuarium Instanzen, der ungeschützten Ausführungsumgebung und der vertrauenswürdigen Ausführungsumgebung zugewiesen sind. Die Zugriffskontrolle der Speicherbereiche der ungeschützten und vertrauenswürdigen Ausführungsumgebungen wird, wie beim Stand der Technik, durch einen Adressraum-Kontroller realisiert (z.B. TZASC von ARM). Wenn eine Sanktuarium Instanz einem physischen Prozessor oder Prozessorkern zugewiesen wird, wird die Isolation der Sanktuarium Instanz auch durch einen Adressraum-Kontroller realisiert. Wird eine Sanktuarium Instanz einem virtualisierten Prozessor oder Prozessorkern zugewiesen, erfolgt die Isolation durch Virtualisierungsmechanismen des physischen Prozessors oder Prozessorkerns (z.B. eine entsprechend ausgebildete Memory Management Unit (MMU)). Die Sanktuarium Isolationsmechanismen regeln, dass Anwendungen aus der ungeschützten Ausführungsumgebung lediglich Zugriff auf den Teil des Sanktuariumsspeicherbereichs erhalten, welcher mit der ungeschützten Ausführungsumgebung geteilt werden soll. Ferner steuert der Adressraum-Kontroller, dass Sanktuariumsanwendungen nur auf den Teil des Speicherbereichs der vertrauenswürdigen Ausführungsumgebung zugreifen können, welcher mit der Sanktuarium Instanz geteilt werden soll.
    In einer bevorzugten Ausführungsform können die Sanktuariumsanwendungen nun mit Hilfe der Sanktuariumsbibliothek, über die geteilten Speicherbereiche, mit Anwendungen in der ungeschützten Ausführungsumgebung und mit Anwendungen in der vertrauenswürdigen Ausführungsumgebung interagieren.
  • In einer bevorzugten Ausführungsform wird eine Sanktuarium Instanz nur aufgebaut und ausgeführt, wenn eine Kommunikationsanfrage von einer ungeschützten Anwendung vorliegt. Nachdem eine Sanktuarium Instanz seine Ausführung beendet hat, kann sie sich selbst abbauen oder sie wird entweder von der ungeschützten oder der vertrauenswürdigen Ausführungsumgebungen beendet und abgebaut, wenn bestimmte zeitliche oder andere Bedingungen hinsichtlich der Nutzung eingetreten sind. In diesem Falle können die Ressourcen, die von einer Sanktuarium Instanz in Anspruch genommen wurden, wieder freigegeben werden. Auf der anderen Seite, wenn eine Sanktuarium Instanz aufgebaut werden soll, sind entsprechende Ressourcen zu belegen, damit ein Prozessor oder ein Prozessorkern lediglich für die Sanktuarium Instanz zur Verfügung steht. Das Gleiche gilt für den Speicherbereich.
  • In den Aufbau einer Sanktuarium Instanz sind Komponenten der vertrauenswürdigen Ausführungsumgebung als auch Komponenten der ungeschützten Ausführungsumgebung involviert.
  • Die Komponenten der ungeschützten Ausführungsumgebung laden die Sanktuariumsbibliothek und Sanktuariumsanwendungen in den Speicher, und initiieren den Aufbau-Prozess. Zudem wählen sie den Prozessor oder Prozessorkern aus der einer Sanktuarium Instanz zugewiesen wird. Die Komponenten der vertrauenswürdigen Ausführungsumgebung überprüfen die Korrektheit des Aufbaus. Wird die Sanktuarium Instanz an einen physischen Prozessor oder Prozessorkern gebunden, aktiviert die vertrauenswürdige Ausführungsumgebung die Speicherisolation, d.h. sie konfiguriert den Adressraum-Kontroller entsprechend. Wird die Sanktuarium Instanz an einen virtualisierten Prozessor oder Prozessorkern gebunden, so wechselt ein Prozessor des Endgerätes in den Hypervisor Modus und aktiviert die Speicherisolation durch eine entsprechende Konfiguration der Virtualisierungsmechanismen (z.B. eine entsprechende MMU) des Prozessors oder Prozessorkerns welcher der Sanktuarium Instanz zugewiesen wurde.
  • Ein weiterer Teil der Erfindung ist ein Endgerät, das entsprechende Prozessoren, Speicher, dauerhafte Speichermedien und eine entsprechende Architektur besitzt, um das vorgenannte Verfahren auszuführen. In der Regel handelt sich um bekannte mobile Endgeräte, deren Firmware und Softwarekonfiguration anzupassen ist, um das Verfahren auszuführen. Es kann sich aber auch um Server oder Personal Computer handeln, die entsprechende Firmware aufweisen.
  • Figurenliste
    • 1: Übersicht über die TEE-Architektur
    • 2: Übersicht über die Architektur der vorliegenden Erfindung wenn eine Sanktuarium Instanz einem physischen Prozessorkern zugewiesen wird, die gestrichelten Linien stellen die neuen Komponenten dar.
    • 3: Übersicht über die Architektur der vorliegenden Erfindung wenn eine Sanktuarium Instanz einem virtualisierten Prozessorkern zugewiesen wird. Die gestrichelten Linien stellen die neuen Komponenten dar.
  • Der Grundgedanke des Sanktuarium-Designs besteht darin, eine oder mehrere isolierte Ausführungsumgebungen bereitzustellen, in der sensibler Programmcode, der sensible Daten verarbeitet, ausgeführt werden kann. Diese isolierten Umgebungen werden Sanktuarium Instanzen genannt. Der in einer Sanktuarium Instanz laufende Programmcode ist vollständig von allem nicht vertrauenswürdigen Programmcode auf dem System getrennt und gleichzeitig ist er nicht Teil des vertrauenswürdigen Programmcodes des Systems, auch als Trusted Computing Base (TCB) bezeichnet. Tatsächlich muss der in einer Sanktuarium Instanz laufende Programmcode selbst nicht vertrauenswürdig sein, da er die Systemsicherheit nicht gefährden kann. Die Trennung vom vertrauenswürdigen Programmcode und anderem nicht vertrauenswürdigen Programmcode erfolgt, indem die Sanktuarium Instanzen jeweils auf einem dedizierten Prozessor oder Prozessorkern ausgeführt werden und Speicherbereiche ausschließlich diesen Prozessoren oder Prozessorkernen unter Verwendung geeigneter Isolationsmechanismen zugewiesen werden.
  • In der Praxis kann das Sanktuarium-Design z.B. dazu genutzt werden, bestehende TEE-Architekturen so zu erweitern, dass das volle Potenzial von TEEs endlich auf modernen mobilen Endgeräten genutzt werden kann. 2 zeigt eine generische TEE-Architektur, die um die Konstruktionsprinzipien des Sanktuariums erweitert wurde, wenn eine Sanktuarium Instanz einem physischen Prozessorkern zugewiesen wird. 3 zeigt eine erweiterte TEE-Architektur, wenn eine Sanktuarium Instanz einem virtualisierten Prozessorkern zugewiesen wird.
  • Wie in der traditionellen TEE-Architektur ist das System in eine normale und eine sichere Welt (Normal World / Secure World) unterteilt. In der normalen Welt besteht der nicht vertrauenswürdige Programmcode aus dem ungeschützten OS (Legacy OS) (1) und den ungeschützten Anwendungen (Legacy Apps) (2). In der sicheren Welt wird ein vertrauenswürdiges OS (Trusted OS) (3) zusammen mit vertrauenswürdigen Anwendungen (Trusted Apps) (4) ausgeführt. Einer der wichtigen Unterschiede zur Stand der Technik TEE-Architektur ist, dass die sichere Welt keinen Programmcode von einem Drittanbieter enthalten wird. Alle vertrauenswürdigen Anwendungen im TEE werden vom Gerätehersteller oder vom TEE-Anbieter bereitgestellt, wenn sie von einer zweiten Vertrauensperson entwickelt werden. Es bleibt dem Hersteller überlassen, welche Funktionalitäten er im TEE zur Verfügung stellt. Eine Änderung nach der Auslieferung an den Endkunden ist somit nicht oder nur mit einem sehr hohen Aufwand möglich.
  • Der sensible Drittanbietercode, der in Form einer benutzerdefinierten vertrauenswürdigen Anwendung in das TEE integriert werden musste, wird in einer Sanktuarium Instanz in Form einer Sanktuariumsanwendung (Sanctuary App) (10) isoliert. Das bedeutet, dass ein Mobilfunkanbieter statt einer kundenspezifischen vertrauenswürdigen Anwendung nun eine kundenspezifische Sanktuariumsanwendung entwickelt. Für jede Sanktuariumsanwendung gibt es vorzugsweise eine entsprechende ungeschützte Anwendung, die ebenfalls vom Mobilfunkanbieter entwickelt werden kann oder auch von Dritten, die z.B. auf Standardschnittstellen zugreifen.
    Die Sanktuarium Instanz besteht aus einer Sanktuariumsanwendung und einer Sanktuariumsbibliothek (Sanctuary Library) 9. Die Sanktuariumsbibliothek bietet einige grundlegende Prozess- und Speicherverwaltungsfunktionen für die Sanktuariumsanwendung, die z.B. mit unprivilegierten Rechten in der Sanktuarium Instanz läuft. Die Konstruktionsprinzipien einer Sanktuarium Instanz verlangen in einer möglichen Ausführungsform, dass nicht mehr als eine Sanktuariumsanwendung von unterschiedlichen Anbietern gleichzeitig in der Sanktuarium Instanz läuft, um Datenlecks zwischen verschiedenen mobilen Diensten zu verhindern. Eine Ausführung von mehreren Sanktuariumsanwendungen desselben Anbieters in einer Sanktuarium Instanz ist dagegen im Sanktuarium-Design möglich.
    Wie in 2 und 3 gezeigt, läuft der Sanktuarium-Code auf einem separaten Prozessorkern und ist daher vom nicht vertrauenswürdigen/unsicheren Programmcode der normalen Welt getrennt. Wird die Sanktuarium Instanz einem physischen Prozessorkern zugewiesen, wie in 2 dargestellt, wird der Sanktuariumsspeicherbereich vorzugsweise ebenfalls durch die TZASC-Hardwarekomponente (6) vom Rest des Systems getrennt. Die neueste Referenzimplementierung, der TZC-400, erlaubt es Speicherbereiche ausschließlich Bus-Mastern auf dem System zuzuweisen, die sich bei den Transaktionen, die sie über den Systembus senden, identifizieren. Die CPU, GPU und andere Peripheriegeräte wie ein Display-Kontroller fungieren als Bus-Master auf dem System. Der TZC-400 kann nun die von den Bus-Mastern gesendeten Identifikatoren verwenden um eine Speicherzugriffskontrolle durchzuführen. In aktuellen TEE-Architekturen wird diese Funktion des TZC-400, die als identitätsbasierte Filterung bezeichnet wird, nur für die Implementierung von Medienschutzanwendungen verwendet, bei denen der Speicher entweder der CPU oder der GPU zugewiesen ist. Im Sanktuarium-Design wird diese Funktion verwendet, um einen Speicherbereich ausschließlich dem einen physischen Prozessorkern zuzuweisen, auf dem der Sanktuarium-Code ausgeführt werden soll. Infolgedessen können die Prozessorkerne, die den Programmcode der normalen Welt ausführen, nicht auf die Speicherbereiche der Sanktuarium Instanzen zugreifen. Da die identitätsbasierte Filterfunktion, zumindest bisher, nicht im Cache-Speicher implementiert ist, werden der Sanktuarium-Code und dessen Daten nicht im gemeinsamen Cache-Speicher zwischen den Prozessorkernen des gleichen Prozessor-Clusters zwischengespeichert. Andernfalls könnte Programmcode in der normalen Welt Zugang zu Daten aus einer Sanktuarium Instanz erhalten. Auf ARM-basierten Systemen ist dieser gemeinsame Cache typischerweise der L2-Cache.
    Wird die Sanktuarium Instanz einem virtualisierten Prozessorkern zugewiesen, wie in 3 dargestellt, wird der Sanktuariumsspeicherbereich vorzugsweise durch Virtualisierungserweiterungen, z.B. eine entsprechend ausgebildete MMU 12, vom Rest des Systems getrennt. Seit der ARMv7 Architektur sind entsprechende Virtualisierungsmechanismen für ARM Prozessoren vorhanden. Die Speicherzugriffskontrolle der MMU erfolgt durch eine zweistufige Übersetzung von virtuellen Speicheradressen zu physikalischen Speicheradressen. Die Konfiguration der MMU kann nur in dem privilegierten Hypervisor-Modus EL2 erfolgen und wird vom Umschalt-Programmcode 11 durchgeführt. Auf diese Weise kann der Programmcode der normalen Welt, welcher in niedriger privilegierteren Betriebsmodi läuft (EL0 oder EL1) die MMU nicht mehr konfigurieren und daher nicht auf den Speicherbereich der Sanktuarium Instanz zugreifen. Da die Virtualisierungsmechanismen auch im Cache implementiert sind, können der Sanktuarium-Code und dessen Daten auch im Cache-Speicher abgelegt werden.
  • Sanktuarium Instanzen werden nicht immer im System ausgeführt bzw. konfiguriert. Nur wenn eine ungeschützte Anwendung verlangt, den sensiblen Programmcode ihrer entsprechenden Sanktuariumsanwendung auszuführen, wird eine Sanktuarium Instanz eingerichtet und bereitgestellt. Das spart Ressourcen auf dem System. Die Einrichtung und Verwaltung der Sanktuarium Instanzen erfolgt hauptsächlich durch die neuen Kernelmodule (Kernel Modules), Komponenten, die Teil des ungeschützten OS (7) und des vertrauenswürdigen OS (8) sind. Das Kernelmodul des ungeschützten OS wird hauptsächlich für das Sammeln der benötigten Ressourcen aus dem ungeschützten OS verwendet. Es wählt einen Prozessorkern aus, der als Sanktuarium-Kern verwendet werden soll und lädt die Binärdateien der Sanktuariumsanwendung und Sanktuariumsbibliothek in den Speicher. Alle sicherheitsrelevanten Verwaltungsaufgaben werden vom Kernelmodul des vertrauenswürdigen OS durchgeführt. Das Kernelmodul des vertrauenswürdigen OS stellt sicher, dass eine Sanktuarium Instanz tatsächlich von dem anderen nicht vertrauenswürdigen Programmode auf dem System getrennt ist. Es überprüft die Binärdatei der Sanktuariumsbibliothek und stellt sicher, dass die Sanktuarium Instanz korrekt eingerichtet ist. Zudem konfiguriert das Kernelmodul des vertrauenswürdigen OS den verwendeten Isolationsmechanismus. Soll die Sanktuariums Instanz einen physischen Prozessorkern zugewiesen werden, wie in 2 dargestellt, konfiguriert das Kernelmodule die TZASC-Komponente. Zudem wird die Hilfe der ARM Trusted Firmware TF benötigt, um zu überprüfen, ob der ausgewählte physische Sanktuarium-Kern ordnungsgemäß heruntergefahren wurde. Soll die Sanktuarium Instanz einem virtualisierten Prozessorkern zugewiesen werden, wie in 3 dargestellt, ruft das Kernelmodul den Umschalt-Programmcode 11 auf um die MMU zu konfigurieren. Nach der Konfiguration des Isolationsmechanismus und der Überprüfung der Sanktuariumsbibliothek kann die Sanktuarium Instanz gestartet werden. Dies wird vom Kernelmodul des ungeschützten OS angestoßen. Wird die Sanktuarium Instanz auf einem physischen Prozessorkern ausgeführt, nutzt das Kernelmodul die ARM TF um den Sanktuarium-Kern zu starten. Wird die Sanktuarium Instanz auf einem virtualisierten Prozessorkern ausgeführt, nutzt das Kernelmodul den Umschalt-Programmcode um die Ausführung des Sanktuarium-Codes anzustoßen.
  • Wenn eine Sanktuarium Instanz eingerichtet und in Betrieb ist, kann die Sanktuariumsanwendung mit der entsprechenden ungeschützten Anwendung kommunizieren, um Befehle oder unsensible Daten von ihr zu empfangen. Darüber hinaus kann es alle vertrauenswürdigen Funktionalitäten des Geräteherstellers und seiner vertrauenswürdigen Anwendungen nutzen. Dies bedeutet, dass eine Sanktuariumsanwendung sensible Daten aus dem TEE extrahieren und diese dann in einer isolierten Umgebung verarbeiten kann, die von der Sanktuarium Instanz bereitgestellt wird. Mit Hilfe des Kernelmoduls im vertrauenswürdigen OS kann eine vertrauenswürdige Anwendung immer sicherstellen, dass sensible Daten nur an eine korrekt eingerichtete Sanktuarium Instanz und an die legitime Sanktuariumsanwendung, die die Daten besitzt, weitergegeben werden. Wenn die Sanktuariumsanwendung die sensiblen Daten verarbeitet hat, können sie wieder im TEE gespeichert werden und nicht sensible Verarbeitungsergebnisse können an die ungeschützte Anwendung zurückgegeben werden. An dem Punkt, an dem eine Sanktuariumsanwendung auf einem Gerät installiert ist, wird sie niemals sensible Daten enthalten. Alle sensiblen Daten werden während der Laufzeit der Sanktuariumsanwendung bereitgestellt. Um dies zu erreichen, stellt das TEE einen Mechanismus mit seinen bewährten Funktionalitäten bereit, der es einem entfernten Server oder einem lokalen Programm ermöglicht, den korrekten Zustand einer Sanktuariumsanwendung zu überprüfen.
    Die Kommunikation der Sanktuariumsanwendung mit ihrer ungeschützte Anwendung oder einer vertrauenswürdigen Anwendung erfolgt über gemeinsame Speicherbereiche, während der zwischen ungeschützter Anwendung und Sanktuariumsanwendung geteilte Speicherbereich als ungeschützter gemeinsamer Speicher und der zwischen Sanktuariumsanwendung und vertrauenswürdiger Anwendung geteilte Speicher als geschützter gemeinsamer Speicher bezeichnet wird. Da der geschützte gemeinsame Speicher sensible Daten enthalten kann, ist er durch den verwendeten Isolationsmechanismus (TZASC-Hardwarekomponente oder MMU mit Virtualisierungserweiterungen) geschützt. 2 bzw. 3 zeigen beispielhaft, dass dem Prozessorkern mit der ID 0 bzw. A im Normal-Modus, der Zugriff auf die Speicheradresse 0x80 verweigert wird, da dieser Speicherbereich der Sanktuarium Instanz zugewiesen ist.
    Wenn eine Sanktuarium Instanz nicht mehr gebraucht wird und im Namen der ungeschützten Anwendung geschlossen wird, arbeiten die Kernelmodule des ungeschützten und vertrauenswürdigen OS zusammen, um die Sanktuarium Instanz so abzubauen, dass keine Daten aus dem Inneren der Sanktuarium Instanz vom Programmcode der normalen Welt aufgegriffen werden können. Alle aus dem ungeschützten OS entnommenen Ressourcen werden zurückgegeben.
  • Das Sanktuarium-Design kann zur Lösung der Probleme bestehender TEE-Architekturen verwendet werden. Durch das Verschieben des sensiblen Programmcodes von Drittanbietern aus der sicheren Welt in Sanktuarium Instanzen kann jeder Mobilfunkanbieter vom Gerätehersteller die Möglichkeit erhalten, den eigenen sensiblen Programmcode auf die Geräte zu übertragen. Der Grund dafür ist, dass der gesamte Sanktuarium-Code nicht Teil der TCB des Systems ist, was bedeutet, dass der Hersteller des Mobilgeräts diesem Programmcode nicht vertrauen muss. Der Sanktuarium-Code besitzt keine privilegierten Rechte auf dem System und ist dennoch vollständig von anderem nicht vertrauenswürdigen Programmcode isoliert. Die Isolation funktioniert in beide Richtungen. Der Programmcode der normalen Welt kann nicht auf die Speicherbereiche der Sanktuarium Instanzen zugreifen und der Programmcode der Sanktuarium Instanzen kann nicht auf den Speicherbereich der normalen Welt zugreifen. Daher deckt das Sanktuarium-Design sogar den Begriff einer bösartigen Sanktuariumsanwendung ab. Eine bösartige vertrauenswürdige Anwendung hingegen wird von den aktuellen TEE-Architekturen nicht abgedeckt.
    Aufgrund dieser Konstruktionsmerkmale kann der Einsatz von Sanktuariumsanwendungen so einfach sein wie der Einsatz von traditionellen ungeschützten Anwendungen, da keine umfangreichen Sicherheitsbewertungen der Sanktuariumsanwendungen erforderlich sind. Da das Sanktuarium-Design flexibel ist und nur ein einige neue Komponenten einführt, können die meisten bestehenden TEE-Lösungen so geändert werden, dass sie das Sanktuarium-Design umsetzen.
  • Eine mögliche Testimplementierung des Sanktuarium-Designs folgte der in 2 dargestellten Sanktuarium-Architektur. Als ungeschütztes OS (1) wird ein Linux verwendet, während die ungeschützten Anwendungen (2) durch C-Programme repräsentiert werden, die auf dem Linux-Kernel im Userspace laufen. Der Linux-Kernel wurde um ein eigenes Kernelmodul (7) erweitert. Als vertrauenswürdiges OS (3) wurde beispielsweise das Open-Source TEE namens OP-TEE verwendet, das auch die Implementierung von vertrauenswürdigen Anwendungen (4) ermöglicht. OP-TEE wurde um ein eigenes Kernelmodul (8) erweitert. Für die Sanktuariumsbibliothek (9) wurde der Zircon Mikrokernel wegen seiner relativ geringen Größe von 1 MB verwendet und weil er eine vollwertige Userspace-Umgebung bietet. Die Sanktuariumsanwendungen (10) sind als C-Programme geschrieben, die auf dem Zircon Mikrokernel laufen. Als Monitor-Programmcode wurde eine leicht modifizierte Version der ARM Trusted Firmware verwendet.
    In der Testimplementierung wurden zwei vertrauenswürdige Anwendungen implementiert, die einige grundlegende vertrauenswürdige Funktionalitäten bieten, die für die Implementierung der meisten mobilen Dienste auf einem Gerät benötigt werden. Eine vertrauenswürdige Anwendung bietet einige Fernzertifizierungsfunktionen, mit denen der Zustand einer Sanktuariumsanwendung von einem entfernten Server aus überprüft werden kann. Wie bereits erwähnt, wird diese Funktionalität benötigt, um sensible Daten auf das Gerät zu übertragen. Die zweite vertrauenswürdige Anwendung bietet einige Versiegelungsfunktionen, mit denen beliebige Daten einer Sanktuariumsanwendung sicher und dauerhaft auf dem Gerät gespeichert werden können. Diese vertrauenswürdige Anwendung stellt auch sicher, dass nur die berechtigte Sanktuariumsanwendung ihre gespeicherten Daten extrahieren kann.
    In der Testimplementierung wurde das reale Szenario einer One-Time-Password (OTP) Generator-Anwendung implementiert, die für die Zwei-Faktor-Authentifizierung weit verbreitet ist. Die Anwendung besteht aus einer ungeschützten Komponente in der normalen Welt und einer Sanktuariumsanwendung. Mit Hilfe der zwei vertrauenswürdigen Anwendungen kann die Generator-Anwendung einen geheimen Schlüssel von einem entfernten Server anfordern und diesen dann sicher aufbewahren. Zu einem späteren Zeitpunkt kann die Sanktuariumsanwendung mit dem Schlüssel und dem aktuellen Zeitstempel ein neues OTP erzeugen, welches dann an die ungeschützte Komponente der Generator-Anwendung geschickt und dem Benutzer angezeigt wird, der eine Zwei-Faktor-Authentifizierung durchführen möchte.
  • Da der OTP-Generierungsalgorithmus sensible Daten (den geheimen Schlüssel) verarbeitet, muss dieser zur Laufzeit geschützt werden. In aktuellen TEE-Architekturen wäre eine eigene vertrauenswürdige Anwendung im TEE erforderlich. Die vorliegende Implementierung hat gezeigt, dass dasselbe mit dem Sanktuarium-Design ohne die Notwendigkeit von Drittanbietercode im TEE erreicht werden kann. Die Bewertung der Implementierung zeigt, dass die Sanktuarium-Architektur praktisch ist und keinen hohen Leistungsverlust verursacht. Wichtig für die implementierte Variante bei der die Sanktuarium Instanz an einen physischen Prozessorkern gebunden wird ist, dass die Speichertrennung auf einer Pro-Kern-Basis in Hardware durchsetzbar ist.
  • Der Grund dafür ist, dass die Identifikatoren, die den verschiedenen Bus-Mastern im System zugeordnet sind, in Hardware vergeben werden und nicht per Software verändert werden können. Durch Experimente mit Virtualisierungstools von ARM, den so genannten ARM Fast Models, wurde festgestellt, dass jedem Prozessorkern mit minimalem Aufwand eindeutige Identifikatoren zugewiesen werden können, wenn die Hardware eines mobilen Geräts entworfen wird. Zudem lassen sich durch einen Filtermechanismus diese Identifikatoren auf alle Transkationen der Bus-Master übertragen welche diese über den Systembus senden.
  • Bezugszeichenliste
    • 1
    ungeschütztes OS (Legacy OS)
    2
    ungeschützte Anwendung (Legacy App)
    3
    Vertrauenswürdiges OS (Trusted OS)
    4
    Vertrauenswürdige Anwendung (Trusted App)
    5
    ARM Trusted Firmware
    6
    Adressraum-Kontroller (Trust Zone Address Space Controller) (TZASC)
    7
    Kernelmodul (Kernel Module)
    8
    Kernelmodul (Kernel Module)
    9
    Sanktuariumsbibliothek (Sanctuary Library)
    10
    Sanktuariumsanwendung (Sanctuary App)
    11
    Umschalt-Programmcode (Switching Code)
    13
    Memory Management Unit (MMU)
  • 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 Nicht-Patentliteratur
    • V. Costan and S. Devadas. Intel sgx explained. IACR Cryptology ePrint Archive, 2016:86, 2016 [0009]
    • V. Costan, I. A. Lebedev, and S. Devadas. Sanctum: Minimal hardware extensions for strong software isolation. in USENIX Security Symposium, pages 857-874, 2016 [0009]
    • J. Noorman, P. Agten, W Daniels, R. Strackx, A. Van Herrewege, C. Huygens, B. Preneel, I. Verbauwhede, and F. Piessens. Sancus: Low-cost trustworthy extensible networked devices with a zero-software trusted computing base. in 22nd USENIX Security symposium, USENIX Sec, pages 479-494, 2013 [0009]
    • J. Noorman, J. V. Bulck, J. T. Mühlberg, F. Piessens, P. Maene, B. Preneel, I. Verbauwhede, J. Götzfried, T. Müller, and F. Freiling. Sancus 2.0: A low-cost security architecture for iot devices. ACM Transactions on Privacy and Security (TOPS), 20(3):7, 2017 [0009]

Claims (14)

  1. Verfahren zur Bereitstellungen von isolierten und abgesicherten Ausführungsumgebungen auf einem Endgerät, das durch einen oder mehrere Prozessoren mit einem oder mehreren Prozessorkernen gesteuert wird, wobei der Prozessor eine erste vertrauenswürdige Ausführungsumgebung und eine zweite ungeschützte Ausführungsumgebung zur Verfügung stellen und ausführen, wobei in der vertrauenswürdigen Ausführungsumgebung mindestens eine vertrauenswürdige Anwendung (4) ausgeführt wird, die sensible Daten verarbeitet, und wobei in der ungeschützten Ausführungsumgebung eine ungeschützte Anwendung (2) ausgeführt wird, gekennzeichnet durch eine oder mehrere weitere Ausführungsumgebungen, genannt Sanktuarium Instanzen, welche isoliert von der ersten und zweiten Ausführungsumgebung sind und jeweils auf einem dedizierten Prozessor oder dedizierten Prozessorkern, wobei diese physisch oder virtualisiert vorhanden sein können, ausgeführt werden, und ein Sankturariumsspeicherbereich der ausschließlich dem jeweiligen Prozessor oder Prozessorkern zugeordnet ist, wobei in einer Sanktuarium Instanz mindestens eine Sanktuariumsanwendung (10) ausgeführt wird, wobei eine Sanktuariumsanwendung (10) sowohl mit einer oder mehreren ungeschützten Anwendungen (2) als auch mit einer oder mehreren vertrauenswürdigen Anwendungen (4) über mindestens einen Kommunikationskanal interagiert, wobei wenn die ungeschützte Anwendung (2) eine Kommunikationsanfrage an die vertrauenswürdige Anwendung (4) vornimmt, wird die Kommunikationsanfrage umgelenkt auf die Sanktuariumsanwendung (10), die dann die Kommunikationsanfrage unter Durchführung einer Kommunikation mit der vertrauenswürdigen Anwendung (4) verarbeitet.
  2. Das Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass die Sanktuariumsanwendung nach Auslieferung des Endgeräts austauschbar ist, wobei die vertrauenswürdige Anwendung in der vertrauenswürdigen Ausführungsumgebung beim Endkunden nur mit Hilfe eines Herstellers des Endgerätes austauschbar ist.
  3. Das Verfahren nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Endgerät ein mobiles Endgerät für ein Mobilfunknetzwerk ist, insbesondere für GSM und LTE, und die Sanktuariumsanwendung nach Auslieferung des Endgeräts durch einen Betreiber des Mobilfunknetzwerks über das Mobilfunknetzwerk austauschbar ist.
  4. Das Verfahren nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die vertrauenswürdige Ausführungsumgebung mindestens eine vertrauenswürdige Anwendung ausführt, die eine Funktionalität zur Verfügung stellt, die nicht dem Zwecke der Verwaltung, insbesondere der Bereitstellung, der Sanktuarium Instanzen dient.
  5. Das Verfahren nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass für die Sanktuariumsanwendung eine Sanktuariumsbibliothek (9) bereitgestellt wird, die grundlegende Prozess- und/oder Speicherverwaltungsfunktionen bereitstellt, insbesondere um mit der vertrauenswürdigen Anwendung zu interagieren, insbesondere zu kommunizieren.
  6. Das Verfahren nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Sanktuariumsbibliothek entsprechend ausgebildet ist, um einen bösartigen Zugriff auf grundlegende Prozess- und/oder Speicherverwaltungsfunktionen einzuschränken.
  7. Das Verfahren nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Sankturariumsspeicherbereich durch eine Hardware-Speicherzugriffskontrollkomponente, insbesondere durch einen Adressraum-Kontroller (6), von der ungeschützten Ausführungsumgebung abgetrennt wird und ausschließlich dem Prozessor oder Prozessorkern zugewiesen wird, auf dem die Sanktuarium Instanz ausgeführt wird.
  8. Das Verfahren nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Kommunikation der Sanktuariumsanwendung mit Hilfe der Sanktuariumsbibliothek mit einer vertrauenswürdigen Anwendung über gemeinsame Speicherbereiche erfolgt, wobei die gemeinsamen Speicherbereiche zwischen Sanktuariumsbibliothek und vertrauenswürdiger Anwendung durch den Adressraum-Kontroller geschützt werden.
  9. Das Verfahren nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine Sanktuarium Instanz nur bei Bedarf aufgebaut und ausgeführt wird, insbesondere wenn eine Kommunikationsanfrage an die vertrauenswürdige Anwendung (4) vorliegt, erst dann wird durch eine Komponente, vorzugsweise unter Verwendung eines Kernelmoduls (7) in der ungeschützten Ausführungsumgebung eine Sanktuarium Instanz eingerichtet.
  10. Das Verfahren nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Kernelmodul(7) den Prozessor oder Prozessorkern, der für eine Sanktuarium Instanz verwendet werden soll, auswählt und die Binärdateien von Sanktuariumsbibliothek und Sanktuariumsanwendung lädt, sowie die Kommunikation dann einleitet.
  11. Das Verfahren nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in der vertrauenswürdigen Ausführungsumgebung eine Komponente (8) ausgeführt wird, vorzugsweise als Kernelmodul, die überprüft, ob eine Sanktuarium Instanz korrekt eingerichtet ist, und nur dann eine Kommunikation mit einer vertrauenswürdigen Anwendung erlaubt, wenn eine korrekte Einrichtung der Sanktuarium Instanz vorliegt.
  12. Das Verfahren nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Prozessor oder Prozessorkern einen RISC-Befehlssatz verwendet.
  13. Das Verfahren nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die vertrauenswürdige Ausführungsumgebung durch eine gesonderte Prozessorerweiterung realisiert wird, die zusätzlich zu Privilegien-Stufen, die zur Unterteilung in Anwendungs-, Betriebssystem- und Hypervisor-Modus, eine weitere, orthogonale Unterteilung ermöglicht, welche insbesondere eine systemweite Hardwareisolation für vertrauenswürdige Software bietet, vorzugsweise durch durch eine ARM-TrustZone implementiert ist.
  14. Endgerät, vorzugsweise mobiles Endgerät gekennzeichnet durch eine Einrichtung und Ausstattung, um das Verfahren nach einem oder mehreren der vorhergehenden Verfahrensansprüche auszuführen.
DE102018132970.9A 2018-10-10 2018-12-19 Verfahren und Vorrichtung zur Isolation von sensiblem nichtvertrauenswürdigem Programmcode auf mobilen Endgeräten Pending DE102018132970A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US17/287,617 US20210397700A1 (en) 2018-10-10 2019-10-02 Method and apparatus for isolating sensitive untrusted program code on mobile device
EP19783279.3A EP3864548A1 (de) 2018-10-10 2019-10-02 Verfahren und vorrichtung zur isolation von sensiblem nicht-vertrauenswürdigem programmcode auf mobilen endgeräten
PCT/EP2019/076774 WO2020074354A1 (de) 2018-10-10 2019-10-02 Verfahren und vorrichtung zur isolation von sensiblem nicht-vertrauenswürdigem programmcode auf mobilen endgeräten

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102018125073 2018-10-10
DE102018125073.8 2018-10-10

Publications (1)

Publication Number Publication Date
DE102018132970A1 true DE102018132970A1 (de) 2020-04-16

Family

ID=69954289

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102018132970.9A Pending DE102018132970A1 (de) 2018-10-10 2018-12-19 Verfahren und Vorrichtung zur Isolation von sensiblem nichtvertrauenswürdigem Programmcode auf mobilen Endgeräten

Country Status (4)

Country Link
US (1) US20210397700A1 (de)
EP (1) EP3864548A1 (de)
DE (1) DE102018132970A1 (de)
WO (1) WO2020074354A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3975029A1 (de) * 2020-09-29 2022-03-30 Renesas Electronics Corporation Verfahren und system zum erzeugen von und zugreifen auf schutzdienste für sichere dienste und operationen dafür

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114490448A (zh) * 2020-11-13 2022-05-13 华为技术有限公司 一种切换执行环境的方法及其相关设备
TWI783410B (zh) * 2021-03-16 2022-11-11 瑞昱半導體股份有限公司 電子裝置以及其休眠恢復方法
CN113239329B (zh) * 2021-04-19 2024-03-19 南京大学 一种用于移动端应用程序的可信执行环境的实现系统
CN113791898B (zh) * 2021-08-24 2022-07-26 电子科技大学 一种基于TrustZone的可信微内核操作系统
US20220103557A1 (en) * 2021-12-08 2022-03-31 Intel Corporation Mechanism for managing services to network endpoint devices

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6321337B1 (en) * 1997-09-09 2001-11-20 Sanctum Ltd. Method and system for protecting operations of trusted internal networks
US20130205361A1 (en) * 2012-02-02 2013-08-08 Juniper Networks, Inc. Dynamic threat protection in mobile networks
EP2433388B1 (de) * 2009-05-20 2017-03-29 Microsoft Technology Licensing, LLC Verfahren und system für eine sichere fernverbindung mit einem tragbaren datenspeicher
US20170364294A1 (en) * 2000-08-08 2017-12-21 Faronics Corporation Method and system for automatically preserving persistent storage

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7568102B2 (en) * 2004-07-15 2009-07-28 Sony Corporation System and method for authorizing the use of stored information in an operating system
US8935746B2 (en) * 2013-04-22 2015-01-13 Oracle International Corporation System with a trusted execution environment component executed on a secure element
US9775029B2 (en) * 2014-08-22 2017-09-26 Visa International Service Association Embedding cloud-based functionalities in a communication device
US10146940B2 (en) * 2016-01-13 2018-12-04 Gbs Laboratories, Llc Multiple hardware-separated computer operating systems within a single processor computer system to prevent cross-contamination between systems
US10733284B2 (en) * 2016-10-06 2020-08-04 Samsung Electronics Co., Ltd. Trusted execution environment secure element communication

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6321337B1 (en) * 1997-09-09 2001-11-20 Sanctum Ltd. Method and system for protecting operations of trusted internal networks
US20170364294A1 (en) * 2000-08-08 2017-12-21 Faronics Corporation Method and system for automatically preserving persistent storage
EP2433388B1 (de) * 2009-05-20 2017-03-29 Microsoft Technology Licensing, LLC Verfahren und system für eine sichere fernverbindung mit einem tragbaren datenspeicher
US20130205361A1 (en) * 2012-02-02 2013-08-08 Juniper Networks, Inc. Dynamic threat protection in mobile networks

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
VASUDEVAN, Amit et al.: Lockdown: A Safe and Practical Environment for Security Applications (CMU-CyLab-09-011). Pittsburgh, PA : Carnegie Mellon University, 2009. URL: https://kilthub.cmu.edu/ndownloader/files/11896472 [abgerufen am 2. September 2019] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3975029A1 (de) * 2020-09-29 2022-03-30 Renesas Electronics Corporation Verfahren und system zum erzeugen von und zugreifen auf schutzdienste für sichere dienste und operationen dafür
US11734414B2 (en) 2020-09-29 2023-08-22 Renesas Electronics Corporation Method and system for generating and accessing guard services for secure services and operations thereof

Also Published As

Publication number Publication date
US20210397700A1 (en) 2021-12-23
WO2020074354A1 (de) 2020-04-16
EP3864548A1 (de) 2021-08-18

Similar Documents

Publication Publication Date Title
DE102018132970A1 (de) Verfahren und Vorrichtung zur Isolation von sensiblem nichtvertrauenswürdigem Programmcode auf mobilen Endgeräten
DE112018002031B4 (de) Sichern einer betriebssystemkonfiguration unter verwendung von hardware
DE60306952T2 (de) Zuordnung von virtuellen zu physischen speicheradressen in einem system mit einem sicheren bereich und einem nicht sicheren bereich
DE102007062745B4 (de) Vorrichtung und Verfahren zum schnellen und sicheren Speicherkontextwechsel
DE102008006759B4 (de) Prozessor-Anordnung und Verfahren zum Betreiben der Prozessor-Anordnung ohne Verringerung der Gesamtsicherheit
DE102009013384B4 (de) System und Verfahren zur Bereitstellung einer sicheren Anwendungsfragmentierungsumgebung
DE112011102876T5 (de) Ressourcenverwaltungs- und Sicherheitssystem
DE102012210887A1 (de) Verfahren zum Einrichten einer sicher verwalteten Ausführungsumgebung für eine virtuelle Maschine, Programm und Computervorrichtung
DE102014002181B4 (de) Chip und Verfahren zum Betreiben eines Chips
DE102018127330A1 (de) System-on-Chip und Verfahren zum Betreiben eines System-on-Chip
DE60305315T2 (de) Originalitätsgesichertes herausnehmbares medium mit ausführbarem kode
DE102008050631A1 (de) Datenverarbeitungssystem
DE602004002241T2 (de) Schutz eines auf ausführungwartenden Programms in einem Speicher für einen Mikroprozessor
WO2021122734A1 (de) Verfahren und vorrichtung zum betreiben einer recheneinrichtung
DE102020122702A1 (de) System-on-Chip und Verfahren zum Betreiben eines System-on-Chip
DE60017438T2 (de) System zur betriebsmittelzugriffsteuerung
DE102009048756B4 (de) Verfahren und Schlüsselgerät zur Verbesserung der Sicherheit eines verschlüsselten Datenspeichers, von dem ein Computer bootet
DE102021110768B3 (de) Forensik-Modul und eingebettetes System
DE102021110766B3 (de) Forensik-Modul und eingebettetes System
EP3690690B1 (de) Verfahren zum prüfen einer validität von daten und computerimplementierte vorrichtung zum verarbeiten von daten
DE102010052246A1 (de) Verfahren zum Zugang zu einem Betriebssystem, Wechselspeichermedium und Verwendung eines Wechselspeichermediums
DE102007005637B4 (de) Computereinrichtung, Kommunikationseinrichtung und Verfahren zum Betreiben einer Computereinrichtung
WO2023036672A1 (de) Ausführen von privilegierten operationen in einem container
DE102015207004A1 (de) Verfahren zum geschützten Zugriff auf Sicherheitsfunktionen eines Sicherheitsmoduls eines Hostsystems
EP4287050A1 (de) Überwachung eines anwendungsprogramms in abhängigkeit dessen privilegs

Legal Events

Date Code Title Description
R163 Identified publications notified
R081 Change of applicant/patentee

Owner name: SANCTUARY SYSTEMS GMBH, DE

Free format text: FORMER OWNERS: BAYERISCHE MOTOREN WERKE AKTIENGESELLSCHAFT, 80809 MUENCHEN, DE; TECHNISCHE UNIVERSITAET DARMSTADT, 64289 DARMSTADT, DE

Owner name: BAYERISCHE MOTOREN WERKE AKTIENGESELLSCHAFT, DE

Free format text: FORMER OWNERS: BAYERISCHE MOTOREN WERKE AKTIENGESELLSCHAFT, 80809 MUENCHEN, DE; TECHNISCHE UNIVERSITAET DARMSTADT, 64289 DARMSTADT, DE