EP3369027A1

EP3369027A1 - Method and security module for providing a security function for a device

Info

Publication number: EP3369027A1
Application number: EP16805357.7A
Authority: EP
Inventors: Rainer Falk; Steffen Fries; Markus Heintel; Dominik Merli; Stefan Pyka
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2015-12-15
Filing date: 2016-11-28
Publication date: 2018-09-05
Also published as: DE102015225270A1; CN108369623A; US20180365411A1; WO2017102295A1

Abstract

The invention relates to a method (100) for providing a security function, in particular a cryptographic function, for a device (600), wherein the following method steps are carried out: receiving (110) a request to execute the security function; loading (120) a security application (214, 216, 316) for the security function via a control application (232), wherein the control application (232) is stored on a first internal memory (520) of a security module (500) and the security application (214, 216, 316) is transferred from a memory which is external to the security module; checking (130) an integrity of the security application (214, 216, 316) by means of security information; executing (140) the security application (214, 216, 316) and providing the security function, wherein the execution and provision steps are carried out after the successful integrity checking step (130).

Description

description

Method and security module for providing a

Safety function for a device

The invention relates to a method and a security module for the cryptographic protection of devices.

Devices such as embedded systems (Engl. Embedded Systems), are now in all industries to fin ^¬. The (cryptographic) protection of these devices plays an increasingly important role in order to guarantee safe operation ^¬ afford. Cryptographic functions can be used to achieve goals such as integrity, confidentiality or authenticity of these platforms. This avoids deliberate, purposeful attacks.

One way to secure an embedded system is to integrate a hardware-based trust anchor. This can fulfill various tasks, for example, can provide cryptographic keys available a safety function of a safety application at runtime, he ^¬ ask Integ ^¬ ritätsprüfwerte of application and configuration data and check sign data, provide cryptographically strong random numbers, and much more.

In many cases, trust anchors have very limited resources, such as low memory or flash memory. This means that the trust anchors, for example, can only be updated in a complicated manner to reflect changes in security standards.

The object of the present invention is to provide a method and a security module that provide the most flexible and secure security functions a device. The object is solved by the features given in the independent claims. Advantageous developments of the invention are shown in the dependent claims.

According to a first aspect, the invention relates to a method for providing a security function, in particular a cryptographic function, for a device, the following method steps being carried out:

In a method step, a request to execute the security function is received. In a further method step, a safety application for the safety function is loaded by a control application, wherein the control application is stored on a first internal memory of a security module, and the security application is transmitted from a security module external memory.

In a further method step, an integrity of the security application is checked by means of security information.

In a further method step, the security application is executed and the security function is provided, wherein the execution and deployment is carried out after the successful checking of the integrity.

For example, a security application can be understood to mean a program library that includes one or more security functions. Thus, a security application may comprise only a single security function, in which case the terms "security function" and "security application" may be considered synonymous.

A (technical) unit or a (technical) Sys tem can, for example, a measuring device for the high frequency ^¬ technique tion a reception device of a Satellitenkommunikationssta, a field device of a power plant, a Steuerungsge advises an embedded system, an IC (integrated circuit ^¬ circular, germ, integrated circuit), an FPGA (engl, Field Programmable Gate Array), an ASIC (application-specific inte ^¬ grated circuit, germ, application-specific integrated CIR cuit), a microcontroller or a DSP (Digital Signal Processor).

The method steps can be performed, for example, computer-aided by means of a processor.

For example, the request may be generated by an operating system driver or operating system that requires the security feature. For this purpose, the request comprises, for example, a data structure which comprises the security application, user data, the security information, for example in the form of integrity information, about the security application and / or further information. The security application and the integrity information are preferably stored on the security module external memory and are sent, for example, by the operating system driver by means of the request to the security module.

"Safety module external" can be understood to mean components that are not an integral part of the safety module.

Internal, often also termed "safety module in-house", can be understood to mean components or method steps which are an integral part of the security module or which are preferably executed exclusively on security-module-internal components.

The loading and executing is carried out, for example, at runtime of the operating system and / or the security module and / or the security module control application.

The term "store" can be broadly understood in the context of the patent application, which may include a variant be understood in which an additional security application is loaded. In another variant, it can be understood that a loaded security application is replaced by the newly loaded security application, that is overwritten. In a further variant, by loading an empty security application, a deletion of a loaded security application can take place. This can be done by an erase charge instruction. The security module, the safety function owing to the successful checking, for example, a autori ^¬ overbased requestor, in particular the operating system, the operating system driver, the security module itself, a different security module or a combination thereof sawn riding. The security application or the security function generates, for example, data which can be used by the requesting party and / or the security module itself, for example for a later provision of a further security function, and / or a later loaded and executed security application or security function.

