EP3529734A1 - Geräteeinheit geeignet für den betrieb im geschützten und/oder offenen betriebszustand sowie zugehöriges verfahren - Google Patents

Geräteeinheit geeignet für den betrieb im geschützten und/oder offenen betriebszustand sowie zugehöriges verfahren

Info

Publication number
EP3529734A1
EP3529734A1 EP17791592.3A EP17791592A EP3529734A1 EP 3529734 A1 EP3529734 A1 EP 3529734A1 EP 17791592 A EP17791592 A EP 17791592A EP 3529734 A1 EP3529734 A1 EP 3529734A1
Authority
EP
European Patent Office
Prior art keywords
operating state
operating
device unit
protected
integrity
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
EP17791592.3A
Other languages
English (en)
French (fr)
Inventor
Hans Aschauer
Rainer Falk
Steffen Fries
Markus Heintel
Dominik Merli
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.)
Siemens AG
Original Assignee
Siemens AG
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 Siemens AG filed Critical Siemens AG
Publication of EP3529734A1 publication Critical patent/EP3529734A1/de
Pending legal-status Critical Current

Links

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/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
    • G06F21/575—Secure boot
    • 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
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • 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
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • 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/107—License processing; Key processing
    • 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/2105—Dual mode as a secondary aspect

Definitions

  • the present invention relates to an apparatus unit geeig ⁇ net for the operation in the protected and / or open state of operation and associated method and an associated computer program Com ⁇ (-product).
  • Embedded systems are often used in the environment of Industry 4.0, in the industrial Internet and in automation systems. You can in
  • a so-called boot loader loads the operating system and the application software when booting the system. Furthermore, this offers the possibility to update the operating system and application software in flash memory.
  • Processors (CPUs) for embedded systems such as Freescale / NXP i.MX6 or ti Sitara, FPGA-based system-on-chips such as Xilinx Zynq or Altera Cyclone V SoC or Prozes ⁇ sors Intel Atom with UEFI Secure Boot support. Secure Boot ensures that only authorized, unaltered software or firmware is executed. It is Anfor ⁇ lenge of protecting the integrity of industrial control devices or embedded systems.
  • UEFI BIOS For a PC-based system with UEFI BIOS is the Mög ⁇ friendliness that the verification key for Secure Boot can be reset by an authorized user. However, this is not possible on embedded platforms where the keys are burned in so-called fuses (combustible fuses). In addition, this UEFI BIOS variant has the disadvantage that the security level of Secure Boot essentially depends on the security of the BlOS password. This creates a lot of effort to keep the BlOS password safe. Ins ⁇ particular, a user can change with access to BIOS configuration settings and the Secure Boot configuration.
  • boot loaders such as Submarine for Linux-based embedded systems in some variants Secure Boot.
  • the Linux kernel can check the integrity (correctness, integrity) of kernel modules and load only properly signed kernel modules.
  • Temporal Correctness There are relevant temporal Bedin ⁇ conditions such as sequences or maximum Verzögerungszei ⁇ th, are complied with.
  • the limitation of Secure Boot by license terms is specifically known in the GPL licenses.
  • the invention claims a device unit, in particular an embedded device unit comprising a module which can configure the device unit with an operating condition of different ⁇ current operating conditions at the start-up procedure and / or during operation of the appliance unit.
  • the module can in this case be designed in the form of hardware and / or firmware and / or software.
  • a first protected operating state of the different operating states is designed to permit the loading and / or execution of at least one predeterminable operating sequence and, if appropriate, to protect the predeterminable operating sequence with defined cryptographic means.
  • the predeterminable operating sequence can be implemented by one or more program codes or can also be configured as such a module.
  • At least one second Be ⁇ operating state of the different operating states is adapted to archive the first protected mode to deakti ⁇ and at least one other modifiable operation (also (in program code s) / module implemented) sen zuzulas- or to enable and these optionally substituted with vorgeb ⁇ protect cryptographic means.
  • the module If the configured mode speaks ent ⁇ the first operating condition, the module retains this in, or when the kon ⁇ figured operating state corresponding to the at least second operating state, the module disables the first operation ⁇ condition and to maintain or passes the at least second Be ⁇ operating state at /.
  • the deactivation can be irrevocable.
  • Specified cryptographic means are here to be ver ⁇ stand that manufacturer-side updates, for example, by a firmware update are possible, but the user side no change ments can be made and thus enshrined or preconfigured or specified for the user.
  • the module can configure the Ge ⁇ and units of so that is introduced or taken during operation of the first or the second operating condition after the power-up sequence.
  • the device unit runs high in the first operating state, then the first operating state can be maintained during the configuration or it is changed to the second operating state in the configuration, then the now configured operating state corresponds to the second operating state, in which case the first operating state is deactivated becomes. 3.
  • the unit will power up in the second operating state, then the second operating state will be maintained in the configuration. Accordingly, the configured operating state corresponds to the second operating state, wherein the first operating state is nevertheless deactivated in order to prevent a "return" to the first operating state.
  • the first operating state corresponds to an operating state preconfigured by a device manufacturer and the second operating state corresponds to one by a user
  • the cryptographic means may be, for example, device configuration or protection means such as keys (from the device manufacturer), certificates, etc.
  • a development of the invention provides that the device unit is configured as an embedded system or as part of a system embedded ⁇ .
  • a refinement of the invention provides that, if the operating state is to be protected during the high-speed operation and / or during ongoing operation of the device unit, the device can be provided or provided with suitable integrity protection measures during startup and / or during operation.
  • Integrity safeguards during the high-speed operation can be eg cryptographically protected file system, cryptographically protected configuration data in EEPROM. Integrity protection measures at runtime can be eg process monitoring, host-based intrusion detection system.
  • a further development of the invention provides that in the protected operating state, the integrity protection measures further comprise device authentication and / or device integrity certification.
  • a further development of the invention provides that, depending on the operating state of at least one key for integrity protection measures ⁇ device side or from a user
  • each have a device certificate for both operating modes may be available ge ⁇ provides.
  • a private or shared device authentication key can be provided.
  • a further development of the invention provides that the deactivation of the protected operating state can be carried out by deleting the at least one key and / or revoking the device certificate made available for the protected operating state. If necessary, the certificate may fikat be restored by a so-called certification authority (CA).
  • CA certification authority
  • a development of the invention provides that parts of the device unit can be activated and / or deactivated. Depending on the operating state can also activates a hardware-related function of the device or Kings ⁇ nen eg These disabled or configured a trust anchor in addition to the software-related functions, a hardware-based
  • Device integrity monitoring or an integrity watchdog a hardware-based self-test function, a self- monitoring ⁇ sensor, a tamper sensor for detecting tampering or a communication unit that provides, for example, an integrity confirmation signal can be used.
  • a development of the invention provides that the module by means of one or more software and / or
  • a development of the invention provides that the one or the software and / or firmware program codes
  • sealable are sealable.
  • the seal can be carried out by means of a hash value or by means of a value from a reference database.
  • a development of the invention provides that at least one further third operating state of the device unit is designed to permit the first and the second operating state in parallel operation and, if necessary, to protect cryptographically.
  • a development of the invention provides that the first, second and possibly the third operating state by device configuration, so-called jumpers, activation codes and / or by the key and / or by the device certificate and / or the revocation state of the device certificate and / or by a trust anchor and / or by a Communication protocol with another body can be specified.
  • Another aspect of the invention provides a method for loading a drive device unit in an operating state of un ⁇ teretzlichen operating conditions during start-up sequence
  • the first ge ⁇ protected operating state is in a further second operating state turned off and allowed at least one other modifiable operation and, if appropriate, is protected with predeterminable cryptographic means, the operating state before and / or during the startup procedure and / or the running operation configured or is determined, and if the configured Radiozu ⁇ state of the first operating state, then this is retained or if the configured operating state of the at least second operating state, the first Be ⁇ operating state (possibly irrevocably) to deactivate and initiate the at least second operating state and / or retained at ⁇ .
  • the method may be according to the embodiments / developments of the above-mentioned unit unit or trained.
  • a further aspect of the invention is a computer program product having at least one computer program which has means for carrying out the method according to one of the preceding method claims if the at least one computer program can be loaded into the memory of a device unit and its embodiments and executed ,
  • the computer program (product) can essentially be developed or developed analogously to the method and its embodiments or further developments.
  • FIG. 1 shows a device unit, preferably an embedded device unit,
  • Figure 2 shows schematically a flow chart, which steps can be performed on the device unit.
  • FIG. 1 shows an apparatus unit GE, which may be integrated as a device alreadystal ⁇ tet or in a device.
  • the device unit GE for a Linux-based embedded device ⁇ (embedded device), preferably a field device or a so-called IOT device. It can
  • the kernel K in the example a Linux kernel, lau ⁇ fen usually hardware- and firmware-or software-based modules as a Mandatory Access Control module MAC and Runtime Integrity Monitor Module RIM from.
  • a hardware or firm- or software-based key module KM for storing and managing crypto-raphischen keys, a hardware- or firm- or software-based integrity monitoring module I (Integrity
  • the apparatus unit can configurable into at least two un ⁇ ter Kunststofflichen operating states or modes of operation and / or operate.
  • a first so-called “closed mode” - or second so-called “open mode” - operation ⁇ mode or in a further third hybrid operating mode a kind of combination of the two aforementioned loading triebsmodi "open mode” and "closed mode", the devices will use ⁇ ness can be operated.
  • the decision as to which mode of operation should be initiated or executed is preferably made at system startup (also called booting).
  • FIG. 2 shows a flowchart whose individual steps are identified by S 1 to S 7.
  • step S2 At system start Sl or Hochfahrablauf the Radiomo ⁇ dus is determined or selected (S2).
  • step S3 When the operation mode in step S3 is "closed mode”, then in step S4, the run-time integrity verification is performed (Runtime Integrity Check).
  • step S5 the access to the Attes ⁇ t ists slaughterl is released for device integrity.
  • step S6 When the operation mode in step S3 is not Is "closed mode”, then the operation is skipped with step S6, whereby the "end” in step S7 symbolically describes the end of the described procedure and does not have to mean the end of the current operation.
  • Embedded systems such as the equipment unit shown above GE, especially for critical industrial control systems often have built-in protection functions / -means to prevent the execution of manipulated source ⁇ kode (also called secure boot) or erken ⁇ nen (also called runtime integrity check).
  • manipulated source ⁇ kode also called secure boot
  • erken ⁇ nen also called runtime integrity check
  • a configurable device unit with two operating modes is used, the configuration being software-based.
  • a first mode of operation called closed mode
  • only software or firmware that has been authorized by the device manufacturer is executable, typically with a digital signature verifiable with a public manufacturer key (platform key) on the device.
  • platform key public manufacturer key
  • the device unit In the so-called “closed mode” continue runtime integrity checks active. This can monitor runtime, that only authorized software (processes) and operations are carried out and that the device configuration or stabilizers such as keys, certificates, etc. unchanged and unve ⁇
  • a second operating mode called “open mode”
  • the device unit In a second operating mode, called “open mode”, a user can load and execute their own software or changed software. For this he can deactivate the first operating mode or set up another platform key.
  • the device unit preferably has an integrity confirmation function, which provides cryptographically protected device integrity information via a communication interface, eg, a device display. authentication function or device integrity assertion information.
  • the operating mode (open or closed) must be explicitly encoded in the integrity confirmation function, e.g. as a flag.
  • a key for forming the cryptographic device integrity information may be selected or released.
  • the encoded mode of operation should be designed so that it is not subject to the GPL or similar license described in the beginning.
  • the module (M) must not be changeable, i. it must be secured by integrity protections (e.g., Secure Boot).
  • cryptographic keys used for device integrity protection in closed mode are cleared or permanently or temporarily disabled when the open mode is activated.
  • a request for the revocation of the certificate is generated by the device unit upon activation of the "open mode" and, if appropriate, sent to a third location, for example a certificate authorization authority (certificate authority).
  • the device checks its own device certificate (device manufacturer certificate).
  • This Certificate can contain information, such as whether the device certificate for "closed mode” or "open mode” is vorgese ⁇ hen as a X.509v3 extension or the device identifier.
  • the module (M) activates the operating mode (open, closed) depending on the configured device certificate. This has the advantage that most ⁇ te technologies and processes can be used for certificate issuance and distribution to a device for
  • the device unit selects one of several configured device certificates for use in operation, depending on the operating mode.
  • the device checks to see if its own manufacturer's device certificate has been revoked or deleted (e.g., using a Certificate Revocation List (CRL) or a Certificate Status Response (OCSP Response)).
  • CTL Certificate Revocation List
  • OCSP Response Certificate Status Response
  • the device unit allows the activation of the "Open Mode” when the associated "Closed Mode” Acting the "Closed Mode” Acting the "Open Mode” when the associated "Closed Mode” Acting the "Open Mode” when the associated "Closed Mode” Acting the "Open Mode” Acting the "Open Mode” when the associated "Closed Mode” Acting the "Open Mode” Acting the "Open Mode” when the associated "Closed Mode” Acting the "Closed Mode” Actgentzerti ⁇ fikat back was or revoked. This has the advantage that known technologies and processes for certificate revocation can be used to unlock a device for an "open mode".
  • a hardware-related function of the device can also be activated or deactivated or configured (eg a trust anchor, a hardware-based device integrity monitoring eg RIM or Integrity Watchdog I, a hardware-based self-test ⁇ function, a self-monitoring sensor, a tamper sensor for detecting tampering or a communication unit, for example, provides an integrity confirmation signal).
  • a trust anchor e.g a hardware-based device integrity monitoring eg RIM or Integrity Watchdog I
  • a hardware-based self-test ⁇ function e.g a hardware-based self-test ⁇ function
  • a self-monitoring sensor e.g a tamper sensor for detecting tampering or a communication unit, for example, provides an integrity confirmation signal.
  • the operating mode can be determined or configured in different ways and, if appropriate, then maintained, defined or selected: - Device configuration settings (eg UEFI BIOS, device configuration)
  • the device unit supports another third mode of operation which simultaneously allows for the two first and second modes of operation, called “combined mode.”
  • a third mode of operation which simultaneously allows for the two first and second modes of operation
  • two CPUs / SoCs may or may not be provided by means of a hypervisor, two separate execution environments are provided on a shared hardware.
  • This "combined mode” may represent a third configurable or selectable operating mode, or may be permanently provided as the sole combined mode of operation.
  • the device has two Principalsum ⁇ environments, a "closed mode” -Aus entrysumdecidian (the operation mode) and an "Open Mode” -Aus entrysumdecidecince.
  • a “closed mode” -Aus entrysumdecidecidecidecidecidecidecidecidecidecidecidecidecidecidecidecitory a user's own software or changed Load and execute software (eg for operating or execution time, at system start, or when importing a firmware update).
  • the closed-mode execution environment can only load authorized applications signed by a device manufacturer's software signature key, Secure Boot and Runtime Integrity Monitoring are active for the "Closed Mode” execution environment, ie for the parts of the software signed by the manufacturer, ie only the "Closed Mo ⁇ de” execution environment is covered by the device integrity protection features.
  • the device supports sealing of loaded user software (in the "open mode” of the device unit or for the "open mode” execution environment). It is provided in addition to equipment integrity protection function for the "closed mode", an additional device integrity ⁇ protection function for the "Open Mode". A user may, under his own control, load software for the "open mode.” By "sealing" the device unit configuration, this user-loaded software state is frozen. In this case, the reference information for the Runtime Integrity protection of the device unit (Secure Boot, Runtime Integrity Monitor RIM) is "taught”.
  • the Secure Boot checks that the "Open Mode" software version detected during sealing is loaded, eg a software hash hash value can be captured during sealing, and it can be checked during subsequent system booting
  • the user software can be signed with a device key by the device unit
  • Integrity Monitoring RIM the software loaded by the user when sealing the device in the reference database (with so-called “white” or “black” lists are included.
  • Processor or bound to specific execution schemes can be performed by software, firmware, microcode, hardware, Prozes ⁇ sensors, integrated circuits, etc. in stand-alone mode or in any combination.
  • Various processing strategies can be used, for example serial processing by a single processor or multiprocessing or multitasking or parallel processing, etc.
  • the instructions can be stored in local memories, but it is also possible to store the instructions on a remote system and then via Network access.
  • processor central signal processing
  • Control unit or “data evaluation means” as here USAGE ⁇ det, processing means includes in the broad sense, that is, for example, servers, general purpose processors, Gardnerluxo ⁇ ren, digital signal processors, application specific inte ⁇ grated circuits (ASICs), programmable logic circuits, such as FPGAs, discrete analog or digital circuits and be ⁇ undesirables combinations thereof, and any other processing means known in the art or developed in the future.
  • Processors can be one or more Devices or devices or units exist. Be a processor of several devices, they can be designed or configured for parallel or sequential processing or execution of instructions.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Stored Programmes (AREA)
  • Storage Device Security (AREA)

Abstract

Die vorliegende Erfindung beansprucht eine Geräteeinheit (GE) umfassend ein Modul (M), welches die Geräteeinheit (GE) mit einem Betriebszustand von unterschiedlichen Betriebszuständen beim Hochfahrablauf und/oder bei laufendem Betrieb der Geräteeinheit konfigurieren kann, wobei ein erster geschützter Betriebszustand der unterschiedlichen Betriebszustände dazu ausgelegt ist, das Ausführen von zumindest einem vorbestimmbaren Betriebsablauf zuzulassen und diesen gegebenenfalls mit festgelegten kryptographischen Mitteln zu schützen, wobei mindestens ein zweiter Betriebszustand der unterschiedlichen Betriebszustände dazu ausgelegt ist, den ersten ge- schützten Betriebszustand zu deaktivieren und zumindest einen anderen änderbaren Betriebsablauf zuzulassen und diesen gegebenenfalls mit vorgebbaren kryptographischen Mitteln zu schützen, und wobei, wenn der konfigurierte Betriebszustand dem ersten Betriebszustand entspricht, das Modul (M) diesen beibehält oder wenn der konfigurierte Betriebszustand dem mindestens zweiten Betriebszustand entspricht, das Modul (M) den ersten Betriebszustand deaktiviert und den mindestens zweiten Betriebszustand einleitet und/oder beibehält.

Description

Beschreibung
Geräteeinheit geeignet für den Betrieb im geschützten
und/oder offenen Betriebszustand sowie zugehöriges Verfahren
Die vorliegende Erfindung betrifft eine Geräteeinheit geeig¬ net für den Betrieb im geschützten und/oder offenen Betriebszustand sowie zugehöriges Verfahren und ein zugehöriges Com¬ puterprogramm (-produkt) .
Hintergrund der Erfindung
Eingebettete Systeme (Embedded Systems bzw. Devices) kommen oft im Umfeld von Industrie 4.0, im industriellen Internet und in Automatisierungssystemen zum Einsatz. Sie können in
Einzelfällen auf ähnlicher Hardware wie Arbeitsplatzcomputer basieren. Für sie sind jedoch in der Regel stark einschränkende Randbedingungen wie minimale Kosten, geringer Platz-, Energie- und Speicherverbrauch gefordert. Einzelne Komponen- ten wie Prozessor und Arbeitsspeicher basieren oft auf Weiterentwicklungen älterer Komponenten. Dadurch wird die langfristige Einsetzbarkeit und Ersatzteilbeschaffung erleichtert. Jüngere eingebettete Systeme basieren häufig auf Pro¬ zessorplattformen, die in Bezug auf die Peripheriemodule ho- chintegriert sind und durch moderne Stromspartechniken deut¬ lich weniger Energie verbrauchen. In einem eingebetteten System muss die Software oft EchtZeitanforderungen genügen. Die Software auf einem solchen Gerät wird Firmware genannt. Sie befindet sich gewöhnlich auf einem ROM, immer häufiger jedoch auf Flashspeicher. Anwendungsspezifische Software wird auch als Anwendungssoftware oder Applikation bezeichnet.
Ein sogenannter Bootloader sorgt für das Laden des Betriebssystems und der Applikationssoftware beim Hochlauf des Sys- tems . Weiter bietet dieser die Möglichkeit, Betriebssystem und Applikationssoftware im Flashspeicher zu aktualisieren. Prozessoren (CPUs) für eingebettete Systeme, wie z.B. Freescale/NXP i.MX6 oder ti Sitara, FPGA-basierte System on Chips wie Xilinx Zynq oder Altera Cyclone V SoC oder Prozes¬ soren Intel Atom mit UEFI unterstützen Secure Boot. Secure Boot stellt dazu sicher, dass nur autorisierte, unveränderte Software bzw. Firmware ausgeführt wird. Es besteht die Anfor¬ derung, die Integrität von industriellen Steuergeräten bzw. eingebetteten Systemen zu schützen. Bei einem PC-basierten System mit UEFI-BIOS besteht die Mög¬ lichkeit, dass die PrüfSchlüssel für Secure Boot durch einen berechtigten Nutzer neu gesetzt werden können. Auf Embedded- Plattformen, bei denen die Schlüssel in sogenannte Fuses (brennbare Sicherungen) gebrannt sind, ist dies jedoch nicht möglich. Außerdem hat diese UEFI-BIOS-Variante den Nachteil, dass das Sicherheitsniveau von Secure Boot im Wesentlichen an der Sicherheit des BlOS-Passworts hängt. Dadurch entsteht ein hoher Aufwand, um das BlOS-Passwort sicher zu verwahren. Ins¬ besondere kann ein Nutzer mit Zugriff auf BIOS- Konfigurationseinstellungen auch die Secure Boot Konfiguration ändern.
Weiterhin unterstützen Bootloader wie z.B. U-Boot für Linuxbasierte eingebettete Systeme in manchen Varianten Secure Boot. Auch der Linux Kernel kann die Integrität (Korrektheit, Unversehrtheit) von Kernel-Modulen prüfen und nur korrekt signierte Kernel Module laden.
Es sind verschiedene Arten von Integrität von Nachrichten, Prozessen bzw. Programmen möglich, die in der Informationssicherheit geprüft werden können:
- Korrekter Inhalt
- Unmodifizierter Zustand
- Erkennung von Modifikation, wenn unerwünschte Modifikationen verhindert werden können. Temporale Korrektheit: Es sollen relevante zeitliche Bedin¬ gungen, wie etwa Reihenfolgen oder maximale Verzögerungszei¬ ten, eingehalten werden. Die Beschränkung von Secure Boot durch Lizenzbedingungen ist speziell bei den GPL-Lizenzen bekannt.
Die dadurch entstehende Problematik ist auch unter dem Begriff Tivoisierung bekannt. „Tivoisierung" beschreibt den Vorgang, dass freie Software auf Geräten zum Einsatz kommt, auf denen nur vom Hersteller signierte Software lauffähig ist. Der Nutzer hat dann zwar der Lizenz nach das Recht, sich den Quellkode zu besorgen und nach seinen Vorstellungen zu ändern, nicht jedoch die techni- sehe Möglichkeit, die von ihm veränderte Software auf das Ge¬ rät des Herstellers aufzuspielen. Nach bestimmten Lizenzbedingungen kann es für den Hersteller erforderlich sein, den Quellkode bereitzustellen bzw. sogar die kryptographischen Schlüssel bzw. Zugangskodes herauszugeben. Im Falle von Secu- re Boot würde dies die Sicherheit und Integrität von solchen eingebetteten Systemen gefährden.
Es besteht ein Bedarf, die Integrität eines (industriellen) Steuerungssystems zu schützen und trotzdem einem Nutzer die Freiheit zu geben, ggf. eine modifizierte Software bzw. Firm¬ ware auf diesem Gerät nutzen zu können. Dadurch soll jedoch die Sicherheit eines industriellen Automatisierungs- und Steuerungssystems nicht gefährdet werden. Es ist Aufgabe der Erfindung, unter Bereitstellung einer offenen Umgebung für nutzerspezifische Anwendungssoftware den¬ noch Sicherheits- bzw. Schutzmaßnahmen für ein eingebettetes System sicherzustellen. Darstellung der Erfindung Diese Aufgabe wird durch die unabhängigen Patentansprüche ge¬ löst. Vorteilhafte Weiterbildungen sind Gegenstand der abhän¬ gigen Ansprüche. Die Erfindung beansprucht eine Geräteeinheit, insbesondere eine eingebettete Geräteeinheit, umfassend ein Modul, welches die Geräteeinheit mit einem Betriebszustand von unterschied¬ lichen Betriebszuständen beim Hochfahrablauf und/oder bei laufendem Betrieb der Geräteeinheit konfigurieren kann. Das Modul kann hierbei in Form von Hardware- und/oder Firmware- und/oder Software ausgestaltet sein.
Ein erster geschützter Betriebszustand der unterschiedlichen Betriebszustände ist dabei dazu ausgelegt, das Laden und/oder Ausführen von zumindest einem vorbestimmbaren Betriebsablauf zuzulassen und den vorbestimmbaren Betriebsablauf gegebenenfalls mit festgelegten kryptographischen Mitteln zu schützen. Dabei kann der vorbestimmbare Betriebsablauf durch ein oder mehrere Programmkodes implementiert sein oder auch als ein solches Modul ausgestaltet sein. Mindestens ein zweiter Be¬ triebszustand der unterschiedlichen Betriebszustände ist dazu ausgelegt, den ersten geschützten Betriebszustand zu deakti¬ vieren und zumindest einen anderen änderbaren Betriebsablauf (ebenfalls in Programmkode ( s ) /Modul implementierbar) zuzulas- sen bzw. zu ermöglichen und diesen gegebenenfalls mit vorgeb¬ baren kryptographischen Mitteln zu schützen. Wenn der konfigurierte Betriebszustand dem ersten Betriebszustand ent¬ spricht, dann behält das Modul diesen bei, oder wenn der kon¬ figurierte Betriebszustand dem mindestens zweiten Betriebszu- stand entspricht, deaktiviert das Modul den ersten Betriebs¬ zustand und behält bzw. leitet den mindestens zweiten Be¬ triebszustand bei/ein.
Die Deaktivierung kann unwiderruflich sein.
Festgelegte kryptographische Mittel sind hierbei so zu ver¬ stehen, dass herstellerseitig Aktualisierungen z.B. durch ein Firmwareupdate möglich sind, jedoch nutzerseitig keine Ände- rungen vorgenommen werden können und somit für den Nutzer festgeschrieben bzw. vorkonfiguriert bzw. festgelegt sind.
Bei einem Hochfahrablauf sind folgende Startbetriebszustände denkbar:
1. Eine Art neutraler Betriebszustand, der nur während des Hochfahrablaufs eingenommen wird. Dann kann das Modul die Ge¬ räteeinheit so konfigurieren, dass nach dem Hochfahrablauf im laufenden Betrieb der erste oder der zweit Betriebszustand eingeleitet bzw. eingenommen wird.
2. Die Geräteeinheit läuft im ersten Betriebszustand hoch, dann kann die der ersten Betriebszustand bei der Konfigurati- on beibehalten werden oder es wird bei der Konfiguration zum zweiten Betriebszustand gewechselt, dann entspricht der nun konfigurierte Betriebszustand dem zweiten Betriebszustand, wobei dann der erste Betriebszustand deaktiviert wird. 3. Die Geräteeinheit läuft im zweiten Betriebszustand hoch, dann wird der zweite Betriebszustand bei der Konfiguration beibehalten werden. Demnach entspricht der konfigurierte Betriebszustand dem zweiten Betriebszustand, wobei der erste Betriebszustand trotzdem deaktiviert wird, um eine „Rückkehr" zum ersten Betriebszustand zu verhindern.
Normalerweise entspricht der erste Betriebszustand einem von einem Gerätehersteller vorkonfigurierten Betriebszustand und der zweite Betriebszustand einen von einem Nutzer
konfigurierbaren Betriebszustand.
Die kryptographischen Mittel können beispielsweise Gerätekonfiguration bzw. Schutzmittel wie Schlüssel (vom Gerätehersteller), Zertifikate, etc. sein.
Eine Weiterbildung der Erfindung sieht vor, dass die Geräteeinheit als ein eingebettetes System oder als Teil eines ein¬ gebetteten Systems ausgestaltet ist. Eine Weiterbildung der Erfindung sieht vor, dass gerätesei- tig, wenn der Betriebszustand während des Hochfahrablaufs und/oder bei laufendem Betrieb der Geräteeinheit geschützt werden soll, für beim Hochlauf geeignete und/oder im laufenden Betrieb geeignete Integritätsschutzmaßnahmen bereitgestellt sind bzw. bereitgestellt werden können.
Integritätsschutzmaßnahmen beim Hochfahrablauf können z.B. kryptographisch geschütztes Dateisystem, kryptographisch geschützte Konfigurationsdaten in EEPROM sein. Integritätsschutzmaßnahmen zur Laufzeit können z.B. Prozessüberwachung, Host-based Intrusion Detection System sein. Eine Weiterbildung der Erfindung sieht vor, dass im geschützten Betriebszustand die Integritätsschutzmaßnahmen des Weiteren eine Geräteauthentifizierung und/oder eine Geräteintegritätsattestierung umfassen. Eine Weiterbildung der Erfindung sieht vor, dass abhängig vom Betriebszustand wenigstens ein Schlüssel für die Integritäts¬ schutzmaßnahmen geräteseitig oder von einem Nutzer
bereitstellbar ist bzw. bereitgestellt werden können. Eine Weiterbildung der Erfindung sieht vor, dass jeweils ein Gerätezertifikat für beide Betriebszustände zur Verfügung ge¬ stellt werden kann.
Weiterhin kann je nach Betriebszustand ein privater oder ge- heimer Geräteauthentifizierungsschlüssel bereitgestellt wer¬ den kann.
Eine Weiterbildung der Erfindung sieht vor, dass die Deakti- vierung des geschützten Betriebszustandes durch ein Löschen des wenigstens einen Schlüssels und/oder Widerruf des für den geschützten Betriebszustand zur Verfügung gestellten Gerätezertifikats durchführbar ist. Gegebenenfalls kann das Zerti- fikat durch eine sogenannte Zertifizierungsauthority (CA) wiederhergestellt werden.
Eine Weiterbildung der Erfindung sieht vor, dass Teile der Geräteeinheit aktivierbar und/oder deaktivierbar sind. Abhängig von dem Betriebszustand kann neben den Software-bezogenen Funktionen auch eine Hardware-bezogene Funktion des Gerätes aktiviert oder deaktiviert bzw. konfiguriert werden Dazu kön¬ nen z.B. ein Vertrauensanker, eine Hardware-basierte
Geräteintegritätüberwachung bzw. ein Integrity Watchdog, eine Hardware-basierte Selbsttestfunktion, ein Selbstüberwachungs¬ sensor, ein Tamper-Sensor zum Erkennen von Manipulationen oder eine Kommunikationseinheit, die z.B. ein Integritätsbe- stätigungssignal bereitstellt, verwendet werden.
Eine Weiterbildung der Erfindung sieht vor, dass das Modul mittels ein oder mehrerer Software- und/oder
Firmwareprogrammkodes und/oder Hardwareschaltung
konfigurierbar ist.
Eine Weiterbildung der Erfindung sieht vor, dass der eine oder die Software- und/oder Firmwareprogrammkodes
versiegelbar sind. Die Versiegelung kann mittels eines Hash- werts bzw. mittels eines Werts aus einer Referenzdatenbank durchgeführt werden.
Eine Weiterbildung der Erfindung sieht vor, dass mindestens ein weiterer dritter Betriebszustand der Geräteeinheit dazu ausgelegt ist, den ersten und den zweiten Betriebszustand im Parallelbetrieb zuzulassen und gegebenenfalls kryptographisch zu schützen.
Eine Weiterbildung der Erfindung sieht vor, dass der erste, zweite und gegebenenfalls der dritte Betriebszustand durch Gerätekonfiguration, sogenannte Jumper, Aktivierungscodes und/oder durch den Schlüssel und/oder durch das Gerätezertifikat und/oder des Widerrufzustands des Gerätezertifikats und/oder durch einen Vertrauensankers und/oder durch eine Kommunikationsprotokoll mit einer weiteren Stelle festlegbar ist .
Ein weiterer Aspekt der Erfindung sieht ein Verfahren zum Be- treiben einer Geräteeinheit in einem Betriebszustand von un¬ terschiedlichen Betriebszuständen beim Hochfahrablauf
und/oder bei laufendem Betrieb der Geräteeinheit vor, wobei in einem ersten geschützten Betriebszustand das (Laden und/oder) Ausführen von zumindest einem vorbestimmbaren Be- triebsablaufs zugelassen und gegebenenfalls mit festgelegten kryptographischen Mitteln geschützt wird und
wobei in einem weiteren zweiten Betriebszustand der erste ge¬ schützte Betriebszustand deaktiviert wird und zumindest ein anderer änderbarer Betriebsablauf zugelassen und gegebenen- falls mit vorgebbaren kryptographischen Mitteln geschützt wird, wobei der Betriebszustand vor und/oder während des Hochfahrablaufs und/oder des laufenden Betriebs konfiguriert bzw. ermittelt wird und wenn der konfigurierte Betriebszu¬ stand dem ersten Betriebszustand entspricht, dann diesen bei- zubehalten oder wenn der konfigurierte Betriebszustand dem mindestens zweiten Betriebszustand entspricht, den ersten Be¬ triebszustand (ggf. unwiderruflich) zu deaktivieren und den mindestens zweiten Betriebszustand einzuleiten und/oder bei¬ zubehalten .
Das Verfahren kann entsprechend der Ausführungsformen/Weiterbildungen zur oben genannten Geräteeinheit aus- bzw. weitergebildet sein. Ein weiterer Aspekt der Erfindung ist ein Computerprogrammprodukt mit mindestens einem Computerprogramm, das Mittel zur Durchführung des Verfahrens nach einem der vorstehenden Verfahrensansprüche aufweist, wenn das mindestens eine Computer¬ programm in den Speicher einer Geräteeinheit und deren Aus- führungsformen ladbar ist und zur Ausführung gebracht wird. Das Computerprogramm (-produkt) kann im Wesentlichen analog wie das Verfahren und dessen Ausgestaltungen bzw. Weiterbildungen entsprechend aus- bzw. weitergebildet werden. Ausführungsbeispiel (e) :
Weitere Vorteile, Einzelheiten und Weiterbildungen der Erfindung ergeben sich aus der nachfolgenden Beschreibung von Ausführungsbeispielen in Verbindung mit den Zeichnungen.
Dabei zeigen:
Figur 1 eine Geräteeinheit, vorzugsweise eine eingebettete Geräteeinheit,
Figur 2 schematisch ein Ablaufdiagramm, welche Schritte auf der Geräteeinheit ausgeführt werden können.
Figur 1 zeigt eine Geräteeinheit GE, die als Gerät ausgestal¬ tet oder in ein Gerät integriert sein kann. Im folgenden Aus- führungsbeispiel ist die Geräteeinheit GE für ein Linux¬ basiertes eingebettetes Gerät (Embedded Device) , vorzugsweise ein Feldgerät oder ein sogenanntes IOT-Gerät. Es kann
mehrere Anwendungen bzw. Applikationen z.B. AI, A2, ausführen. Zudem kann ein Steuerungsalgorithmus DMA (Device Manage- ment Agent) und/oder ein BIST (Built-in Selbst Test) ausge¬ führt werden. Im Kernel K, im Beispiel ein Linux-Kernel, lau¬ fen in der Regel hardware- bzw. firm- bzw. softwarebasierte Module wie ein Mandatory Access Control Modul MAC und ein Runtime Integrity Monitor Modul RIM ab. Außerdem ist auf der Geräteeinheit ein hardware- bzw. firm- bzw. softwarebasiertes Schlüsselmodul KM zur Speicherung und Verwaltung von kryptog- raphischen Schlüsseln, ein hardware- bzw. firm- bzw. softwarebasierte Integritätsüberwachungsmodul I (Integrity
Watchdog) und ein hardware- bzw. firmware- bzw. softwareba- siertes Device Mode Manager vorhanden. Ein hardware-, firmwa¬ re- und/oder softwarebasiertes Modul M, auch Device Mode Ma¬ nager genannt, kann die Geräteeinheit in mindestens zwei un¬ terschiedlichen Betriebszuständen bzw. Betriebsmodi konfigu- rieren und/oder betreiben. In einem ersten sogenannten „closed mode"- oder zweiten sogenannte „open mode"- Betriebs¬ modus oder in einem weiteren dritten Hybrid-Betriebsmodus, also eine Art Kombination aus beiden zuvor genannten Be- triebsmodi „open mode" und „closed mode", kann die Geräteein¬ heit betrieben werden. Die Entscheidung, welcher Betriebsmodus eingeleitet oder ablaufen soll, erfolgt vorzugsweise beim Systemstart (auch Booten genannt) . Abhängig vom aktivierten Betriebsmodus der Geräteeinheit werden die Module De- vice Key Manager KM, Integrity Watchdog I, Runtime Integrity Monitor RIM, Mandatory Access Control Modul MAC und der Selbsttest BIST durch das Modul M (Device Mode Manager) kon¬ figuriert . Das Modul M kann abhängig vom aktuellen Betriebsmodus eine kryptographisch geschützte Attestierungsinformation bereitstellen, die den Betriebsmodus angibt. Der Selbsttest BIST, insbesondere inklusive Dateisystem-Integritätsprüfung, Monitor RIM, Mandatory Access Control Modul MAC und Integrity Watchdog sind abhängig vom Betriebsmodus aktiv oder verwenden eine vom Betriebsmodus abhängige Regel (Policy) . Das Modul KM (Device Key Manager) kann den Schlüssel abhängig vom Betriebsmodus sperren oder löschen. Figur 2 zeigt ein Ablaufdiagramm, dessen einzelne Schritte mit Sl bis S7 gekennzeichnet sind.
Beim Systemstart Sl bzw. Hochfahrablauf wird der Betriebsmo¬ dus ermittelt bzw. ausgewählt (S2) . Wenn der Betriebsmodus in Schritt S3 „closed mode" ist, dann wird in Schritt S4 die Laufzeit-Integritätsüberprüfung (Runtime Integrity Check) durchgeführt. In Schritt S5 wird der Zugriff auf den Attes¬ tierungsschlüssel zur Geräteintegrität freigegeben. Wenn der Betriebsmodus in Schritt S3 nicht „closed mode" ist, dann wird mit Schritt S6 in den laufende Betrieb übergangen, wobei das „Ende" in Schritt S7 symbolisch das Ende des beschrieben Ablaufs beschreibt und nicht das Ende des laufenden Betriebs bedeuten muss. Im Folgenden sind weitere Ausführungsformen beschrieben:
Eingebettete Systeme wie beispielsweise die oben dargestellte Geräteeinheit GE, insbesondere für kritische industrielle Steuerungssysteme, verfügen häufig über integrierte Schutz- Funktionen/-mittel , um das Ausführen von manipuliertem Quell¬ kode zu verhindern (auch secure boot genannt) oder zu erken¬ nen (auch runtime integrity check genannt) .
Solche Funktionen würden jedoch auch verhindern, dass ein Nutzer von ihm beabsichtigt geänderte Software auf einem sol¬ chen Gerät ausführen kann. Demnach wird erfindungsgemäß eine konfigurierbare Geräteinheit mit zwei Betriebsarten einge- setzt, wobei die Konfiguration softwarebasiert sein kann.
In einem ersten Betriebsmodus, genannt „Closed Mode", ist nur Software bzw. Firmware ausführbar, die vom Gerätehersteller autorisiert wurde. Üblicherweise weist die Software dazu eine digitale Signatur auf, die mit einem öffentlichen Herstellerschlüssel (Plattformschlüssel) auf dem Gerät überprüfbar ist.
Im sogenannten „Closed Mode" sind weiterhin Runtime- Integrity-Checks aktiv. Diese können zur Laufzeit überwachen, dass nur zugelassene Software (-Prozesse) bzw. Betriebsabläufe ausgeführt werden und dass Gerätekonfiguration bzw. Schutzmittel wie Schlüssel, Zertifikate etc. unverändert und unve¬ ränderbar sind. In einem zweiten Betriebsmodus, genannt „Open Mode", kann ein Nutzer eigene Software bzw. geänderte Software laden und ausführen. Dazu kann er den ersten Betriebsmodus deaktivieren oder einen anderen Plattformschlüssel einrichten. Die Geräteeinheit verfügt im „Closed Mode" vorzugsweise über eine Integritätsbestätigungsfunktion, die eine kryptogra- phisch geschützte Gerätintegritätsinformation über eine Kommunikationsschnittstelle bereitstellt, z.B. eine Geräteau- thentisierungsfunktion oder eine Geräteintegritätsattestie- rungsinformation .
Im „Open Mode" wird geräteseitig dagegen keine Gerätintegri- tätsinformation oder eine andere Gerätintegritätsinformation bereitgestellt .
Es kann z.B. der Betriebsmodus (open oder closed) in der In- tegritätsbestätigungsfunktion explizit einkodiert sein, z.B. als Flag. Es kann abhängig vom Betriebsmodus ein Schlüssel zur Bildung der kryptographischen Geräteintegritätsinformation ausgewählt bzw. freigegeben werden. Es können also zwei Integritätsbestätigungs-Schlüssel , einen Gerätehersteller- Integritätsbestätigungs-Schlüssel und einen Nutzer- definierbaren Integritätsbestätigungs-Schlüssel geben.
Das oben genannte Hardware- oder Software- bzw. Firmware- Modul M, das die Entscheidung zwischen „Closed
Mode" (geschlossenen bzw. geschützten Betriebsmodus) und „Open Mode" (offenen Betriebsmodus) trifft bzw. den ggf.
einkodierten Betriebsmodus erkennt, soll so ausgestaltet sein, dass es nicht der eingangs beschriebenen GPL- oder einer ähnlichen Lizenz unterliegt. Zusätzlich darf das Modul (M) nicht veränderbar sein, d.h. es muss durch Integritäts- Schutzmaßnahmen (z.B. Secure Boot) abgesichert werden.
In einer Ausführungsform werden kryptographische Schlüssel, die zum Geräteintegritätsschutz im „closed mode" verwendet werden, gelöscht, oder dauerhaft bzw. temporär gesperrt, wenn der „open mode" aktiviert bzw. eingeleitet wird. In einer weiteren Ausführungsform wird eine Anfrage des Zertifikatswiderrufs bei einer Aktivierung des „open mode" von der Geräteeinheit erzeugt und ggf. an eine dritte Stelle z.B. eine Zertifikatsauthorisierungsstelle ( Zertifikatsauthority) ge- sendet.
In einer weiteren Ausführungsform prüft das Gerät sein eigenes Gerätezertifikat (Geräteherstellerzertifikat) . Dieses Zertifikat kann eine Information enthalten, z.B. in Form einer X.509v3 Erweiterung oder des Gerätebezeichners , ob das Gerätezertifikat für „closed mode" oder „open mode" vorgese¬ hen ist. In einer weiteren Ausführungsform aktiviert das Mo- dul (M) den Betriebsmodus (open, closed) abhängig vom konfigurierten Gerätezertifikat. Dies hat den Vorteil, das bekann¬ te Technologien und Prozesse zur Zertifikatsausstellung und Verteilung verwendet werden können, um ein Gerät für
einen „open mode" freizuschalten. In einer weiteren Ausfüh- rungsform wählt die Geräteeinheit abhängig vom Betriebsmodus eines von mehreren konfigurierten Gerätezertifikaten für die Verwendung im Betrieb aus .
In einer weiteren Ausführungsform prüft das Gerät, ob das ei- gene Hersteller-Gerätezertifikat widerrufen bzw. gelöscht wurde (z.B. unter Verwendung einer Zertifikatswiderrufsliste (CRL) oder einer Zertifikatsstatusantwort (OCSP Response) ) .
Die Geräteeinheit ermöglicht die Aktivierung des „Open Mode", wenn das dem „Closed Mode" zugeordnete Geräteherstellerzerti¬ fikat zurück- bzw. widerrufen wurde. Dies hat den Vorteil, dass bekannte Technologien und Prozesse zum Zertifikatswiderruf verwendet werden können, um ein Gerät für einen „open mode" freizuschalten.
Weiterhin kann abhängig von dem Betriebsmodus „open" / „closed" neben den Software-bezogenen Funktionen auch eine Hardware-bezogen Funktion des Gerätes aktiviert oder deaktiviert bzw. konfiguriert werden (z.B. ein Vertrauensanker, ei- ne Hardware-basierter Geräteintegritätüberwachung z.B. RIM bzw. Integrity Watchdog I, eine Hardware-basierte Selbsttest¬ funktion, ein Selbstüberwachungssensor, ein Tamper-Sensor zum Erkennen von Manipulationen oder eine Kommunikationseinheit, die z.B. ein Integritätsbestätigungssignal bereitstellt).
Im oben genannten Schritt S2 kann der Betriebsmodus auf unterschiedliche Art ermittelt bzw. konfiguriert und ggf. dann beibehalten, festgelegt bzw. ausgewählt werden: - Geräte-Konfigurationseinstellungen (z.B. UEFI BIOS, Gerätekonfiguration)
- Sogenannte Jumper
- Eingabe eines Freischaltkodes zum Aktivieren des „Open Modes" Implizit über die Firmware-Signatur (der Closed-Mode wird bei Laden bzw. Starten einer mit einem Geräteherstellerschlüssel signierten Firmware aktiviert, ansonsten wird der Open Mode gestartet) .
- Implizit über das konfigurierte Gerätezertifikat
- Über den oben erwähnten WiderrufStatus eines Gerätezertifi¬ kats
- Durch den Zustand eines im System verbauten Vertrauensankers
- Durch ein Aushandlungs-Protokoll mit einer dritten Stellen z.B. einem Remote Server
In einer Ausführungsform unterstützt die Geräteeinheit einen weiteren dritten Betriebsmodus, der gleichzeitig die beiden ersten und zweiten Betriebsmodi, „Combined Mode" genannt, zu- lässt. Dazu können z.B. zwei CPUs/SoCs (Ein-Chip-System) vorgesehen sein, oder es können mittels eines Hypervisors zwei separierte Ausführungsumgebungen auf einer gemeinsam genutzten Hardware bereitgestellt werden. Dieser „Combined Mode" kann einen dritten konfigurierbaren bzw. ermittelbaren bzw. wählbaren Betriebsmodus darstellen, oder kann dauerhaft als einziger kombinierter Betriebsmodus vorgesehen sein.
Im „Combined Mode" verfügt das Gerät über zwei Ausführungsum¬ gebungen, eine „Closed Mode"-Ausführungsumgebung (Betriebsmo- dus) und eine „Open Mode"-Ausführungsumgebung . Für die „Open Mode"-Ausführungsumgebung kann ein Nutzer eigene Software oder geänderte Software laden und ausführen (z.B. zur Betriebs- bzw. Ausführungszeit, beim Systemstart, oder beim Einspielen eines Firmware-Updates) . Für die „Closed Mode"- Ausführungsumgebung können dagegen nur autorisierte, d.h. mittels eines Geräteherstellerzertifizierten Softwaresignaturschlüssel signierte Anwendungen geladen werden. Secure Boot und Runtime Integrity Monitoring sind aktiv für die „Closed Mode"-Ausführungsumgebung, d.h. für die vom Hersteller signierten Teile der Software. D.h. nur die „Closed Mo¬ de"- Ausführungsumgebung wird durch die Geräteintegritäts- schutzfunktionen erfasst.
In einer weiteren Ausführungsform unterstützt das Gerät ein Versiegeln von geladener Nutzersoftware (im „Open Mode" der Geräteeinheit bzw. für die „Open Mode"-Ausführungsumgebung) . Hierbei ist zusätzlich zur Geräteintegritätsschutzfunktion für den „Closed Mode" eine zusätzliche Geräteintegritäts¬ schutzfunktion für den „Open Mode" vorgesehen. Dabei kann ein Nutzer unter eigener Kontrolle, Software für den „Open Mode" laden. Durch ein „Versiegeln" der Geräteeinheitskonfiguration wird dieser vom Nutzer geladene Software-Stand festgefroren. Dabei erfolgt ein „Anlernen" der Referenzinformation für den Runtime Integrity Schutz der Geräteeinheit (Secure Boot, Runtime Integrity Monitor RIM) .
Bei einem im versiegelten Zustand erfolgenden Secure Boot wird überprüft, dass der beim Versiegeln erfasste Software- Stand des „Open Mode" geladen wird. Dazu kann z.B. ein Hash- Wert des Software Stands beim Versiegeln erfasst und beim nachfolgenden Systemstarts überprüft werden, oder es kann die Nutzersoftware mit einem Geräteschlüssel durch die Geräteein- heit signiert werden. Weiterhin kann für ein Runtime
Integrity Monitoring RIM die vom Nutzer geladene Software beim Versiegeln des Gerätes in die Referenzdatenbank (mit sogenannten „weißen" bzw. „schwarzen" Listen aufgenommen werden .
Obwohl die Erfindung im Detail durch das bevorzugte Ausführungsbeispiel näher illustriert und beschrieben wurde, so ist die Erfindung nicht durch die offenbarten Beispiele einge¬ schränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen . Die Implementierung der vorstehend beschriebenen Prozesse oder Verfahrensabläufe kann anhand von Instruktionen erfol¬ gen, die auf computerlesbaren Speichermedien oder in flüchtigen Computerspeichern (im Folgenden zusammenfassend als com- puterlesbare Speicher bezeichnet) vorliegen. Computerlesbare Speicher sind beispielsweise flüchtige Speicher wie Caches, Puffer oder RAM sowie nichtflüchtige Speicher wie Wechselda¬ tenträger, Festplatten, usw. Die vorstehend beschriebenen Funktionen oder Schritte können dabei in Form zumindest eines Instruktionssatzes in/auf einem computerlesbaren Speicher vorliegen. Die Funktionen oder Schritte sind dabei nicht an einen bestimmten Instruktions¬ satz oder an eine bestimmte Form von Instruktionssätzen oder an ein bestimmtes Speichermedium oder an einen bestimmten
Prozessor oder an bestimmte Ausführungsschemata gebunden und können durch Software, Firmware, Microcode, Hardware, Prozes¬ soren, integrierte Schaltungen usw. im Alleinbetrieb oder in beliebiger Kombination ausgeführt werden. Dabei können ver- schiedenste Verarbeitungsstrategien zum Einsatz kommen, beispielsweise serielle Verarbeitung durch einen einzelnen Prozessor oder Multiprocessing oder Multitasking oder Parallelverarbeitung usw. Die Instruktionen können in lokalen Speichern abgelegt sein, es ist aber auch möglich, die Instruktionen auf einem entfernten System abzulegen und darauf via Netzwerk zuzugreifen.
Der Begriff "Prozessor", "zentrale Signalverarbeitung",
"Steuereinheit" oder "Datenauswertemittel " , wie hier verwen¬ det, umfasst Verarbeitungsmittel im weitesten Sinne, also beispielsweise Server, Universalprozessoren, Grafikprozesso¬ ren, digitale Signalprozessoren, anwendungsspezifische inte¬ grierte Schaltungen (ASICs) , programmierbare Logikschaltungen wie FPGAs, diskrete analoge oder digitale Schaltungen und be¬ liebige Kombinationen davon, einschließlich aller anderen dem Fachmann bekannten oder in Zukunft entwickelten Verarbeitungsmittel. Prozessoren können dabei aus einer oder mehreren Vorrichtungen bzw. Einrichtungen bzw. Einheiten bestehen. Be steht ein Prozessor aus mehreren Vorrichtungen, können diese zur parallelen oder sequentiellen Verarbeitung bzw. Ausführung von Instruktionen ausgelegt bzw. konfiguriert sein.

Claims

Patentansprüche
1. Geräteeinheit (GE) umfassend ein Modul (M) , welches die Geräteeinheit (GE) mit einem Betriebszustand von unter- schiedlichen Betriebszuständen beim Hochfahrablauf und/oder bei laufendem Betrieb der Geräteeinheit konfigurieren kann, wobei ein erster geschützter Betriebszustand der unterschied¬ lichen Betriebszustände dazu ausgelegt ist, das Ausführen von zumindest einem vorbestimmbaren Betriebsablauf zuzulassen und diesen gegebenenfalls mit festgelegten kryptographischen Mitteln zu schützen,
wobei mindestens ein zweiter Betriebszustand der unterschied¬ lichen Betriebszustände dazu ausgelegt ist, den ersten ge¬ schützten Betriebszustand zu deaktivieren und zumindest einen anderen änderbaren Betriebsablauf zuzulassen und diesen gegebenenfalls mit vorgebbaren kryptographischen Mitteln zu schützen, und
wobei, wenn der konfigurierte Betriebszustand dem ersten Be¬ triebszustand entspricht, das Modul (M) diesen beibehält oder wenn der konfigurierte Betriebszustand dem mindestens zweiten Betriebszustand entspricht, das Modul (M) den ersten Be¬ triebszustand deaktiviert und den mindestens zweiten Be¬ triebszustand einleitet und/oder beibehält.
2. Geräteeinheit (GE) nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass die Geräteeinheit als ein einge¬ bettetes System oder als Teil eines eingebetteten Systems ausgestaltet ist.
3. Geräteeinheit (GE) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass geräteseitig, wenn der Betriebszustand während des Hochfahrablaufs und/oder bei lau¬ fendem Betrieb der Geräteeinheit geschützt werden soll, für beim Hochlauf geeignete und/oder im laufenden Betrieb geeig- nete Integritätsschutzmaßnahmen bereitgestellt sind.
4. Geräteeinheit (GE) nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass die Integritätsschutzmaßnahmen des Weiteren eine Geräteauthentifizierung und/oder eine Gerä- teintegritätsattestierung umfassen .
5. Geräteeinheit (GE) nach einem der vorhergehenden An- sprüche 3 oder 4, dadurch gekennzeichnet, dass abhängig vom Betriebszustand wenigstens ein Schlüssel für die Integritäts¬ schutzmaßnahmen geräteseitig oder von einem Nutzer
bereitstellbar ist.
6. Geräteeinheit (GE) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass jeweils ein Gerätezer¬ tifikat für beide Betriebszustände zur Verfügung gestellt werden kann.
7. Geräteeinheit nach einem der vorhergehenden Ansprüche
3 bis 6, dadurch gekennzeichnet, dass die Deaktivierung des geschützten Betriebszustandes durch ein Löschen des wenigs¬ tens einen Schlüssels und/oder Widerruf des für den geschützten Betriebszustand zur Verfügung gestellten Gerätezertifi- kats durchführbar ist.
8. Geräteeinheit (GE) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Teile der Geräteeinheit aktivierbar und/oder deaktivierbar sind.
9. Geräteeinheit (GE) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Modul (M) mittels ein oder mehrerer Software- und/oder Firmwareprogrammkodes und/oder Hardwareschaltung konfigurierbar ist.
10. Geräteeinheit (GE) nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass der eine oder die Software- und/oder Firmwareprogrammkodes versiegelbar sind.
11. Geräteeinheit nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mindestens ein weiterer dritter Betriebszustand der Geräteeinheit dazu ausgelegt ist, den ersten und den zweiten Betriebszustand im Parallelbetrieb zu¬ zulassen und gegebenenfalls kryptographisch zu schützen.
12. Geräteeinheit (GE) nach einem der vorhergehenden An- sprüche, dadurch gekennzeichnet, dass der erste, zweite und gegebenenfalls der dritte Betriebszustand durch Gerätekonfi¬ guration, sogenannte Jumper, Aktivierungscodes und/oder durch den Schlüssel und/oder durch das Gerätezertifikat und/oder des Widerrufzustands des Gerätezertifikats und/oder durch ei- nen Vertrauensankers und/oder durch eine Kommunikationsproto¬ koll mit einer weiteren Stelle festlegbar ist.
13. Verfahren zum Betreiben einer Geräteeinheit (GE) in einem Betriebszustand von unterschiedlichen Betriebszuständen beim Hochfahrablauf und/oder bei laufenden Betrieb der Gerä¬ teeinheit,
wobei in einem ersten geschützten Betriebszustand das Ausführen von zumindest einem vorbestimmbaren Betriebsablaufs zuge¬ lassen und diesen gegebenenfalls mit festgelegten kryptogra- phischen Mitteln geschützt wird (S4, S5) und
wobei in einem weiteren zweiten Betriebszustand der erste ge¬ schützte Betriebszustand deaktiviert wird und zumindest ein anderer änderbarer Betriebsablauf zugelassen und dieser gegebenenfalls mit vorgebbaren kryptographischen Mitteln ge- schützt wird, wobei der Betriebszustand vor und/oder während des Hochfahrablaufs und/oder des laufenden Betriebs konfigu¬ riert wird und wenn der konfigurierte Betriebszustand dem ersten Betriebszustand entspricht (S3) , dann diesen beizube¬ halten oder wenn der konfigurierte Betriebszustand dem min- destens zweiten Betriebszustand entspricht, den ersten Be¬ triebszustand zu deaktivieren und den mindestens zweiten Be¬ triebszustand einzuleiten und/oder beizubehalten.
14. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass, wenn der Betriebszustand während des
Hochfahrablaufs und/oder bei laufendem Betrieb der Geräteeinheit geschützt werden soll, für beim Hochlauf geeignete und/oder im laufenden Betrieb geeignete Integritätsschutzma߬ nahmen bereitgestellt werden.
15. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass die Integritätsschutzmaßnahmen (S4, S5) des Weiteren eine Geräteauthentifizierung und/oder eine Gerä- teintegritätsattestierung umfassen .
16. Verfahren nach einem der vorhergehenden Ansprüche 14 oder 15, dadurch gekennzeichnet, dass abhängig vom Betriebs¬ zustand wenigstens ein Schlüssel für die Integritätsschutz¬ maßnahmen bereitgestellt wird.
17. Verfahren nach einem der vorhergehenden Verfahrensan- Sprüche, dadurch gekennzeichnet, dass jeweils ein Gerätezer¬ tifikat für beide Betriebszustände zur Verfügung gestellt wird .
18. Verfahren nach einem der vorhergehenden Ansprüche 14 bis 17, dadurch gekennzeichnet, dass die Deaktivierung des geschützten Betriebszustandes durch ein Löschen des wenigs¬ tens einen Schlüssels und/oder Widerruf des für den geschützten Betriebszustand zur Verfügung gestellten Gerätezertifi¬ kats durchgeführt wird.
19. Verfahren nach einem der vorhergehenden Verfahrensansprüche, dadurch gekennzeichnet, dass mindestens ein weiterer dritter Betriebszustand der Geräteeinheit den ersten und den zweiten Betriebszustand im Parallelbetrieb zulässt und gege- benenfalls kryptographisch schützt.
20. Verfahren nach einem der vorhergehenden Vorrichtungsansprüche, dadurch gekennzeichnet, dass der erste, zweite und gegebenenfalls der dritte Betriebszustand durch Gerätekonfi- guration, sogenannte Jumper, Aktivierungscodes und/oder durch den Schlüssel und/oder durch das Gerätezertifikat und/oder des Widerrufzustands des Gerätezertifikats und/oder durch ei- nen Vertrauensankers und/oder durch eine Kommunikationsproto¬ koll mit einer weiteren Stelle festgelegt wird.
21. Computerprogrammprodukt mit mindestens einem Computer¬ programm, das Mittel zur Durchführung des Verfahrens nach einem der vorstehenden Verfahrensansprüche aufweist, wenn das mindestens eine Computerprogramm in den Speicher einer Geräteeinheit nach einem der vorstehenden Ansprüche 1 bis 12 lad¬ bar ist und zur Ausführung gebracht wird.
EP17791592.3A 2016-12-08 2017-10-10 Geräteeinheit geeignet für den betrieb im geschützten und/oder offenen betriebszustand sowie zugehöriges verfahren Pending EP3529734A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP16202905.2A EP3333748A1 (de) 2016-12-08 2016-12-08 Geräteeinheit geeignet für den betrieb im geschützten und/oder offenen betriebszustand sowie zugehöriges verfahren
PCT/EP2017/075719 WO2018103915A1 (de) 2016-12-08 2017-10-10 Geräteeinheit geeignet für den betrieb im geschützten und/oder offenen betriebszustand sowie zugehöriges verfahren

Publications (1)

Publication Number Publication Date
EP3529734A1 true EP3529734A1 (de) 2019-08-28

Family

ID=57629234

Family Applications (2)

Application Number Title Priority Date Filing Date
EP16202905.2A Withdrawn EP3333748A1 (de) 2016-12-08 2016-12-08 Geräteeinheit geeignet für den betrieb im geschützten und/oder offenen betriebszustand sowie zugehöriges verfahren
EP17791592.3A Pending EP3529734A1 (de) 2016-12-08 2017-10-10 Geräteeinheit geeignet für den betrieb im geschützten und/oder offenen betriebszustand sowie zugehöriges verfahren

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP16202905.2A Withdrawn EP3333748A1 (de) 2016-12-08 2016-12-08 Geräteeinheit geeignet für den betrieb im geschützten und/oder offenen betriebszustand sowie zugehöriges verfahren

Country Status (4)

Country Link
US (1) US11914715B2 (de)
EP (2) EP3333748A1 (de)
CN (1) CN110023940A (de)
WO (1) WO2018103915A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022125711A1 (de) 2022-10-05 2024-04-11 Audi Aktiengesellschaft Verfahren zum Aktualisieren eines Steuergeräts eines Fahrzeugs

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7694121B2 (en) 2004-06-30 2010-04-06 Microsoft Corporation System and method for protected operating system boot using state validation
US8266692B2 (en) * 2006-07-05 2012-09-11 Bby Solutions, Inc. Malware automated removal system and method
US8555049B2 (en) * 2007-10-05 2013-10-08 Panasonic Corporation Secure boot terminal, secure boot method, secure boot program, recording medium, and integrated circuit
US8127363B2 (en) * 2007-12-26 2012-02-28 Intel Corporation Method and apparatus for booting a processing system
US8533445B2 (en) * 2009-04-21 2013-09-10 Hewlett-Packard Development Company, L.P. Disabling a feature that prevents access to persistent secondary storage
EP2449503A4 (de) * 2009-07-01 2013-12-11 Mandar Patil Verfahren zur fernsteuerung und überwachung der auf einer desktop-software erstellten daten
US20120204254A1 (en) * 2011-02-04 2012-08-09 Motorola Mobility, Inc. Method and apparatus for managing security state transitions
US8863109B2 (en) * 2011-07-28 2014-10-14 International Business Machines Corporation Updating secure pre-boot firmware in a computing system in real-time
US9015456B1 (en) * 2011-09-27 2015-04-21 Google Inc. Indicator for developer mode
US8806579B1 (en) * 2011-10-12 2014-08-12 The Boeing Company Secure partitioning of devices connected to aircraft network data processing systems
KR101930864B1 (ko) * 2012-02-16 2019-03-11 삼성전자주식회사 디바이스 인증을 이용한 디지털 콘텐츠 보호 방법 및 장치
US9218178B2 (en) * 2012-08-29 2015-12-22 Microsoft Technology Licensing, Llc Secure firmware updates
JP2014089652A (ja) * 2012-10-31 2014-05-15 Toshiba Corp 情報処理装置
US10140454B1 (en) * 2015-09-29 2018-11-27 Symantec Corporation Systems and methods for restarting computing devices into security-application-configured safe modes

Also Published As

Publication number Publication date
US11914715B2 (en) 2024-02-27
US20200089890A1 (en) 2020-03-19
EP3333748A1 (de) 2018-06-13
CN110023940A (zh) 2019-07-16
WO2018103915A1 (de) 2018-06-14

Similar Documents

Publication Publication Date Title
DE19781829C2 (de) Verfahren und Vorrichtung zum Schützen eines Flash-Speichers
DE112017004786T5 (de) Verfahren und vorrichtung zur verwendung eines sicherheits-coprozessors für firmwareschutz
EP3437012B1 (de) Verfahren, prozessor und gerät zur integritätsprüfung von nutzerdaten
EP3274825A1 (de) Verfahren und ausführungsumgebung zum gesicherten ausführen von programmbefehlen
DE102011005209B4 (de) Programmanweisungsgesteuerte Instruktionsflusskontrolle
DE10393662T5 (de) Bereitstellen eines sicheren Ausführungsmodus in einer Preboot-Umgebung
CN105122214A (zh) 对非易失性存储器中损坏的系统数据的修复
DE102014208838A1 (de) Verfahren zum Betreiben eines Steuergeräts
WO2019201598A1 (de) Verfahren und ausführungsumgebung zum ausführen von programmcode auf einem feldgerät
DE102016210788B4 (de) Komponente zur Verarbeitung eines schützenswerten Datums und Verfahren zur Umsetzung einer Sicherheitsfunktion zum Schutz eines schützenswerten Datums in einer solchen Komponente
DE112015007220T5 (de) Techniken zum Koordinieren von Vorrichtungshochfahrsicherheit
EP3529734A1 (de) Geräteeinheit geeignet für den betrieb im geschützten und/oder offenen betriebszustand sowie zugehöriges verfahren
DE102021101891A1 (de) Bestimmen , ob eine aktion zur berechnung ausgeführt werden soll gerät basierend auf der analyse von endorsement-informationen eines sicherheits-coprozessors
EP3752911B1 (de) Verfahren zum installieren eines programmcodepakets in ein gerät sowie gerät und kraftfahrzeug
EP3286872B1 (de) Bereitstellen eines gerätespezifischen kryptographischen schlüssels aus einem systemübergreifenden schlüssel für ein gerät
DE102014208848A1 (de) Verfahren zum Überwachen eines elektronischen Sicherheitsmoduls
DE102014208840A1 (de) Verfahren zum Behandeln von Software-Funktionen in einem Steuergerät
EP3072080B1 (de) Verfahren und vorrichtung zum manipulationsschutz einer recheneinrichtung
EP3690690B1 (de) Verfahren zum prüfen einer validität von daten und computerimplementierte vorrichtung zum verarbeiten von daten
DE102014208853A1 (de) Verfahren zum Betreiben eines Steuergeräts
DE102018207504A1 (de) Steuervorrichtung und Steuerverfahren
EP3786790A1 (de) Ausführungsumgebung und verfahren für einen prozess
EP4312137A1 (de) Berechtigung zu einem installieren und/oder einem starten eines zweiten anwendungsprogramms
EP4254096A1 (de) Verfahren zur implementierung einer automatisierungsfunktionalität auf einer automatisierungskomponente mit programmierbarer automatisierungsfunktionalität und system
EP4270228A1 (de) Software-implementierte sperre

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20190524

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20210430

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS