METHOD FOR CONFIGURING A SECURITY MODULE WITH AT LEAST ONE DERIVED KEY

Abstract

Provided a method for configuring a security module with at least one derived key, having the following steps: providing a key; deriving a further key from the provided key or from a key previously derived from the provided key, wherein the further key is derived by using an alterable digital fingerprint as key derivation parameter, which is formed on the basis of a measurable current runtime configuration of a runtime environment communicating with the security module.

Claims

1. A method for configuring a security module (SD) with at least one derived key, comprising the following steps: providing a key (MK); deriving (KDF) a further key (K1 to KN) from the provided key or from a key derived beforehand from the provided key, characterized in that a changeable digital fingerprint (FP) is incorporated into the derivation as key derivation parameter, this fingerprint being formed on the basis of a measurable current runtime configuration of a runtime environment (R) communicating with the security module.

2. The method as claimed in the preceding claim, characterized in that the step of deriving a further key is repeated once or multiple times.

3. The method as claimed in either of the preceding claims, characterized in that at least one cryptographic operation is performed using the derived further key.

4. The method as claimed in one of the preceding claims, characterized in that the measurable runtime configuration comprises at least one ascertainable state (1 to N) of the runtime environment (R) or at least one state of the runtime environment that is triggered by the occurrence of a monitorable event.

5. A security module (SD), able to be configured with at least one derived key, having: a reception unit for a provided key (MK); a derivation unit (KDF) for deriving a further key (K1 to KN) from the provided key or from a key derived beforehand from the provided key, characterized by a generation unit that is designed to form a changeable fingerprint (FP) using a measurable current runtime configuration of a runtime environment (R) communicating with the security module, which fingerprint is incorporated into the derivation as key derivation parameter.

6. A device (D) having a runtime environment (R), having a security module (SD) as claimed in the preceding claim, characterized by a provision unit for providing a key (MK) and a measurement unit (M) for measuring a current runtime configuration, which is used to form a changeable fingerprint (FP) that is incorporated, as key derivation parameter, into a derivation of a further key (K1 to KN) from the provided key or from a key derived beforehand from the provided key.

7. A computer program product comprising computer-executable instructions that, when loaded into a device, are designed to perform a method as claimed in one of the preceding method claims.

Description

DETAILED DESCRIPTION

[0034] The figure shows a device D. The relationship between runtime properties of a runtime environment R, the division into N different system states S1 to SN and the derivation of corresponding keys with the aid of a master key MK are illustrated. The underlying functionality is implemented by the runtime measurement key derivation function RM-KDF, which is integrated in a security module SD that is integrated into the device D or coupled to the device D. It may also be implemented in a distributed manner, that is to say a first part of the runtime measurement key derivation function RM-KDF may be integrated on the security module, and a second part of the runtime measurement key derivation function RM-KDF may be coupled to the security module.

[0035] The system or runtime states 1 to N differ in terms of the runtime properties of one or more components, for example the processes P running at the time of key derivation, file system properties FS and hardware states HW, such as for example the value of a hardware counter. If a key is intended to be derived, the RM-KDF measured values (for example one-way or hash values of files) are taken from the runtime environment R. The parts of the runtime environment that are intended to be measured are predefined in this case by a measurement rule system MP (measurement policy). All of the measured values M, which may be maintained for example with a running hash value, then serve, together with a master key MK, as input parameters for a key derivation function KDF, for example based on HMAC-SHA256. If the state of a measured runtime component, due to an attack, no longer corresponds to that expected, for example due to an attacker starting a process for which no provision is made in the state, the derived key is also changed. Objects protected by the key are thus accessible only in states of the runtime environment that are defined as valid.

[0036] The states 1 to N are defined implicitly by the measurement policy (measurement rule) 1VIP and the states of the measured runtime components. The measurement policy MP may be different for each state, or identical for multiple states. Multiple RM-KDFs may accordingly be implemented on a device D, these using different measurement policies, derivation functions KDFs and/or master keys MK.

[0037] The measurement policy MP, the measurement functions for all of the measured values M and the key derivation functions KDF may be implemented in principle either in software or in hardware components. The master key MK used for the derivation may in this case either be stored in hardware (for example hardware-based trust anchor) or implemented in software (for example as part of an obfuscated routine).

[0038] Multiple options for measurable runtime properties are set forth below. They may be combined as desired to form a measurement policy MP. [0039] Previous runtime of the device D since a reset, for example by way of a hardware counter or a real-time clock. The previous runtime of the software, for example of a Linux kernel (/proc/uptime), may also be used here. [0040] Performance runtime data (for example CPU load, memory utilization, utilization of input/output interfaces, for example network interfaces, DMA transfers, interrupt frequency). [0041] Power consumption profile, electromagnetic radiation profile (for example temporal profile, frequency spectrum) [0042] Meta information about running processes P, for example the user under which a process is running, what process started it (process tree/parent-child relationship of processes/“process chain”), process priority, process number, SELinux domain of a process, namespaces and cgroups in which a process is running. [0043] Currently appended file systems and their properties (for example read-only). Keys may thus also be derived on the basis of the existing, interchangeable peripheral modules—such as for example USB dongles. [0044] Dedicated files that reflect the integrity of the current system. By way of example, security-critical events may be written to specific files, which are jointly measured in the course of the key derivation, by a host-based intrusion detection system (HIDS). A further option is to jointly incorporate configuration data that restrict logging onto the system (or even prevent it entirely) into the measurement: in the event of an attack in which the configuration is changed such that logging on is possible again (in particular in order to be able to observe the system “internally” at runtime), only incorrect keys are then derived. [0045] The state of particular security mechanisms may be jointly incorporated. For instance, on a Linux-based system, it is possible to derive the correct keys for an application only when one or more security mechanisms are in a particular state (for example SELinux in “enforcing” mode). [0046] It is possible to jointly measure static data, such as for example a hardware ID, or configuration files in the file system. If the runtime measurement key derivation function RM-KDF is executed in another environment (different hardware and thus hardware ID, different configuration), or if the files that are assumed to be static are manipulated, different keys are thus derived. [0047] It is possible to check for the presence of particular file contents that are supposed to be present for example from a provisioning phase of the device. [0048] Meta information of the file system, such as for example the size of particular parts, access or change times, permissions, users/owners, targets of symbolic links, etc. [0049] It is possible to jointly incorporate how the runtime measurement key derivation function RM-KDF is used or called. This may thus for example jointly incorporate the process chain, starting from the called component, to the root of the process tree. In this case, the names of the processes contained in the process chain may for example be hashed continuously and used as part of the key derivation parameter. It is thus possible to ensure that the correct keys are able to be derived only in the course of an intended call. [0050] It is possible to jointly incorporate a watchdog (hardware or software function) that monitors the integrity of the runtime environment.