A security function can be understood as meaning cryptographic functions, for example for creating a digital signature, for decrypting or encrypting a data structure, or functions for providing license information.

The disclosed method is advantageous over previous solutions in that it allows dynamic exchange of (cryptographic) security functions or security applications, such as cryptographic functions, during runtime of the device's operating system. For example, the method allows a plurality of security functions to be provided by a security module, for example a trust anchor, where previously only a single security function or security application can be integrated for reasons of space was. Thus, the security module can be inexpensively gefer ^¬ Untitled.

In a first embodiment of the method, the security application can be decrypted before checking by means of a first cryptographic key.

For this purpose, the security application is present in encrypted form on the memory external to the security module, whereby the integrity information for the security application can also be encrypted. Here symmetrical or ASYMMET ^¬ innovative methods can be used. The first cryptographic key is preferably stored on the first security-module-internal memory and protected against security module-external accesses. This improves the safety of the process. Decryption can then ^¬ example, be carried out during loading or while checking the integrity of the security application.

In further embodiments of the method, before checking the security application, header information of the security application can be checked for its integrity. The security application can only be loaded after or as a result of the successful checking of the header information.

For example, the header information may be included in the request along with the security application and the security information. The control application loads the security application only after the check has been successful and has the advantage that charging a potenti ^¬ ell manipulated security application is terminated early the advantage, and thus the safety of the process is improved.

In further embodiments of the method, the

Security application as part of a request, transfer a location of the security application as part of the request, or be loaded by the control application from the safety module external memory.

The various methods of loading the security application permit, for example, the method that can be Da ^¬ tenquelle flexibly selected.

In further embodiments of the method, the

Security application for decrypting, checking the security application or checking the header information to be loaded into a second internal memory.

As a result, the security of the method can be increased to prevent, for example, dangerous program code is not loaded directly into a memory in which executable applications and / or data are.

In further embodiments of the method, the

Security application for execution in the first internal memory or in an internal application memory of the

Security module to be loaded.

By loading the security application into a special internal memory of the security module for execution, the security of the method can be further increased.

In further embodiments of the method, the security function and / or further security functions may be provided by the security application and / or by other security applications.

For example, depending on the configuration, a security application can provide multiple security features. As a result, different application scenarios can be realized and adapted to the individual needs of the device. For example, the security application, in particular by means of the security module, can be provided exclusively. Also, a request may include several security applications that are executed in parallel or in succession, for example, by a scheduler.

In further embodiments of the method, a data exchange between security applications in the security module via a third internal memory of the Sicherheitsmo module done.

For example, the third internal memory, such as a volatile memory, may use security application outputs as input to another security application, for example, if only one security application can be in the security module at a time. Kings The expenditure of the security application nen, for example, which are generieret of the security ^¬ functional data. In this way can be vorzugswei se complex and / or nested cryptographic func ^¬ nen realized.

In further embodiments of the method, a number of security applications to be executed may be determined by the control application.

To be executed (maximum) number of security applications is preferably limited by the control application purpose, of securing ^¬ integrated module, the number to be executed can be determined, for example, during manufacture. If a new and / or additional safety application is to be loaded, the control application compares the (maximum) number to be executed with the number of security applications executed. If the new application were to exceed the number to be executed (ie, the number executed would be greater than the number to be executed), the control application may unload a security application that has already been loaded, which may also be considered an override. The fixed For example, schema may specify that a redundant security application be overridden. For example, if the memory or computational capacity of the security module is severely limited, then it may be determined that only a single security application can be loaded and executed at a time. This has the advantage that the storage space requirement can be kept low, for example, on an FPGA.

In further embodiments of the method, based on authorization information, a number of security applications to be executed can be specified, and / or the authorization information determines whether

the security application is loadable; and or

the security application is loadable from the security engine external memory or another storage location; and or

the device is in a predetermined operating mode be ^¬, so that the security application is loadable;

and or

are accessible for the security application predetermined garbage ^¬ surface of the security module or cryptographic func ^¬ NEN the control application.

The authorization information may also be referred to as license information or licensing information.

This allows the loading and running of the security application to be easily controlled via the authorization information, such as a security policy or an authorization policy. For example, may be limited for For the leading ^¬ (maximum) number of security applications. Alternatively and / or additionally, access to the predetermined memory areas, for example, pre-defined memory areas of the first internal memory, the second internal memory or the third internal memory, in accordance with the safety requirements Festge ^¬ be inserted. In further embodiments of the method, the authorization information can be received as part of the request, the authorization information is stored in the first internal memory or stored in a header information of the security application.

As a result, the authorization information is flexibly provided to the security module or the control application by the first internal memory or another internal memory of the security module, for example the second internal memory, the internal application memory and / or the third internal memory. In further embodiments of the method, an application-specific cryptographic key can be provided when loading the security application.

In one variant, the control application forms, for example, an application-specific cryptographic key or application-specific raw data, a so-called primary seed or private primary seed, for forming a cryptographic key depending on identification information of the loaded security application.

This increases the safety of the process can be further improved wei ^¬ ter, as there is preferably a security application only a cryptographic key to verify, for example, a security information in the form of a digitalized len signature.

In further embodiments of the method, when loading the security application, an application specific identifier may be provided.

For example, to create a anwendungsspe ^¬-specific cryptographic key of the application-specific identifier, the identifier also referred to as can enter the key generation to generate an application-specific cryptographic key in a reproducible way.

In further embodiments of the method, the method steps can Ver by the security module, in particular egg ^¬ nem trust anchor, are executed.

For example, by performing an exclusive all Ver method steps of the security module very high Safe ^¬ standardize the process are achieved. In this case, the components or units of the security module mentioned below can be organized centrally or also decentrally.

In further embodiments of the method, an identity information and / or context information can be transmitted when carrying the security application.

In further embodiments of the method, the

Security Application Data for a subsequently executed

Provide security application.

This allows the security functions of security applications to be concatenated, and preference can be given to implementing complex application scenarios.

In further embodiments of the method, the requirement for loading and executing the security application can be generated by the security module or the request can be generated outside the security module.

In this way, the process can be flexible for different application scenarios ^¬ Liche use.

According to a further aspect, the invention relates to a

Security module, in particular a trust anchor, to Be provide a security function, in particular a cryptographic function, for a device. The security Mo dul includes a processor and a first internal memory. The security module additionally comprises an ^interface for receiving a request to execute the security function. The safety module additionally comprises a loading unit for loading a safety application for the safety function by a control application, the control ^{application being} stored on the first internal memory of the safety module and the safety ^{application being} transmitted from a safety-module-external memory. The security module additionally comprises a Überprü ^¬ flash unit for checking an integrity of the security ^¬ application by means of a security information. The security module includes an execution unit for executing the security application and providing the security function, wherein the execution and deployment are performed only after successfully verifying integrity.

The units of the security module can be organized centrally or decentrally.

According to a further aspect, the invention relates to a device which has an inventive security module and / or an inventive application-specific security module or a plurality of inventive application-specific security modules.

An application-specific security module can be understood to mean a security module according to the invention which, for example, only executes certain security applications on the basis of authorization information. It can ^¬ example, also be only a pre-defined security application running on an application-specific security module. This enables more secure ^¬ integrated applications use parallel on a plurality of security modules, for example the device. Furthermore, a computer program ^{product is} claimed with program ^examples for carrying out said method ^according to the invention. In addition, a variant of the computer program product with program instructions for configuring a creation device, for example a 3D printer or a similar device, claimed, wherein the creation device is ^¬ with the Programmbe ^¬ missing configured such that said inventive device is created.

In addition, a provision device for storing and / or providing the computer program ^{product is claimed} . The provisioning device is, for example, a data carrier which stores and / or makes available the computer program product. Alternatively and / or additionally, the providing apparatus is, for example, a network service, a computer system, a server system, in particular a distributed computer system, a cloud-based computer system and / or virtual computer system which stores the Computerpro ^¬ program product preferably in the form of a data stream and / or provides.

This provision takes place, for example, as a download in the form of a program data block and / or command data block, preferably as a file, in particular as a download file, or as a data stream, in particular as a download data stream, of the complete computer program product. However, this provision can also take place, for example, as a partial download, which consists of several parts and in particular is downloaded via a peer-to-peer network or made available as a data stream. Such a computer program product is read using the provision device in the form of the data carrier in a system, for example, and executes the program instructions so that the method according to the invention is executed on a computer or the authoring device is configured in such a way that it creates the device ^{according to} the invention. The above-described characteristics, features, and advantages of this invention, as well as the manner in which they will be achieved, will become clearer and more clearly understood in connection with the following description of the embodiments which will be described in connection with the figures. This show in a schematic representation:

1 shows a flowchart of a first exemplary embodiment of the disclosed method;

FIG. 2 shows provision of a safety function by means of the disclosed method in a second embodiment; FIG.

3 shows a provision of a safety function by means of the disclosed method in a third embodiment; Figure 4 is an authorized loading a backup application for providing a security function according to a fourth embodiment of the method of ^¬ fenbarten. 5 shows a security module of a fifth Ausführungsbei ^¬ game; and

Fig. 6 is a device of a sixth embodiment.

In the figures, functionally identical elements are provided with the same reference numerals, unless stated otherwise.

1 is a flowchart of a first embodiment of the disclosed method 100.