[0051] It is possible to measure the execution time of a specifically provided benchmark function and to jointly incorporate this into the derivation—with a certain amount of play for normal measurement variances. If the execution of such a function requires for example 250 ms with a standard deviation (Sigma) of 10 ms, an (integer) division by 100 ms on a non-manipulated device with 5-Sigma reliability gives the value 2. By contrast, this makes it more difficult for an attacker to reproduce the derived keys in a simulated or emulated environment, because the performance of the device then additionally also has to be replicated in a sufficiently accurate manner (in the example: +/−20%).

[0052] The applications, with an application being indicated by way of example by AP in the figure, are able to derive keys at runtime using the library in order to perform a cryptographic operation using the derived key. Such operations are able to protect and access security-critical objects, for example encrypted file systems, or private keys for a TLS connection. If a key is intended to be derived, the runtime measurement key derivation function RM-KDF uses the measurement function and the measurement policy MP in order to measure or to ascertain parts of the runtime environment that are defined therein or defined events at one or more particular times and to define them as a runtime configuration. The measurement function, using dedicated kernel interfaces, aggregates information about currently appended file systems (mounts), the state of certain peripheral modules (for example FPGA, GPIO, MAC address), the previous runtime of the operating system (uptime), static contents from the file system and the names of the processes in the process chain of the caller in a running hash value. The aggregated value is then used as key derivation parameter for a key derivation function with the master key MK. The derived key K1 to KN is different depending on the application called, since these belong to different process chains.

[0053] A variable fingerprint FP formed from the runtime configuration and the consideration thereof as key derivation parameter may be considered as a configuration of the security module. The applications may use these derived keys for example to access private file systems. If an attacker, by way of a further process, likewise attempts to derive a key using the runtime measurement key derivation function RM-KDF, then this will be different. Both offline and online attacks generally change dynamic properties of a runtime environment (for example configuration files, options of appended file systems). Access to keys from valid states is thus made much more difficult.

[0054] Embodiments of the invention have the advantage that access to keys may be linked to the current state of static and in particular dynamic properties of the runtime environment. In the event of an intervention in the runtime environment (physical attack, remote attack), the key derivation is able to be influenced and it is thus no longer possible to derive valid keys in a non-trusted environment. The state dependency may furthermore be intentionally used to provide different keys at different runtime phases in software. This specifically has the advantage that, in the case of a compromised runtime phase, it is not possible to derive the keys of the current or the other phases.

[0055] The processes or method sequences described above may be implemented on the basis of instructions that are present on computer-readable storage media or in volatile computer memories (referred to below collectively as computer-readable memories). Computer-readable memories are for example volatile memories such as caches, buffers or RAM, and non-volatile memories such as interchangeable data carriers, hard drives, etc.

[0056] The functions or steps described above may in this case be present in the form of at least one set of instructions in/on a computer-readable memory. The functions or steps are in this case not linked to a particular set of instructions or to a particular form of sets of instructions or to a particular storage medium or to a particular processor or to particular execution schemes, and may be executed by software, firmware, microcode, hardware, processors, integrated circuits etc. on their own or in any desired combination. In this case, a very wide variety of processing strategies may be used, for example serial processing using a single processor or multiprocessing or multitasking or parallel processing, etc.

[0057] The instructions may be stored in local memories, but it is also possible to store the instructions on a remote system and to access them via a network.

[0058] The device D may have one or more processors. The term “processor”, “central signal processor”, “control unit” or “data evaluation means” or “a data evaluator” comprises processing means or processor in the broadest sense, that is to say for example servers, universal processors, graphics processors, digital signal processors, application-specific integrated circuits (ASICs), programmable logic circuits such as FPGAs, discrete analog or digital circuits and any desired combinations thereof, including all other processing means or processors known to a person skilled in the art or developed in the future. Processors may in this case consist of one or more apparatuses or appliances or units. If a processor consists of multiple apparatuses, these may be designed or configured for the parallel or sequential processing or execution of instructions.

[0059] Although the present invention has been disclosed in the form of preferred embodiments and variations thereon, it will be understood that numerous additional modifications and variations could be made thereto without departing from the scope of the invention.

[0060] For the sake of clarity, it is to be understood that the use of “a” or “an” throughout this application does not exclude a plurality, and “comprising” does not exclude other steps or elements.