The method 100 is capable of a device beispielswei ^¬ se a measuring device for the high-frequency technology, a Messge- advises a control device, a reception device of a Satellitenkom ^¬ munikationsstation or a field device of a power plant, a security function such as a cryptographic specific function of providing.

In order to provide the safety function, for example, a security module is installed in the device or the security module is a subcomponent of the device, the security module executing in particular a plurality of, preferably all, of the following method steps.

In a first method step, a request for executing the security function, for example via a communication interface, is received. In the safety function can, for example, be a cryptographic function that particular cryptographic Keyring ^¬ sel that provides digital certificates or cryptographic functions. The cryptographic functions can, for example, implement cryptographic methods such as the Advanced Encoding Standard (AES). Alternatively and / or additionally, for example, license information for activating functions of the device can be provided. The license information can, for example, enable measuring algorithms of a measuring device or frequency ranges that can be processed by measuring algorithms.

In a second method step 120, a security ^¬ application is loaded for the safety function by a control application, the control application is stored on a first internal memory of the security module and the security application is transferred from an external memory sicherheitsmodul-. The security application provides the requested security function. The control application is activated during operation of the

Security module preferably out ^¬ security modules, so preferably a security module external Ver Change, often referred to as external change, the control application is suppressed.

For example, the security application itself may be received as part of the request. Additionally and / or alternatively, the request may also specify a storage location from which the security application may be loaded.

The security application is preferably loaded into the first internal memory or into an internal application memory of the security module. In this case, an external memory can be understood as a memory device, for example a hard disk of the device, which is not arranged within the security module.

In one variant, the security application is selected by the control application. In this case, for example, one or more security applications can be permanently assigned to a specific security function. This assignment can be stored, for example, as a list, as an implementation Tabel ^¬ le (English, lookup table) or in the request.

In a third method step 130, an integrity of the security application is checked on the basis of security information, for example integrity information. This can be done, for example, by means of integrity information in the form of a digital certificate, a digital signature or a checksum that was contained in the request. An implementation using digital signatures can be achieved, for example, with the RSA (Rivest, Shamir,

Adleman), the DSA (Digital Signature Algorithm) or the ECDSA (Elliptic Curve Digital Signature Algorithm) ^{realisie ¬} ren.

In one variant, the security applications are stored in encrypted form and are decrypted before being checked by means of a first cryptographic key. Provided that the verification of the integrity was successful, in a fourth method step 140, the security application is running and the requested safety function examples play, via the communication interface bereitge ^¬ provides. In other words, the security application is executed as a result of a successful integrity check. Thus, in the event of a failure of the check, execution of the security application and the provision of the security function are prevented.

In other words, preferably before running the security application in the security module, the integrity of the security application is checked. If the Sicherheitsanwen- is dung encrypted, it is encrypted ent ^¬ before checking.

The "running" of a security application may also be referred to as security-internal activation of the code or program code of the security application.

If, for example, the security application to be loaded is ^encrypted , this can be carried out using a symmetric or an asymmetric cryptographic method. The necessary first cryptographic key to decrypt the security applications, is preferably stored in the security module, for the first field in ternal ^¬ memory. The first cryptographic key is preferably protects normal use before security module external access, so that preferably only can be done or not use by the Steue ^¬ insurance application at first cryptographic key.

This first cryptographic key can be stored, for example, during the production of the security module or by a cryptographically protected update on the security module. In other words, a method is disclosed in which an application, for example the security application, of the

Security module, such as a trust anchor must not be stored next ^¬ internally but also externally can be present, and that this can also be exchangeable for example by au ^¬ torisierte entities. An authorized entity may be understood to mean a component of the device that sends a request to the trust anchor and can provide the necessary information to verify integrity.

At the same time, the software, which is ready for the trust ^anchor, is initially limited to the control application. So on the trust anchor is preferably initially only the control application available. In other words, data stored permanently on the trust anchor is limited to the control application because the security application or other security applications can be loaded into the trust anchor and deleted from the trust anchor.

The control application is able to reload an application, such as the security application, from external memory or from the received request to the trust anchor, the control application being hard coded in the trust anchor. This means that in particular the security function or other security functions to be provided by the trust anchor are preferably provided by means of reloading and executing the security application or other security applications in the trust anchor.

In the trust anchor, preferably only one security application is executed at a time. To give security applications the ability to data, such as Generier ^¬ te cryptographic keys or checksums sure to specify later than ^¬ ter-loaded security applications on, the trust anchor may one exclusively used preferably for second internal memory, such as a volatile memory, have.

The control application preferably remains unchanged when loading and executing the security application. At the same time, the control application ensures in particular that the consistency, ie the correct execution of security functions, of the preferably complete system in the trust anchor is ensured.

In a first implementation variant, the consistency can be ensured by first loading a new security application into a third internal memory, for example an intermediate buffer, of the security anchor. Once the security application is loaded in the third internal memory, this security ^application is decrypted if necessary and checked for integrity. If integrity checking is successful, the security application is executed, which can also be said to be active. The previous security application can then be deactivated and, if necessary, overwritten.

In the first implementation variant, it is sufficient to check a digital signature or a MAC (Message Authentication Code) about the loaded security application after loading. If integrity checking fails, the intermediate buffer is freed and the loaded security application is not executed.

In a second implementation variant, a newly loaded security application and the old security application, ie a previously loaded security application that is no longer needed, share a common storage area in the trust anchor. This memory area may preferably be in the first internal memory or the internal application memory of the trust anchor. In particular, the old security application is already being loaded when the new security replaced. In this case, preferably ^¬ represents sicherge that when an error occurs during charging of the Nachla ^¬ a suitable security application is still possible.

In the second implementation variant, it may be useful first to transmit header information of the new security application and to check the integrity of this header information. Only after a review of the header information has been successful, as a result, the security application is transferred and the old security application replaced. A check of the integrity of the security application is preferably carried out after completion of the transfer. In the header information, for example, information about the to be loaded

Safety application such as version, size and / or safety functions to be performed.

In a further variant, by means of authorization information, for example a security policy in the form of an authorization policy, it can be determined which reloadable security applications may be used and / or from which (data) source these security applications may originate. In this case, the following criteria / data can be used for a security policy, for which, for example, a list, also called (application / security application) whitelist, is created.

Security applications may, for example, be approved according to their source. It is for example possible to use the "Subj ectName" and / or "Subj ectAltName" of the digital certificate with which the digital signature of the security ^¬ application has been created. Alternatively and / or additionally, the serial number and / or the issuer of the certificate with which the digital signature of the Safe ^¬ standardized application was created to be used. However, safety applications may also be permitted after their identification. For example, it is possible to use an application-specific identifier of a security application for matching with a list of permitted security applications. Alternatively and / or additionally, a fingerprint of a security application, for example in the form of a cryptographic hash value or a digital signature, can also be used. Alternatively and / or in addition to the list described, the authorization information can also be entered in the header information of the respective reloadable security application. The advantage of this approach is that the authorization information is not explicitly loaded in the form of a list and thus does not require additional storage space in the trust anchor.

In addition to the authorization information, the operating mode of the device can additionally be included in the authorization of loading a security application. An example of this is: if it is a device with a specific security authorization, no code may be reloaded / exchanged in the case of a safety-critical operation. For this purpose, additional interfaces on the trust anchor may be necessary in order to evaluate this status information.

Furthermore, the authorization information can be used to specify which cryptographic keys or which cryptographic operations of the trust anchor the security application can access. For this purpose, access to some predefined memory areas, such as key memory areas, predefined function calls or opcodes, can be blocked.

In a further variant, an application-specific cryptographic key is provided for a loaded security application. This can be formed, for example, when loading the security application, or the application-specific cryptographic key can be formed when using a cryptographic operation or when accessing a key memory. The application-specific cryptographic key can be selected randomly or it can be formed de ^¬ terministically by a key derivation. The key derivation preferably receives a security-application-dependent derivation parameter, for example an application-specific identifier, a security application checksum, eg a cryptographic hash value, or publisher information of the security application. In particular, depending on a master key of the trust anchor, an application-specific master key can be formed and provided to the security application as an application-specific master key.

Under Master Key is understood here also an information that can be used to form one or more cryptographic keys, a so-called Private Primary Seed. A Private Primary Seed can be used as an input parameter to various key generation functions to deterministically form a private or public key private key.

In a further variant, an application-specific identifier of the security application is provided analogously to the provision of the application-specific cryptographic key. This allows, for example, under ^¬ schiedliche security applications of the trust anchor un ^¬ terschiedliche application-specific identifier bereitge ^¬ provides are. This ensures that a security ^¬ application can not use the same identifier as another security application of the same trust anchor. The identifier can be provided to the security application cryptographically protected (attestation), for example, or it can be provided in a key derivation was triggered by the security application, used as a derivative parameter.

Fig. 2 shows a providing a safety function by a security module of a second embodiment 200. In particular, a variant of the method is USAGE ^¬ det, which was described in FIG. 1.

FIG. 2 shows a security module 230 comprising a control application 232. Moreover, Fig. 2 shows the security module external components such as an operating system 220, such as a Linux kernel, with drivers 222, ei ^¬ ne loading application 210 of the operating system 220, a first security application 214 and an n-th security application 216. The security module external components may be a part a device by the security module 230 is installed.

The security module 230 is, for example, a trusted anchor implemented as an FPGA module. An integrity of the security applications is protected with a cryptographic algorithm, such as the HMAC-SHA256 (Keyed-Hash Mes ^¬ sage Authentication Code, Secure Hash Algorithm 256), and as integrity information together with the

Safety applications on a safety module external

Memory stored. For example, the load application 210 of the operating system 220 selects the first security application 214 to have the trust anchor 230 perform and provide a security function of the first security application 214.

The loading application 210 for this purpose forwards the first security application 214 with the integrity information, for example a digital signature via the integrity information, to the operating system 220 in order for the operating system 220 to transmit via the

Driver 222 to the security anchor 230 can perform a data transfer 201 and a request to provide the security function of the first security application 214.

The driver 222 thus sends a request that the

Security application and the integrity information includes, to the trust anchor 230, so that the trust anchor executes the first security application 214 and provides the security ^¬ function. For this purpose, the first ^¬ Sicherheitsan application is loaded 214 by the controller application 232 in a two-th internal memory of the trust anchor, and

Control application 232 then checks the integrity of first security application 214 using the integrity information. Only when the verification of the integrity of the first security application 214 has been successful is it considered to be a security application 234 to be executed in the trust anchor 230. The control application 232 then loads, for example, from the second internal memory the first security application 214 into a first internal memory of the trust anchor or into an internal application memory of the trust anchor. The first security application 214 is then executed and the requested security function is provided to the operating system 220.

FIG. 3 shows a provision of a safety function by a security module of a third embodiment 300. In particular, a variant of the method is USAGE ^¬ det, which was used as described in FIG. 1.

FIG. 3 shows a security module 330 that includes a Steue ^¬ approximately application 232 and a third internal memory 336 of the security module 330. Moreover, Fig. 3 shows the security module external components such as an operating system 220, such as a Linux kernel, with drivers 222, ei ^¬ ne loading application 210 of the operating system 220, a first Security application 214 and second security application 316. The security module-external components may be part of a device in which the security module 330 is installed.

The security module 330 is, for example, a trusted ^anchor , which is implemented as an FPGA module. An integrity of the security applications is protected with a cryptographic algorithm, such as the HMAC-SHA256 (Keyed-Hash Message Authentication Code, Secure Hash Algorithm 256), and integrity information together with the

Safety applications are stored on a non-safety-related memory. For example, the loading application 210 of the operating system 220 selects the first security application 214 at a first time ti for the trust anchor 230 to perform and provide a first security function of the first security application 214.

For example, the load application 210 of the operating system 220 selects the second security application 316 at a second time t ₂ for the trust anchor 230 to execute and provide a second security function of the second security application 316. The load application 210 passes to the first Sicherheitsan ^¬ application 214 with the associated integrity information, such as a digital signature over the integrity information, the operating system 220 so that the operating system 230 to perform via the driver 222 to the security anchor 330, a first data transmission 301 at the first time ti and may make a first request to provide the first security function of the first security application 214. Analogously, a second data transmission 302 becomes the second

Time t ₂ for the second safety application 316 durchge ^¬ leads. The second safety function is then provided analogously to the first safety function. For this purpose, the driver 222 sends, for example, the first ^request , which comprises the first security application 214 and the associated integrity information, to the trust anchor 330 at the first time ti, so that the trust anchor 330 executes the first security application 214 and provides the first security function.

The driver 222 sends the second time point t ₂ beispiels-, a second request comprising the second Sicherheitsan ^¬ application 316 and the associated integrity information to the trust anchor 330 so that the trust anchor 330 executes the second security application 316 and provides the second security function.

First, the first security application 214 is loaded by the control application 232 into a second internal memory of the trust anchor, and the control application 232 then checks the integrity of the first security application 214 using the integrity information.

Only when the verification of the integrity of the first security application has been successful is it considered to be a security application 234 to be executed in the trust anchor 230.

The control application 232 then loads, for example, from the second internal memory the first security application 214 into a first internal memory of the trust anchor or into an internal application memory of the trust anchor. The first security application 214 is then executed and the requested security function is provided to the operating system 220, the trust anchor 330, or the control application 232. The first security application 214 or the first security function can also generate data that is stored on a third internal memory 336 of the security module, so that the second security application 316 can use the ^latter at a later time. When the second security application 316 is loaded and executed analogously to the first security application 214, the second security function can read and process the data generated by the first security function from the third internal memory 336.

In this way, any number of safety applications can be loaded one after the other, and the safety applications can exchange data safely via the third internal memory 336.

This sequencing of security applications makes it possible to implement complex functionalities that would altogether exceed the resources of the trust anchor through a sequence of security applications. For example, the calculation of a SHA256-ECDSA signature can be divided into the calculation of the hash (SHA256) and the signature (ECDSA). The first security application 214 calculates the SHA256 hash, also called the checksum. The second security application 316 calculates a digital ^signature . The required intermediate value (hash value) is exchanged via the third internal memory 336. For example, the trust anchor can also implement a stack machine that reloads individual commands.

In one variant, the first request already contains all the security applications to be executed, their integrity information and information about the requested security functions.

In a further variant, the first security application provides data for a subsequently executed security application. Specifically, a car ^¬ ization can thus for example be implemented by the first security application 214 to the second security application 316th Here, the first security application, in addition to the (optional) len) intermediate values an authentication token, for example in the third internal memory 336 of the security module 330. The authentication token is evaluated before the calculation is continued. Two implementation variants are conceivable:

In the first implementation variant puts the first

Security application or the first security feature limits that only certain security applications can be reloaded and / or run later. The restriction is enforced by the trust anchor application 232.

In the second implementation variant, acceptance of intermediate results of previously executed security applications, for example the first security application 214, by the second security application 316 is limited to predetermined intermediate results. The throttling is enforced by the second security application 316 in the second implementation.

In a further variant, the previous embodiments can be extended to the effect that, in addition to verifying the integrity, the authorization for reloading certain security applications is also checked. The associated authorization information can be created by the device operator and can be provided, for example, in the form of signed information. For this purpose, the control application has an extension that allows the determination of owner information or operator information. This can be realized during production or during commissioning. A possible procedure for loading in the variant with external authorization information, for example an authorization policy, is shown in FIG. 4 from the perspective of the security module. In detail, FIG. 4 shows a flowchart with a start element 405 and an end element 460.

In a first method step 410, for example, an attempt is made to read the owner ^information or the operator ^information . In a second method step 415, it is checked whether the owner information or the operator information was readable. If the checking fails, ie the owner ^information or the operator information is not present, for example, in a method step 420, a (data) source of the security application to be reloaded or a type, for example a certain type of security application such as encryption applications, the security application to be reloaded without restriction Loading and running accepted.

If the checking is successful, ie the owner information or the operator information is present, the authorization information is loaded in a method step 425, for example, and the authenticity of the authorization information is verified. In a process step 430 is then decided which further process steps to be executed based on the result of the Veri ^¬ fizierens.

If the verification fails, for example, an error message is output in a method step 435 and the security application is not loaded and / or executed.

If the verification is successful, for example, in a method step 440, the security application is loaded and its integrity is checked. Alternatively and / or additionally ^¬ to the authorization information is loaded and the security application and / or their safety function checks whether they are executable. In a method step 445, an execution of the security application is then decided on the basis of a result of checking the integrity and / or authorization information.

If the check is successful, for example, in a method step 455, the security application is executed and the security function of the security application is provided to the person who requested it.

If the check failed, an error message is output, for example, in a method step 450 and an execution of the security application is prevented.

5 shows a security ^module 500 of a fifth ^exemplary embodiment.

The security module 500, which is implemented, for example, as a trust anchor, provides a security function, for example a cryptographic function, for a device. The security module 500 includes a processor 510, a first internal memory 520, a loading unit 530, a checking unit 540, an executing unit 550, and an interface 585 communicatively communicating with each other via a first bus 580.

Specifically, interface 585 receives a request to perform a security function. The loading unit 530 loads a security application for the security function by means of a control application, wherein the control application is stored on a first internal memory 520 of the security module 500 and the security application is transmitted from a security module external memory.

The security application is then executed, for example, by the processor 510 on a security module basis, so that the In the FIGS. 1-4 disclosed method can be computer-aided out ^¬ leads.

The checking unit 540 checks integrity of the security application based on security information. The execution unit 550 executes the security application and provides the security function via the

Interface 585 ready, wherein the execution and ^{Stel ¬} len is carried out only after the successful checking of the integrity.

The security module may for example be integrated in a device 600 as shown in FIG. The device 600 may, for example, an embedded system, rather pacemakers, a field device of a power plant or a Steuerge ^¬ advises be a fire extinguishing system.

Specifically, the device 600 includes a security module 500 as described in FIG. 5. In addition, the device includes an operating system component 620 and a

Driver component 630 communicatively communicating with the security module via a second bus 610.

Requires the operating system component 620, a safety function, it sends using the driver component 630, a request to execute the safety function on the second bus 610 to the security module 500. The secure ^¬ integrated module provides as described play in the previous Ausführungsbei ^¬ then, the safety function provided that at least the integrity of a security application providing the security function has been successfully verified.

Although the invention in detail by the embodiments has been illustrated and described more detail, the invention is not limited by the disclosed examples, and can be derived therefrom by the skilled artisan without departing from the scope of the invention to particular ^¬ variations.

Claims

claims

A method (100) for providing a security function, in particular a cryptographic function, for a device (600), wherein the following method steps are carried out:

Receiving (110) a request to perform the security function;

Loading (120) a security application (214, 216, 316) for the security function by a control application (232), wherein

the control application (232) is stored on a first internal memory (520) of a security module (500);

- the security application (214, 216, 316) is transmitted from a security module external memory; Checking (130) an integrity of the security application (214, 216, 316) by means of a Sicherheitsinformati ^¬ one; and

- executing (140) the security application (214, 216, 316) and providing the security function, wherein the executing and deploying is performed after successfully checking (130) the integrity.

2. The method (100) according to the preceding claim, wherein the security application (214, 216, 316) is encrypted ent ^¬ means of a first cryptographic key before checking (130).

3. The method (100) according to any one of the preceding claims, wherein

before checking (130) the security information, a header information of the security application (214, 216, 316) is checked for integrity; and

- the security application (214, 216, 316) is loaded only after successful checking of the header information.

The method (100) of any preceding claim, wherein the security application (214, 216, 316) is transmitted as part of the request, a storage location of the security application (214, 216, 316) is transmitted as part of the request or Security application (214, 216, 316) is loaded by the control application (232) from the safety module external memory.

5. The method (100) according to any one of the preceding claims, wherein the security application (214, 216, 316) for Entschlüs ^¬ clauses, to check (130) of the security application (214, 216, 316) or to check the header information in a second internal Memory is loaded.

The method (100) of any of the preceding claims, wherein the security application (214, 216, 316) is loaded for execution (140) in the first internal memory (520) or in an internal application memory of the security module (500).

7. Method (100) according to one of the preceding claims, wherein the safety function and / or further safety functions are provided by the safety ^application (214, 316) and / or by further safety applications (216, 316).

8. The method (100) according to any one of the preceding claims, wherein a data exchange between security applications (214, 216, 316) in the security module (500) via a third internal memory of the security module (500) he follows ^¬ .

The method (100) of any of the preceding claims, wherein a number of security applications (214, 216, 316) to be executed is determined by the control application (232).

10. The method (100) according to any one of the preceding claims, wherein based on an authorization information to be executed number of security applications (214, 216, 316) is determined, and / or is determined based on the authorization information, whether

the security application (214, 216, 316) is loadable; and or

the security application (214, 216, 316) can be loaded from the security module external memory or another storage location; and or

the device (600) is in a predetermined operating mode for the safety application (214, 216, 316) to be loadable; and or

for the security application (214, 216, 316) predetermined memory areas of the security module (500) or cryptographic functions of the control application (232) are accessible.

11. The method (100) of claim 10, wherein the authorization information is received as part of the request, the

Authorization information in the first internal memory (520) is stored or in a header information of

Security application (214, 216, 316) is stored.

The method (100) of any of the preceding claims, wherein an application-specific cryptographic key is provided when loading the security application (214, 216, 316).

The method (100) of any one of the preceding claims, wherein upon loading the security application (214, 216, 316) an application specific identifier is provided.

14. The method (100) according to one of the preceding claims, wherein the method steps by the security module

(500), especially a trust anchor (300, 400) out ^¬ leads are.

15. The method (100) according to one of the preceding claims, wherein identity information and / or context information are transmitted when the security application (214, 216, 316) is transmitted.

The method (100) of any one of the preceding claims, wherein the security application (214) provides data for a subsequently executed security application (316).

17. The method (100) according to claim 1, wherein the request for loading and executing the security application (214, 216, 316) is generated by the security module (500) or the request is generated outside the security module.

18. Security module (500), in particular a trust anchor (300, 400), for providing a security function, in particular a cryptographic function, for a device (600), comprising:

a processor (510);

a first internal memory (520);

an interface (585) for receiving a request to perform the security function;

a charging unit (530) for loading a security application (214, 216, 316) for the security function by a control application (232), wherein

is the control application (232) on said first internal memory (520) of the security module (500) stores ^¬ ge;

- the security application (214, 216, 316) is transmitted from a security module external memory; a checking unit (540) for checking a ^¬ In tegrity of the security application (214, 216, 316) by means of a security information; and

- an execution unit (550) for executing the secure ^¬ integrated application (214, 216, 316) and providing the safety function, and wherein performing Bereitstel- Only after successfully verifying the integrity is performed.

19. Device (600) which has a security module (500) according to claim 18 and / or an application-specific security ^module (500) or a plurality of application-specific security ^modules (500) according to claim 18.

20. Computer program product with program instructions for carrying out the method according to one of claims 1-17.

21, to create a computer program product having program instructions for creating a device that is confi ^¬ riert by means of the program instructions, the security module (500) according to claim 18 or device according to claim 19th

22. The computer program product deployment device of claim 20, wherein the deployment device stores and / or provides the computer program product.