Nothing Special   »   [go: up one dir, main page]

EP3369027A1 - Verfahren und sicherheitsmodul zum bereitstellen einer sicherheitsfunktion für ein gerät - Google Patents

Verfahren und sicherheitsmodul zum bereitstellen einer sicherheitsfunktion für ein gerät

Info

Publication number
EP3369027A1
EP3369027A1 EP16805357.7A EP16805357A EP3369027A1 EP 3369027 A1 EP3369027 A1 EP 3369027A1 EP 16805357 A EP16805357 A EP 16805357A EP 3369027 A1 EP3369027 A1 EP 3369027A1
Authority
EP
European Patent Office
Prior art keywords
security
application
module
function
security application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP16805357.7A
Other languages
English (en)
French (fr)
Inventor
Rainer Falk
Steffen Fries
Markus Heintel
Dominik Merli
Stefan Pyka
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 EP3369027A1 publication Critical patent/EP3369027A1/de
Withdrawn 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/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures

Definitions

  • the invention relates to a method and a security module for the cryptographic protection of devices.
  • 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 ⁇ rticiansprüfock of application and configuration data and check sign data, provide cryptographically strong random numbers, and much more.
  • 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.
  • 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:
  • a request to execute the security function is received.
  • 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.
  • an integrity of the security application is checked by means of security information.
  • 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.
  • a security application can be understood to mean a program library that includes one or more security functions.
  • 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).
  • IC integrated circuit ⁇ circular, germ, integrated circuit
  • FPGA engl, Field Programmable Gate Array
  • ASIC application-specific inte ⁇ grated circuit, germ, application-specific integrated CIR cuit
  • microcontroller or a DSP Digital Signal Processor
  • the method steps can be performed, for example, computer-aided by means of a processor.
  • the request may be generated by an operating system driver or operating system that requires the security feature.
  • 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.
  • 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.
  • 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.
  • 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.
  • the security module can be inexpensively gefer ⁇ Untitled.
  • the security application can be decrypted before checking by means of a first cryptographic key.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 ⁇ tenán flexibly selected.
  • Security application for decrypting, checking the security application or checking the header information to be loaded into a second internal memory.
  • 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.
  • Security application for execution in the first internal memory or in an internal application memory of the
  • the security of the method can be further increased.
  • the security function and / or further security functions may be provided by the security application and / or by other security applications.
  • 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.
  • the security application in particular by means of the security module, can be provided exclusively.
  • a request may include several security applications that are executed in parallel or in succession, for example, by a scheduler.
  • a data exchange between security applications in the security module via a third internal memory of theprofilemo module done.
  • the third internal memory such as a volatile memory
  • 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.
  • a number of security applications to be executed may be determined by the control application.
  • 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.
  • 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.
  • 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;
  • the authorization information may also be referred to as license information or licensing information.
  • the authorization information such as a security policy or an authorization policy.
  • a security policy or an authorization policy may be limited for For the leading ⁇ (maximum) number of security applications.
  • 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.
  • 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.
  • 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.
  • an application-specific cryptographic key can be provided when loading the security application.
  • 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.
  • an application specific identifier when loading the security application, an application specific identifier may be provided.
  • the identifier also referred to as can enter the key generation to generate an application-specific cryptographic key in a reproducible way.
  • the method steps can Ver by the security module, in particular egg ⁇ nem trust anchor, are executed.
  • the components or units of the security module mentioned below can be organized centrally or also decentrally.
  • an identity information and / or context information can be transmitted when carrying the security application.
  • 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.
  • the invention relates to a
  • 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 Studentsprü ⁇ 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.
  • 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.
  • a computer program product is claimed with program examples for carrying out said method according to the invention.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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 fifthheldsbei ⁇ game
  • Fig. 6 is a device of a sixth embodiment.
  • FIG. 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.
  • 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.
  • a request for executing the security function is received.
  • 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).
  • AES Advanced Encoding Standard
  • 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.
  • 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 Obviouslysmodul-.
  • 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.
  • the security application itself may be received as part of the request.
  • 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.
  • 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.
  • the security application is selected by the control application.
  • 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.
  • an integrity of the security application is checked on the basis of security information, for example integrity information.
  • 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,
  • the security applications are stored in encrypted form and are decrypted before being checked by means of a first cryptographic key.
  • the security application is running and the requested safety function examples play, via the communication interface sais ⁇ provides.
  • the security application is executed as a result of a successful integrity check.
  • the integrity of the security application is checked. If thestructureanwen- 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.
  • 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.
  • 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 ⁇ torinstrumente 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.
  • 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.
  • an application such as the security application
  • 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.
  • the trust anchor preferably only one security application is executed at a time.
  • 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.
  • 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.
  • a third internal memory for example an intermediate buffer
  • 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.
  • the old security application is already being loaded when the new security replaced.
  • ⁇ represents admirably to provide a suitable security application.
  • header information of the new security application 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.
  • header information for example, information about the to be loaded
  • Safety application such as version, size and / or safety functions to be performed.
  • authorization information for example a security policy in the form of an authorization policy
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a security-specific master key can be formed and provided to the security application as an application-specific master key.
  • 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.
  • 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 ⁇ Kunststoffliche security applications of the trust anchor un ⁇ ter Kunststoffliche application-specific identifieretcge ⁇ 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.
  • 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.
  • 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 HMAC-SHA256 (Keyed-Hash Mes ⁇ sage Authentication Code, Secure Hash Algorithm 256), and as integrity information together with the HMAC-SHA256 (Keyed-Hash Mes ⁇ sage Authentication Code, Secure Hash Algorithm 256), and as integrity information together with the HMAC-SHA256 (Keyed-Hash Mes ⁇ sage Authentication Code, Secure Hash Algorithm 256), and as integrity information together with the HMAC-SHA256 (Keyed-Hash Mes ⁇ sage Authentication Code, Secure Hash Algorithm 256), and as integrity information together with the HMAC-SHA256 (Keyed-Hash Mes
  • 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 integrity information
  • 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.
  • the first ⁇ profilean 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.
  • 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.
  • 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 HMAC-SHA256 (Keyed-Hash Message Authentication Code, Secure Hash Algorithm 256), and integrity information together with the HMAC-SHA256 (Keyed-Hash Message Authentication Code, Secure Hash Algorithm 256), and integrity information together with the HMAC-SHA256 (Keyed-Hash Message Authentication Code, Secure Hash Algorithm 256), and integrity information together with the HMAC-SHA256 (Keyed-Hash Message Authentication Code, Secure Hash Algorithm 256), and integrity information together with the HMAC-SHA256 (Keyed-Hash Message Authentication Code, Secure Hash Algorithm 256), and integrity information together with
  • Safety applications are stored on a non-safety-related memory.
  • 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.
  • the load application 210 of the operating system 220 selects the second security application 316 at a second time t 2 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 firstforcean ⁇ 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.
  • a second data transmission 302 becomes the second
  • Time t 2 for the second safety application 316 leads.
  • the second safety function is then provided analogously to the first safety function.
  • 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 2 beispiels-, a second request comprising the secondforcean ⁇ 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.
  • 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.
  • 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.
  • the second security function can read and process the data generated by the first security function from the third internal memory 336.
  • 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.
  • 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.
  • the trust anchor can also implement a stack machine that reloads individual commands.
  • the first request already contains all the security applications to be executed, their integrity information and information about the requested security functions.
  • the first security application provides data for a subsequently executed security application.
  • a car ⁇ ization can thus for example be implemented by the first security application 214 to the second security application 316th
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 4 shows a flowchart with a start element 405 and an end element 460.
  • a first method step 410 for example, an attempt is made to read the owner information or the operator information .
  • 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.
  • the authorization information is loaded in a method step 425, for example, and the authenticity of the authorization information is verified.
  • a process step 430 is then decided which further process steps to be executed based on the result of the Veri ⁇ fiths.
  • 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.
  • the security application is executed and the security function of the security application is provided to the person who requested it.
  • an error message is output, for example, in a method step 450 and an execution of the security application is prevented.
  • FIG. 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.
  • 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.
  • the device 600 includes a security module 500 as described in FIG. 5.
  • the device includes an operating system component 620 and a
  • Driver component 630 communicatively communicating with the security module via a second bus 610.
  • the secure ⁇ integrated module provides as described play in the previous Tinsbei ⁇ then, the safety function provided that at least the integrity of a security application providing the security function has been successfully verified.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mathematical Physics (AREA)
  • Storage Device Security (AREA)

Abstract

Verfahren und Sicherheitsmodul zum Bereitstellen einer Sicherheitsfunktion für ein Gerät Die Erfindung betrifft ein Verfahren (100) zum Bereitstellen einer Sicherheitsfunktion, insbesondere einer kryptographischen Funktion, für ein Gerät (600), wobei folgende Verfahrensschritten ausgeführt werden. Ein Verfahrensschritt zum Empfangen (110) einer Anforderung zum Ausführen der Sicherheitsfunktion. Einen weiteren Verfahrensschritt zum Laden (120) einer Sicherheitsanwendung (214, 216, 316) für die Sicherheitsfunktion durch eine Steuerungsanwendung (232), wobei die Steuerungsanwendung (232) auf einem ersten internen Speicher (520) eines Sicherheitsmoduls (500) gespeichert ist und die Sicherheitsanwendung (214, 216, 316) von einem sicherheitsmodulexternen Speicher übertragen wird. Einen weiteren Verfahrensschritt zum Überprüfen (130) einer Integrität der Sicherheitsanwendung (214, 216, 316) mittels einer Sicherheitsinformation. Einen weiteren Verfahrensschritt zum Ausführen (140) der Sicherheitsanwendung (214, 216, 316) und Bereitstellen der Sicherheitsfunktion, wobei das Ausführen und Bereitstellen nach dem erfolgreichen Überprüfen (130) der Integrität durchgeführt wird.

Description

Beschreibung
Verfahren und Sicherheitsmodul zum Bereitstellen einer
Sicherheitsfunktion für ein Gerät
Die Erfindung bezieht sich auf ein Verfahren und ein Sicherheitsmodul zum kryptographischen Schutz von Geräten.
Geräte, beispielsweise eingebettete Systeme (engl. Embedded Systems) , sind heutzutage in allen Industriezweigen zu fin¬ den. Der (kryptographische) Schutz dieser Geräte spielt eine zunehmend wichtigere Rolle, um einen sicheren Betrieb gewähr¬ leisten zu können. Durch kryptographische Funktionen können Ziele wie Integrität, Vertraulichkeit oder Authentizität die- ser Plattformen erreicht werden. Dadurch werden absichtliche, zielgerichtete Angriffe abgewehrt.
Eine Möglichkeit, ein eingebettetes System abzusichern, ist die Integration eines hardwarebasierten Vertrauensankers. Dieser kann diverse Aufgaben erfüllen, beispielsweise kann eine Sicherheitsfunktion einer Sicherheitsanwendung zur Laufzeit kryptographische Schlüssel zur Verfügung stellen, Integ¬ ritätsprüfwerte von Anwendungs- und Konfigurationsdaten er¬ stellen und prüfen, Daten signieren, kryptographisch starke Zufallszahlen bereitstellen, und vieles mehr.
In vielen Fällen haben Vertrauensanker nur sehr beschränkte Ressourcen zur Verfügung, beispielsweise wenig Arbeitsspeicher oder Flash Speicher. Dies bedeutet, dass die Vertrauens- anker beispielsweise auf Veränderungen von Sicherheitsstandards nur kompliziert aktualisiert werden können.
Die Aufgabe der vorliegenden Erfindung ist es, ein Verfahren und ein Sicherheitsmodul bereitzustellen, die möglichst fle- xibel und sicher Sicherheitsfunktionen einem Gerät bereitstellen . Die Aufgabe wird durch die in den unabhängigen Ansprüchen an gegebenen Merkmale gelöst. In den abhängigen Ansprüchen sind vorteilhafte Weiterbildungen .er Erfindung dargestellt.
Gemäß einem ersten Aspekt betrifft die Erfindung ein Verfahren zum Bereitstellen einer Sicherheitsfunktion, insbesonder einer kryptographischen Funktion, für ein Gerät, wobei folgende Verfahrensschritten ausgeführt werden:
In einem Verfahrensschritt wird eine Anforderung zum Ausführen der Sicherheitsfunktion empfangen. In einem weiteren Ver fahrensschritt wird eine Sicherheitsanwendung für die Sicher heitsfunktion durch eine Steuerungsanwendung geladen, wobei die Steuerungsanwendung auf einem ersten internen Speicher eines Sicherheitsmoduls gespeichert ist, und die Sicherheits anwendung von einem sicherheitsmodulexternen Speicher übertragen wird.
In einem weiteren Verfahrensschritt wird eine Integrität der Sicherheitsanwendung mittels einer Sicherheitsinformation überprüft .
In einem weiteren Verfahrensschritt wird die Sicherheitsanwendung ausgeführt und die Sicherheitsfunktion bereitgestellt, wobei das Ausführen und Bereitstellen nach dem erfolgreichen Überprüfen der Integrität durchgeführt wird.
Unter einer Sicherheitsanwendung kann beispielsweise eine Programmbibliothek verstanden werden die eine oder mehrere Sicherheitsfunktionen umfasst. Somit kann eine Sicherheitsan wendung nur eine einzige Sicherheitsfunktion umfassen, wobei in einem solchen Fall die Ausdrücke „Sicherheitsfunktion" un „Sicherheitsanwendung" als synonym angesehen werden können.
Unter einem (technischen) Gerät oder einem (technischen) Sys tem kann beispielsweise ein Messgerät für die Hochfrequenz¬ technik, ein Empfangsgerät einer Satellitenkommunikationssta tion, ein Feldgerät einer Kraftwerksanlage, ein Steuerungsge rät, ein eingebettetes System, ein IC (integrierter Schalt¬ kreis, engl, integrated circuit) , ein FPGA (engl, field pro- grammable gate array) , ein ASIC (anwendungsspezifische inte¬ grierte Schaltung, engl, application-specific integrated cir- cuit) , ein MikroController oder ein DSP (digitaler Signalprozessor, engl. Digital Signal Processor) verstanden werden.
Die Verfahrensschritte können beispielsweise rechnergestützt mittels eines Prozessors ausgeführt werden.
Die Anforderung kann beispielsweise von einem Betriebssystemtreiber oder einem Betriebssystem erzeugt werden, welches die Sicherheitsfunktion benötigt. Die Anforderung umfasst dazu beispielsweise eine Datenstruktur, die die Sicherheitsanwen- dung, Nutzerdaten, die Sicherheitsinformation, beispielsweise in Form einer Integritätsinformation, über die Sicherheitsanwendung und/oder weitere Informationen umfasst. Die Sicherheitsanwendung und die Integritätsinformation sind vorzugsweise auf dem sicherheitsmodulexternen Speicher gespeichert und werden beispielsweise von dem Betriebssystemtreiber mittels der Anforderung an das Sicherheitsmodul gesendet.
Unter "sicherheitsmodulextern" können Komponenten verstanden werden, die kein integraler Bestandteil des Sicherheitsmoduls sind.
Unter interne, häufig auch "sicherheitsmodulintern" genannt, können Komponenten oder Verfahrensschritte verstanden werden, die ein integraler Bestandteil des Sicherheitsmoduls sind oder auf sicherheitsmodulinternen Komponenten vorzugsweise exklusiv ausgeführt werden.
Das Laden und Ausführen wird beispielsweise zur Laufzeit des Betriebssystems und/oder des Sicherheitsmoduls und/oder der Steuerungsanwendung des Sicherheitsmoduls ausgeführt.
Der Begriff „Laden" kann im Zusammenhang mit der Patentanmeldung breit verstanden werden. Es kann darunter eine Variante verstanden werden, bei der eine zusätzliche Sicherheitsanwendung geladen wird. In einer anderen Variante kann darunter verstanden werden, dass eine geladene Sicherheitsanwendung durch die neu geladene Sicherheitsanwendung ersetzt wird, d.h. überschrieben wird. In einer weiteren Variante kann durch das Laden einer leeren Sicherheitsapplikation ein Löschen einer geladenen Sicherheitsanwendung erfolgen. Dies kann durch eine Lösch-Ladeanweisung erfolgen. Das Sicherheitsmodul stellt die Sicherheitsfunktion infolge des erfolgreichen Überprüfens beispielsweise eines autori¬ sierten Anfordernden, insbesondere dem Betriebssystem, dem Betriebssystemtreiber, dem Sicherheitsmodul selbst, einem anderen Sicherheitsmodul oder einer Kombination hiervon, be- reit. Die Sicherheitsanwendung oder die Sicherheitsfunktion generieren dabei beispielsweise Daten, die von dem Anfordernden und/oder dem Sicherheitsmodul selbst, beispielsweise für ein späteres Bereitstellen einer weiteren Sicherheitsfunktion, und/oder einer später geladenen und ausgeführten Sicher- heitsanwendung oder Sicherheitsfunktion genutzt werden können .
Unter einer Sicherheitsfunktion können kryptographische Funktionen, beispielsweise zum Erstellen einer digitalen Signa- tur, zum Entschlüsseln oder Verschlüsseln einer Datenstruktur, oder Funktionen zum Bereitstellen von Lizenzinformationen verstanden werden.
Das offenbarte Verfahren ist vorteilhaft gegenüber bisherigen Lösungen, da es einen dynamischen Austausch von (kryptogra- phischen) Sicherheitsfunktionen oder Sicherheitsanwendungen, beispielsweise kryptographischen Funktionen, zur Laufzeit des Betriebssystems des Gerätes erlaubt. Beispielsweise erlaubt das Verfahren, eine Vielzahl von Sicherheitsfunktionen durch ein Sicherheitsmodul, beispielsweise einen Vertrauensanker, bereitzustellen, wo zuvor aus Platzgründen nur eine einzige Sicherheitsfunktion oder Sicherheitsanwendung integrierbar war. Dadurch kann das Sicherheitsmodul kostengünstig gefer¬ tigt werden.
Bei einer ersten Ausführungsform des Verfahrens kann die Sicherheitsanwendung vor dem Überprüfen mittels eines ersten kryptographischen Schlüssels entschlüsselt werden.
Hierzu liegt die Sicherheitsanwendung auf dem sicherheitsmo- dulexternen Speicher in verschlüsselter Form vor, wobei auch die Integritätsinformation zur Sicherheitsanwendung verschlüsselt sein kann. Hier können symmetrische oder asymmet¬ rische Verfahren zum Einsatz kommen. Der erste kryptographi- sche Schlüssel ist vorzugsweise auf dem ersten sicherheitsmo- dulinternen Speicher abgelegt und vor sicherheitsmodulexter- nen Zugriffen geschützt. Hierdurch wird die Sicherheit des Verfahrens verbessert. Das Entschlüsseln kann dann beispiels¬ weise beim Laden oder beim Überprüfen der Integrität der Sicherheitsanwendung durchgeführt werden.
Bei weiteren Ausführungsformen des Verfahrens kann vor dem Überprüfen der Sicherheitsanwendung eine Headerinformation der Sicherheitsanwendung auf deren Integrität überprüft werden. Die Sicherheitsanwendung kann erst nach oder infolge der erfolgreichen Prüfung der Headerinformation geladen werden.
Die Headerinformation kann beispielsweise in der Anforderung zusammen mit der Sicherheitsanwendung und der Sicherheitsinformation enthalten sein. Die Steuerungsanwendung lädt die Sicherheitsanwendung erst, nachdem das Überprüfen erfolgreich war und hat den Vorteil, dass ein Ladevorgang einer potenti¬ ell manipulierten Sicherheitsanwendung frühzeitig abgebrochen wird, und damit die Sicherheit des Verfahrens verbessert wird .
Bei weiteren Ausführungsformen des Verfahrens kann die
Sicherheitsanwendung als ein Teil Anforderung übertragen werden, ein Speicherort der Sicherheitsanwendung als ein Teil der Anforderung übertragen werden, oder die Sicherheitsanwen- dung durch die Steuerungsanwendung von dem sicherheitsmodul- externen Speicher geladen werden.
Die verschiedenen Varianten des Ladens der Sicherheitsanwendung erlauben es beispielsweise dem Verfahren, dass die Da¬ tenquelle flexibel gewählt werden kann.
Bei weiteren Ausführungsformen des Verfahrens kann die
Sicherheitsanwendung zum Entschlüsseln, zum Überprüfen der Sicherheitsanwendung oder zum Überprüfen der Headerinformation in einen zweiten internen Speicher geladen werden.
Hierdurch kann die Sicherheit des Verfahrens erhöht werden, um zu verhindern, dass beispielsweise gefährlicher Programmcode nicht direkt in einen Speicher geladen wird, in dem ausführbare Anwendungen und/oder auch Daten liegen.
Bei weiteren Ausführungsformen des Verfahrens kann die
Sicherheitsanwendung zum Ausführen in den ersten internen Speicher oder in einen internen Anwendungsspeicher des
Sicherheitsmoduls geladen werden.
Dadurch, dass die Sicherheitsanwendung zum Ausführen in einen speziellen internen Speicher des Sicherheitsmoduls geladen wird, kann die Sicherheit des Verfahrens noch weiter erhöht werden .
Bei weiteren Ausführungsformen des Verfahrens können die Sicherheitsfunktion und/oder weitere Sicherheitsfunktionen von der Sicherheitsanwendung und/oder von weiteren Sicherheitsanwendungen bereitgestellt werden.
Je nach Konfiguration kann beispielsweise eine Sicherheitsanwendung mehrere Sicherheitsfunktionen bereitstellen. Dadurch können unterschiedliche Anwendungsszenarien realisiert werden und auf die individuellen Bedürfnisse des Gerätes angepasst werden. Beispielsweise können von der Sicherheitsanwendung, insbesondere mittels des Sicherheitsmoduls, Sicherheitsfunk- tionen exklusiv bereitgestellt werden. Auch kann eine Anforderung mehrere Sicherheitsanwendungen enthalten, die paralle oder nacheinander, beispielsweise durch einen Scheduler, aus geführt werden.
Bei weiteren Ausführungsformen des Verfahrens kann ein Daten austausch zwischen Sicherheitsanwendungen in dem Sicherheits modul über einen dritten internen Speicher des Sicherheitsmo duls erfolgen.
Durch den dritten internen Speicher, beispielsweise einen flüchtiger Speicher, lassen sich beispielsweise Ausgaben der Sicherheitsanwendung als Eingabe für eine weitere Sicherheitsanwendung verwenden, falls sich beispielsweise zu einem Zeitpunkt nur eine Sicherheitsanwendung in dem Sicherheitsmo dul befinden kann. Die Ausgaben der Sicherheitsanwendung kön nen beispielsweise die Daten sein die von der Sicherheits¬ funktion generieret werden. Hierdurch lassen sich vorzugswei se komplexe und/oder geschachtelte kryptographische Funktio¬ nen realisieren.
Bei weiteren Ausführungsformen des Verfahrens kann eine auszuführende Anzahl von Sicherheitsanwendungen durch die Steue rungsanwendung festgelegt werden.
Die auszuführende (maximale) Anzahl von Sicherheitsanwendungen wird vorzugsweise durch die Steuerungsanwendung begrenzt Hierzu kann beispielsweise während der Fertigung des Sicher¬ heitsmoduls die auszuführende Anzahl festgelegt werden. Soll eine neue und/oder zusätzliche Sicherheitsanwendung geladen werden, vergleicht die Steuerungsanwendung die auszuführende (maximale) Anzahl mit der ausgeführten Anzahl von Sicherheitsanwendungen. Würde mit der neuen Anwendung die die auszuführende Anzahl überschritten werden (also die ausgeführte Anzahl wäre größer als die auszuführende Anzahl) , kann die Steuerungsanwendung nach einem festgelegten Schema eine bereits geladene Sicherheitsanwendung entladen, was auch als ein Überschreiben betrachtet werden kann. Das festgelegte Schema kann beispielsweise festlegen, dass eine nicht mehr benötigte Sicherheitsanwendung überschrieben wird. Ist der Speicher oder die Rechenkapazität des Sicherheitsmoduls stark beschränkt, so kann beispielsweise festgelegt werden, dass nur eine einzige Sicherheitsanwendung zu einem Zeitpunkt geladen und ausgeführt werden kann. Das hat den Vorteil, dass der Speicherplatzbedarf beispielsweise auf einem FPGA gering gehalten werden kann.
Bei weiteren Ausführungsformen des Verfahrens kann anhand einer Autorisierungsinformation eine auszuführende Anzahl der Sicherheitsanwendungen festlegt werden, und/oder die Autorisierungsinformation legt fest, ob
die Sicherheitsanwendung ladbar ist; und/oder
die Sicherheitsanwendung von dem sicherheitsmodulexter- nen Speicher oder einem anderen Speicherort ladbar ist; und/oder
das Gerät sich in einem vorgegebenen Betriebsmodus be¬ findet, damit die Sicherheitsanwendung ladbar ist;
und/oder
für die Sicherheitsanwendung vorbestimmte Speicherberei¬ che des Sicherheitsmoduls oder kryptographische Funktio¬ nen der Steuerungsanwendung zugreifbar sind.
Die Autorisierungsinformation kann auch als Lizenzinformation bzw. Lizensierungsinformation bezeichnet werden.
Hierdurch kann das Laden und das Ausführen der Sicherheitsanwendung einfach über die Autorisierungsinformation, beispielsweise eine Sicherheitsrichtlinie oder eine Autorisie- rungspolicy, gesteuert werden. Beispielsweise kann die auszu¬ führende (maximale) Anzahl von Sicherheitsanwendungen beschränkt werden. Alternativ und/oder zusätzlich kann ein Zugriff auf die vorbestimmten Speicherbereiche, beispielsweise vordefinierte Speicherbereiche des ersten internen Speichers, des zweiten internen Speichers oder des dritten internen Speichers, entsprechend den Sicherheitsanforderungen festge¬ legt werden. Bei weiteren Ausführungsformen des Verfahrens kann die Auto- risierungsinformation als Teil der Anforderung empfangen werden, die Autorisierungsinformation in dem ersten internen Speicher abgelegt werden oder in einer Headerinformation der Sicherheitsanwendung abgelegt werden.
Hierdurch wird die Autorisierungsinformation flexibel dem Sicherheitsmodul oder der Steuerungsanwendung durch den ers- ten internen Speicher oder einen anderen internen Speicher des Sicherheitsmoduls, beispielsweise der zweite interne Speicher, der interne Anwendungsspeicher und/oder der dritte interne Speicher, bereitgestellt. Bei weiteren Ausführungsformen des Verfahrens kann beim Laden der Sicherheitsanwendung ein anwendungsspezifischer kryptog- raphischer Schlüssel bereitgestellt werden.
In einer Variante bildet die Steuerungsanwendung beispiels- weise einen anwendungsspezifischen kryptographischen Schlüssel oder anwendungsspezifische Rohdaten, einen sogenannten Primary Seed bzw. Private Primary Seed, zur Bildung eines kryptographischen Schlüssels abhängig von einer Identifizierungsinformation der geladenen Sicherheitsanwendung.
Hierdurch lässt sich die Sicherheit des Verfahrens noch wei¬ ter verbessern, da es vorzugsweise zu einer Sicherheitsanwendung nur einen kryptographischen Schlüssel gibt, um beispielsweise eine Sicherheitsinformation in Form einer digita- len Signatur zu überprüfen.
Bei weiteren Ausführungsformen des Verfahrens kann beim Laden der Sicherheitsanwendung ein anwendungsspezifischer Identifizierer bereitgestellt werden.
Beispielsweise kann zu einer Erstellung eines anwendungsspe¬ zifischen kryptographischen Schlüssels der anwendungsspezifische Identifizierer, der auch als Identifikator bezeichnet werden kann, in die Schlüsselgenerierung eingehen, um auf re produzierbare Weise einen anwendungsspezifischen kryptogra- phischen Schlüssel zu generieren.
Bei weiteren Ausführungsformen des Verfahrens können die Ver fahrensschritte durch das Sicherheitsmodul, insbesondere ei¬ nem Vertrauensanker, ausgeführt werden.
Beispielsweise kann durch ein exklusives Ausführen aller Ver fahrensschritte des Sicherheitsmoduls eine sehr hohe Sicher¬ heit des Verfahrens erreicht werden. Dabei können die weiter unten genannten Komponenten bzw. Einheiten des Sicherheitsmo duls zentral oder auch dezentral organisiert sein.
Bei weiteren Ausführungsformen des Verfahrens kann beim Über tragen der Sicherheitsanwendung eine Identitätsinformation und/oder eine Kontextinformation mit übertragen werden.
Bei weiteren Ausführungsformen des Verfahrens kann die
Sicherheitsanwendung Daten für eine danach ausgeführte
Sicherheitsanwendung bereitstellen.
Hierdurch lassen sich die Sicherheitsfunktionen von Sicherheitsanwendungen miteinander verketten und es können Vorzugs weise komplexe Anwendungsszenarien implementiert werden.
Bei weiteren Ausführungsformen des Verfahrens kann die Anfor derung zum Laden und Ausführen der Sicherheitsanwendung von dem Sicherheitsmodul erzeugt werden oder die Anforderung sicherheitsmodulextern erzeugt werden.
Hierdurch lässt sich das Verfahren flexibel für unterschied¬ liche Anwendungsszenarien einsetzen.
Gemäß einem weiteren Aspekt betrifft die Erfindung ein
Sicherheitsmodul, insbesondere einen Vertrauensanker, zum Be reitstellen einer Sicherheitsfunktion, insbesondere einer kryptographischen Funktion, für ein Gerät. Das Sicherheitsmo dul umfasst einen Prozessor und einen ersten internen Speicher. Das Sicherheitsmodul umfasst zusätzlich eine Schnitt¬ stelle zum Empfangen einer Anforderung zum Ausführen der Sicherheitsfunktion. Das Sicherheitsmodul umfasst zusätzlich eine Ladeeinheit zum Laden einer Sicherheitsanwendung für die Sicherheitsfunktion durch eine Steuerungsanwendung, wobei die Steuerungsanwendung auf dem ersten internen Speicher des Sicherheitsmoduls gespeichert ist und die Sicherheitsanwen¬ dung von einem sicherheitsmodulexternen Speicher übertragen wird. Das Sicherheitsmodul umfasst zusätzlich eine Überprü¬ fungseinheit zum Überprüfen einer Integrität der Sicherheits¬ anwendung mittels einer Sicherheitsinformation. Das Sicherheitsmodul umfasst eine Ausführungseinheit zum Ausführen der Sicherheitsanwendung und zum Bereitstellen der Sicherheitsfunktion, wobei das Ausführen und das Bereitstellen nur nach dem erfolgreichen Überprüfen der Integrität durchgeführt werden .
Dabei können die Einheiten des Sicherheitsmoduls zentral oder auch dezentral organisiert sein.
Gemäß einem weiteren Aspekt betrifft die Erfindung ein Gerät, das ein erfinderisches Sicherheitsmodul und/oder ein erfinde- risches anwendungsspezifisches Sicherheitsmodul oder mehrere erfinderische anwendungsspezifisehe Sicherheitsmodule auf- weist .
Unter einem anwendungsspezifischen Sicherheitsmodul kann ein erfindungsgemäßes Sicherheitsmodul verstanden werden, das beispielsweise aufgrund einer Autorisierungsinformation nur bestimmte Sicherheitsanwendungen ausführt. Es kann beispiels¬ weise auch nur eine vordefinierte Sicherheitsanwendung auf einem anwendungsspezifischen Sicherheitsmodul ausgeführt werden. Hierdurch kann beispielsweise das Gerät mehrere Sicher¬ heitsanwendungen parallel auf mehreren Sicherheitsmodulen verwenden . Desweiteren wird ein Computerprogrammprodukt mit Programmbe¬ fehlen zur Durchführung des genannten erfindungsgemäßen Verfahrens beansprucht. Zusätzlich wird eine Variante des Computerprogrammproduktes mit Programmbefehlen zur Konfiguration eines Erstellungsgeräts, beispielsweise ein 3D-Drucker oder ein ähnliches Gerät, beansprucht, wobei das Erstellungsgerät mit den Programmbe¬ fehlen derart konfiguriert wird, dass die genannte erfin- dungsgemäße Vorrichtung erstellt wird.
Darüber hinaus wird eine Bereitstellungsvorrichtung zum Speichern und/oder Bereitstellen des Computerprogrammprodukts be¬ ansprucht. Die Bereitstellungsvorrichtung ist beispielsweise ein Datenträger, der das Computerprogrammprodukt speichert und/oder bereitstellt. Alternativ und/oder zusätzlich ist die Bereitstellungsvorrichtung beispielsweise ein Netzwerkdienst, ein Computersystem, ein Serversystem, insbesondere ein verteiltes Computersystem, ein cloudbasiertes Rechnersystem und/oder virtuelles Rechnersystem, welches das Computerpro¬ grammprodukt vorzugsweise in Form eines Datenstroms speichert und/oder bereitstellt.
Diese Bereitstellung erfolgt beispielsweise als Download in Form eines Programmdatenblocks und/oder Befehlsdatenblocks, vorzugsweise als Datei, insbesondere als Downloaddatei, oder als Datenstrom, insbesondere als Downloaddatenstrom, des vollständigen Computerprogrammprodukts. Diese Bereitstellung kann beispielsweise aber auch als partieller Download erfol- gen, der aus mehreren Teilen besteht und insbesondere über ein Peer-to-Peer Netzwerk heruntergeladen oder als Datenstrom bereitgestellt wird. Ein solches Computerprogrammprodukt wird beispielsweise unter Verwendung der Bereitstellungsvorrichtung in Form des Datenträgers in einem System eingelesen und führt die Programmbefehle aus, sodass das erfindungsgemäße Verfahren auf einem Computer zur Ausführung gebracht wird oder das Erstellungsgerät derart konfiguriert wird, dass die¬ ses die erfindungsgemäße Vorrichtung erstellt. Die oben beschriebenen Eigenschaften, Merkmale und Vorteile dieser Erfindung sowie die Art und Weise, wie diese erreicht werden, werden klarer und deutlicher verständlich im Zusam- menhang mit der folgenden Beschreibung der Ausführungsbeispiele, die im Zusammenhang mit den Figuren näher erläutert werden. Dabei zeigen in schematischer Darstellung:
Fig. 1 ein Ablaufdiagramm eines ersten Ausführungsbei- spiels des offenbarten Verfahrens;
Fig. 2 ein Bereitstellen einer Sicherheitsfunktion mittels des offenbarten Verfahrens in einem zweiten Ausführungsbeispiel;
Fig. 3 ein Bereitstellen einer Sicherheitsfunktion mittels des offenbarten Verfahrens in einem dritten Ausführungsbeispiel; Fig. 4 ein autorisiertes Laden einer Sicherheitsanwendung zum Bereitstellen einer Sicherheitsfunktion entsprechend einem vierten Ausführungsbeispiel des of¬ fenbarten Verfahrens; Fig. 5 ein Sicherheitsmodul eines fünften Ausführungsbei¬ spiels; und
Fig. 6 ein Gerät eines sechsten Ausführungsbeispiels.
In den Figuren sind funktionsgleiche Elemente mit denselben Bezugszeichen versehen, sofern nichts anderes angegeben ist.
Fig. 1 ist ein Ablaufdiagramm eines ersten Ausführungsbei- spiels des offenbarten Verfahrens 100.
Das Verfahren 100 ist in der Lage, einem Gerät, beispielswei¬ se einem Messgerät für die Hochfrequenztechnik, ein Messge- rät, ein Steuergerät, ein Empfangsgerät einer Satellitenkom¬ munikationsstation oder ein Feldgerät einer Kraftwerksanlage, eine Sicherheitsfunktion, beispielsweise eine kryptographi- sche Funktion, bereitzustellen.
Um die Sicherheitsfunktion bereitzustellen, wird beispielsweise in dem Gerät ein Sicherheitsmodul installiert oder das Sicherheitsmodul ist eine Teilkomponente des Gerätes, wobei das Sicherheitsmodul insbesondere mehrere, vorzugsweise alle der nachfolgenden Verfahrensschritte ausführt.
In einem ersten Verfahrensschritt wird eine Anforderung zum Ausführen der Sicherheitsfunktion, beispielsweise über eine Kommunikationsschnittstelle, empfangen. Bei der Sicherheits- funktion kann es sich beispielsweise um eine kryptographische Funktion handeln, die insbesondere kryptographische Schlüs¬ sel, digitale Zertifikate oder kryptographische Funktionen bereitstellt. Die kryptographischen Funktionen können beispielsweise kryptographische Verfahren wie den Advanced Enc- ryption Standard (AES) implementieren. Alternativ und/oder zusätzlich können beispielsweise Lizenzinformationen zum Freischalten von Funktionen des Gerätes bereitgestellt werden. Die Lizenzinformationen können beispielsweise Messalgorithmen eines Messgerätes oder Frequenzbereiche freischalten, die von Messalgorithmen verarbeitet werden können.
In einem zweiten Verfahrensschritt 120 wird eine Sicherheits¬ anwendung für die Sicherheitsfunktion durch eine Steuerungsanwendung geladen, wobei die Steuerungsanwendung auf einem ersten internen Speicher des Sicherheitsmoduls gespeichert ist und die Sicherheitsanwendung von einem sicherheitsmodul- externen Speicher übertragen wird. Die Sicherheitsanwendung stellt dabei die angeforderte Sicherheitsfunktion bereit. Die Steuerungsanwendung wird während des Betriebes des
Sicherheitsmoduls vorzugsweise sicherheitsmodulintern ausge¬ führt, sodass vorzugsweise eine sicherheitsmodulexterne Ver- änderung, häufig auch als externe Veränderung bezeichnet, der Steuerungsanwendung unterbunden wird.
Die Sicherheitsanwendung selbst kann beispielsweise als ein Teil der Anforderung empfangen werden. Zusätzlich und/oder alternativ kann die Anforderung auch einen Speicherort angeben, von dem die Sicherheitsanwendung geladen werden kann.
Die Sicherheitsanwendung wird dabei vorzugsweise in den ers- ten internen Speicher oder in einen internen Anwendungsspeicher des Sicherheitsmoduls geladen. Unter einem externen Speicher kann hierbei eine Speichereinrichtung, beispielsweise eine Festplatte des Gerätes, verstanden werden, die nicht innerhalb des Sicherheitsmoduls angeordnet ist.
In einer Variante wird die Sicherheitsanwendung durch die Steuerungsanwendung ausgewählt. Dabei können beispielsweise eine oder mehrere Sicherheitsanwendungen einer bestimmten Sicherheitsfunktion fest zugeordnet sein. Diese Zuordnung kann beispielsweise als eine Liste, als eine Umsetzungstabel¬ le (engl, lookup table) oder in der Anforderung gespeichert sein .
In einem dritten Verfahrensschritt 130 wird eine Integrität der Sicherheitsanwendung anhand einer Sicherheitsinformation, beispielsweise einer Integritätsinformation, überprüft. Dies kann beispielsweise mittels einer Integritätsinformation in Form eines digitalen Zertifikates, einer digitalen Signatur oder einer Prüfsumme geschehen, die in der Anforderung ent- halten war. Eine Implementierung mittels digitaler Signaturen lässt sich beispielsweise mit dem RSA (Rivest, Shamir,
Adleman) , dem DSA (Digital Signature Algorithm) oder dem ECDSA (Elliptic Curve Digital Signature Algorithm) realisie¬ ren .
In einer Variante sind die Sicherheitsanwendungen verschlüsselt abgespeichert und werden mittels eines ersten kryptogra- phischen Schlüssels vor dem Überprüfen entschlüsselt. Sofern die Überprüfung der Integrität erfolgreich war, wird in einem vierten Verfahrensschritt 140 die Sicherheitsanwendung ausgeführt und die angeforderte Sicherheitsfunktion bei- spielsweise über die Kommunikationsschnittstelle bereitge¬ stellt. Mit anderen Worten wird die Sicherheitsanwendung infolge einer erfolgreichen Prüfung der Integrität ausgeführt. Somit wird bei einem Fehlschlag der Überprüfung ein Ausführen der Sicherheitsanwendung und des Bereitstellens der Sicher- heitsfunktion unterbunden.
Mit anderen Worten wird vor dem Ausführen der Sicherheitsanwendung im Sicherheitsmodul vorzugsweise die Integrität der Sicherheitsanwendung überprüft. Falls die Sicherheitsanwen- dung verschlüsselt ist, wird diese vor dem Überprüfen ent¬ schlüsselt .
Das „Ausführen" einer Sicherheitsanwendung kann auch als sicherheitsmodulinternes Aktivieren des Codes oder Programm- codes der Sicherheitsanwendung bezeichnet werden.
Ist beispielsweise die zu ladende Sicherheitsanwendung ver¬ schlüsselt, so kann dies mit einem symmetrischen oder einem asymmetrischen kryptographisches Verfahren durchgeführt wor- den sein. Der notwendige erste kryptographische Schlüssel zum Entschlüsseln der Sicherheitsanwendungen ist vorzugsweise im Sicherheitsmodul gespeichert, beispielswiese dem ersten in¬ ternen Speicher. Der erste kryptographische Schlüssel ist vorzugsweise vor sicherheitsmodulexternen Zugriffen ge- schützt, sodass vorzugsweise nur ein Zugriff durch die Steue¬ rungsanwendung auf den ersten kryptographischen Schlüssel erfolgen kann.
Dieser erste kryptographische Schlüssel kann beispielsweise während der Fertigung des Sicherheitsmoduls oder durch eine kryptographisch geschützte Aktualisierung auf dem Sicherheitsmodul gespeichert werden. Mit anderen Worten wird ein Verfahren offenbart, bei dem eine Anwendung, beispielsweise die Sicherheitsanwendung, des
Sicherheitsmoduls, beispielsweise eines Vertrauensankers, zu¬ nächst nicht intern gespeichert werden muss, sondern auch ex- tern vorliegen kann, und dass diese beispielsweise durch au¬ torisierte Entitäten auch austauschbar sein kann. Unter einer autorisierten Entität kann dabei eine Komponente des Gerätes verstanden werden, die eine Anforderung an den Vertrauensanker sendet und die notwendigen Informationen zur Prüfung der Integrität bereitstellen kann.
Dabei ist die Software, die auf dem Vertrauensanker bereit¬ steht, zunächst auf die Steuerungsanwendung beschränkt. Also auf dem Vertrauensanker steht vorzugsweise zunächst nur die Steuerungsanwendung zur Verfügung. Mit anderen Worten sind permanent auf dem Vertrauensanker gespeicherte Daten auf die Steuerungsanwendung beschränkt, da die Sicherheitsanwendung oder weitere Sicherheitsanwendungen in den Vertrauensanker geladen werden können und von dem Vertrauensanker gelöscht werden können.
Die Steuerungsanwendung ist in der Lage eine Anwendung, beispielsweise die Sicherheitsanwendung, von einem externen Speicher oder von der empfangenen Anforderung in den Vertrau- ensanker nachzuladen, wobei die Steuerungsanwendung fest im Vertrauensanker kodiert ist. Das bedeutet, dass insbesondere die Sicherheitsfunktion oder weitere Sicherheitsfunktionen die vom Vertrauensanker bereitgestellt werden sollen, vorzugsweise mittels eines Nachladens und eines Ausführens der Sicherheitsanwendung oder weiterer Sicherheitsanwendungen in den Vertrauensanker, bereitgestellt werden.
Im Vertrauensanker wird zu einem Zeitpunkt vorzugsweise nur eine Sicherheitsanwendung ausgeführt. Um Sicherheitsanwendun- gen die Möglichkeit zu geben, Daten, beispielsweise generier¬ te kryptographische Schlüssel oder Prüfsummen, sicher an spä¬ ter geladene Sicherheitsanwendungen weiter zu geben, kann der Vertrauensanker einen vorzugsweise exklusiv dafür genutzten zweiten internen Speicher, beispielsweise einen flüchtigen Speicher, aufweisen.
Die Steuerungsanwendung bleibt beim Laden und Ausführen der Sicherheitsanwendung vorzugsweise unverändert. Zugleich stellt die Steuerungsanwendung insbesondere sicher, dass die Konsistenz, also das korrekte Ausführen von Sicherheitsfunktionen, des vorzugsweise kompletten Systems im Vertrauensanker sichergestellt ist.
In einer ersten Implementierungsvariante kann die Konsistenz dadurch sichergestellt werden, dass eine neue Sicherheitsanwendung zunächst in einen dritten internen Speicher, beispielsweise einem Zwischenpuffer, des Sicherheitsankers gela- den wird. Sobald die Sicherheitsanwendung in dem dritten internen Speicher geladen ist, wird diese Sicherheitsanwendung, falls notwendig, entschlüsselt und auf ihre Integrität ge¬ prüft. Ist das Prüfen der Integrität erfolgreich, wird die Sicherheitsanwendung ausgeführt, was auch als aktiv geschal- tet bezeichnet werden kann. Die vorherige Sicherheitsanwendung kann dann deaktiviert und gegebenenfalls überschrieben werden .
In der ersten Implementierungsvariante ist es ausreichend, eine digitale Signatur oder einen MAC (Message Authentication Code) über die geladene Sicherheitsanwendung nach erfolgtem Laden zu überprüfen. Falls das Überprüfen der Integrität fehlschlägt, wird der Zwischenpuffer wieder freigegeben und die geladene Sicherheitsanwendung wird nicht ausgeführt.
In einer zweiten Implementierungsvariante teilen sich eine neu geladene Sicherheitsanwendung und die alte Sicherheitsanwendung, also eine vorher geladene Sicherheitsanwendung, die nicht mehr benötigt wird, einen gemeinsamen Speicherbereich im Vertrauensanker. Dieser Speicherbereich kann vorzugsweise im ersten internen Speicher oder der interne Anwendungsspeicher des Vertrauensankers sein. Die alte Sicherheitsanwendung wird insbesondere bereits beim Laden der neuen Sicherheitsan- wendung ersetzt. In diesem Fall wird vorzugsweise sicherge¬ stellt, dass bei einem Fehler während des Ladens das Nachla¬ den einer geeigneten Sicherheitsanwendung weiterhin möglich ist .
In der zweiten Implementierungsvariante ist es gegebenenfalls sinnvoll, zunächst eine Headerinformation der neuen Sicherheitsanwendung zu übertragen und die Integrität dieser Headerinformation zu überprüfen. Erst nachdem eine Überprüfung der Headerinformation erfolgreich war, wird infolgedessen die Sicherheitsanwendung übertragen und die alte Sicherheitsanwendung ersetzt. Eine Überprüfung der Integrität der Sicherheitsanwendung wird vorzugsweise nach abgeschlossener Übertragung zusätzlich durchgeführt. In die Headerinformation können beispielsweise Informationen über die zu ladende
Sicherheitsanwendung einfließen wie Version, Größe und/oder auszuführende Sicherheitsfunktionen .
In einer weiteren Variante kann mittels einer Autorisierungs- Information, beispielsweise eine Sicherheitsrichtlinie in Form einer Authorization Policy, festgelegt werden, welche nachladbaren Sicherheitsanwendungen genutzt werden dürfen und/oder aus welcher (Daten-) Quelle diese Sicherheitsanwendungen stammen dürfen. Dabei können nachfolgende Kriteri- en/Daten für eine Sicherheitsrichtlinie genutzt werden, für die beispielsweise eine Liste, häufig auch (Anwendungs/Si- cherheitsanwendungs ) Whitelist genannt, erstellt wird.
Sicherheitsanwendungen können beispielsweise nach deren Quel- le zugelassen werden. Es ist beispielsweise möglich, den „Subj ectName" und/oder den „Subj ectAltName" des digitalen Zertifikates, mit dem die digitale Signatur der Sicherheits¬ anwendung erstellt wurde, zu verwenden. Alternativ und/oder zusätzlich kann auch die Seriennummer und/oder der Aussteller des Zertifikates, mit dem die digitale Signatur der Sicher¬ heitsanwendung erstellt wurde, verwendet werden. Sicherheitsanwendungen können aber auch nach deren Kennzeichnung zugelassen werden. Es ist beispielsweise möglich, einen anwendungsspezifischen Identifizierer einer Sicherheitsanwendung zum Abgleich mit einer Liste von erlaubten Sicherheits- anwendungen zu verwenden. Alternativ und/oder zusätzlich kann auch ein Fingerabdruck (engl, fingerprint) einer Sicherheitsanwendung, beispielsweise in Form eines kryptographischen hash-Werts oder einer digitalen Signatur, verwendet werden. Alternativ und/oder zusätzlich zur beschriebenen Liste kann die Autorisierungsinformation auch in der Headerinformation der jeweiligen nachladbaren Sicherheitsanwendung eingetragen werden. Der Vorteil dieses Ansatzes liegt darin, dass die Autorisierungsinformation nicht explizit in Form einer Liste geladen wird und damit nicht zusätzlichen Speicherplatz im Vertrauensanker benötigt.
Neben der Autorisierungsinformation kann zusätzlich auch der Betriebsmodus des Gerätes in die Autorisierung des Ladens ei- ner Sicherheitsanwendung mit einbezogen werden. Ein Beispiel hierfür ist: wenn es sich um ein Gerät mit einer bestimmten Sicherheitszulassung handelt, darf im Falle einer Sicherheitskritischen Operation kein Code nachgeladen/ausgetauscht werden. Hierzu können weitere Schnittstellen am Vertrauensan- ker notwendig sein, um diese Zustandsinformation mit auszuwerten .
Weiterhin kann anhand der Autorisierungsinformation festgelegt werden, auf welche kryptographischen Schlüssel oder wel- che kryptographischen Operationen des Vertrauensankers die Sicherheitsanwendung zugreifen kann. Dazu kann der Zugriff auf manche vordefinierte Speicherbereiche, wie beispielsweise Schlüsselspeicherbereiche, vordefinierte Funktionsaufrufe oder Opcodes, gesperrt werden.
In einer weiteren Variante wird für eine geladene Sicherheitsanwendung ein dafür anwendungsspezifischer kryptographi- scher Schlüssel bereitgestellt. Dieser kann beispielsweise beim Laden der Sicherheitsanwendung gebildet werden, oder der anwendungsspezifische krypto- graphische Schlüssel kann bei Nutzung einer kryptographischen Operation oder bei einem Zugriff auf einen Schlüsselspeicher gebildet werden. Der anwendungsspezifische kryptographische Schlüssel kann dabei zufällig gewählt werden oder er kann de¬ terministisch durch eine Schlüsselableitung gebildet werden. In die Schlüsselableitung geht vorzugsweise ein sicherheits- anwendungsabhängiger Ableitungsparameter ein, beispielsweise ein anwendungsspezifischer Identifizierer, eine Prüfsumme der Sicherheitsanwendung, z.B. ein kryptographischer Hash-Wert, oder eine Herausgeberinformation der Sicherheitsanwendung. Insbesondere kann abhängig von einem Master Key des Vertrau- ensankers ein anwendungsspezifischer Master Key gebildet werden und der Sicherheitsanwendung als anwendungsspezifischer Master Key bereitgestellt werden.
Unter Master Key wird hier auch eine Information verstanden, die zur Bildung eines oder mehrerer kryptographischen Schlüssel verwendbar ist, ein sogenannter Private Primary Seed. Ein Private Primary Seed kann als Eingabeparameter für unterschiedliche Schlüsselbildungsfunktionen verwendet werden, um deterministisch einen privaten Schlüssel bzw. ein Schlüssel- paar aus privatem und öffentlichem Schlüssel zu bilden.
In einer weiteren Variante wird analog zum Bereitstellen des anwendungsspezifischen kryptographischen Schlüssels ein anwendungsspezifischer Identifizierer der Sicherheitsanwendung bereitgestellt. Dadurch können beispielsweise für unter¬ schiedliche Sicherheitsanwendungen des Vertrauensankers un¬ terschiedliche anwendungsspezifische Identifizierer bereitge¬ stellt werden. Dadurch wird erreicht, dass eine Sicherheits¬ anwendung nicht den gleichen Identifizierer wie eine andere Sicherheitsanwendung des gleichen Vertrauensankers verwenden kann. Der Identifizierer kann der Sicherheitsanwendung beispielsweise kryptographisch geschützt bereitgestellt werden (Attestierung) oder er kann in einer Schlüsselableitung, die durch die Sicherheitsanwendung angestoßen wurde, als Ableitungsparameter verwendet werden.
Die Fig. 2 zeigt ein Bereitstellen einer Sicherheitsfunktion durch ein Sicherheitsmodul eines zweiten Ausführungsbeispiels 200. In Einzelnen wird eine Variante des Verfahrens verwen¬ det, welches in Fig. 1 beschrieben wurde.
Die Fig. 2 zeigt ein Sicherheitsmodul 230, das eine Steue- rungsanwendung 232 umfasst. Darüber hinaus zeigt Fig. 2 sicherheitsmodulexterne Komponenten wie ein Betriebssystem 220, beispielsweise einen Linux-Kernel, mit Treibern 222, ei¬ ne Ladeanwendung 210 des Betriebssystems 220, eine erste Sicherheitsanwendung 214 und eine n-te Sicherheitsanwendung 216. Die sicherheitsmodulexternen Komponenten können ein Teil eines Gerätes sein, indem das Sicherheitsmodul 230 verbaut ist .
Das Sicherheitsmodul 230 ist beispielsweise ein Vertrauensan- ker, der als ein FPGA-Modul realisiert ist. Eine Integrität der Sicherheitsanwendungen ist mit einem kryptographischen Algorithmus, beispielsweise dem HMAC-SHA256 (Keyed-Hash Mes¬ sage Authentication Code, Secure Hash Algorithm 256) , geschützt und als Integritätsinformation zusammen mit den
Sicherheitsanwendungen auf einem sicherheitsmodulexternen
Speicher abgelegt. Die Ladeanwendung 210 des Betriebssystems 220 wählt beispielsweise die erste Sicherheitsanwendung 214 aus, damit der Vertrauensanker 230 eine Sicherheitsfunktion der ersten Sicherheitsanwendung 214 ausführt und bereit- stellt.
Die Ladeanwendung 210 übergibt dazu die erste Sicherheitsanwendung 214 mit der Integritätsinformation, beispielsweise eine digitale Signatur über die Integritätsinformation, dem Betriebssystem 220, damit das Betriebssystem 220 über den
Treiber 222 an den Sicherheitsanker 230 eine Datenübertragung 201 durchführen kann und eine Anforderung zur Bereitstellung der Sicherheitsfunktion der ersten Sicherheitsanwendung 214 stellen kann.
Der Treiber 222 schickt also eine Anforderung, die die
Sicherheitsanwendung und die Integritätsinformation umfasst, an den Vertrauensanker 230, damit der Vertrauensanker die erste Sicherheitsanwendung 214 ausführt und die Sicherheits¬ funktion bereitstellt. Hierzu wird die erste Sicherheitsan¬ wendung 214 durch die Steuerungsanwendung 232 in einen zwei- ten internen Speicher des Vertrauensankers geladen, und die
Steuerungsanwendung 232 überprüft anschließend die Integrität der ersten Sicherheitsanwendung 214 mit Hilfe der IntegritätsInformation . Erst wenn die Überprüfung der Integrität der ersten Sicherheitsanwendung 214 erfolgreich war, wird diese als eine im Vertrauensanker 230 auszuführende Sicherheitsanwendung 234 angesehen . Die Steuerungsanwendung 232 lädt dann beispielsweise von dem zweiten internen Speicher die erste Sicherheitsanwendung 214 in einen ersten internen Speicher des Vertrauensankers oder in einen internen Anwendungsspeicher des Vertrauensankers. Die erste Sicherheitsanwendung 214 wird dann ausgeführt und die angeforderte Sicherheitsfunktion dem Betriebssystem 220 bereitgestellt .
Die Fig. 3 zeigt ein Bereitstellen einer Sicherheitsfunktion durch ein Sicherheitsmodul eines dritten Ausführungsbeispiels 300. In Einzelnen wird eine Variante des Verfahrens verwen¬ det, welches in Fig. 1 beschrieben wurde verwendet.
Die Fig. 3 zeigt ein Sicherheitsmodul 330, das eine Steue¬ rungsanwendung 232 und einen dritten internen Speicher 336 des Sicherheitsmoduls 330 umfasst. Darüber hinaus zeigt Fig. 3 sicherheitsmodulexterne Komponenten wie ein Betriebssystem 220, beispielsweise einen Linux-Kernel, mit Treibern 222, ei¬ ne Ladeanwendung 210 des Betriebssystems 220, eine erste Sicherheitsanwendung 214 und zweite Sicherheitsanwendung 316. Die sicherheitsmodulexternen Komponenten können ein Teil eines Gerätes sein, in dem das Sicherheitsmodul 330 verbaut ist .
Das Sicherheitsmodul 330 ist beispielsweise ein Vertrauensan¬ ker, der als ein FPGA-Modul realisiert ist. Eine Integrität der Sicherheitsanwendungen ist mit einem kryptographischen Algorithmus, beispielsweise dem HMAC-SHA256 (Keyed-Hash Mes- sage Authentication Code, Secure Hash Algorithm 256) , geschützt und als Integritätsinformation zusammen mit den
Sicherheitsanwendungen auf einem sicherheitsmodulexternen Speicher abgelegt. Die Ladeanwendung 210 des Betriebssystems 220 wählt beispielsweise die erste Sicherheitsanwendung 214 zu einem ersten Zeitpunkt ti aus, damit der Vertrauensanker 230 eine erste Sicherheitsfunktion der ersten Sicherheitsanwendung 214 ausführt und bereitstellt.
Die Ladeanwendung 210 des Betriebssystems 220 wählt bei- spielsweise die zweite Sicherheitsanwendung 316 zu einem zweiten Zeitpunkt t2 aus, damit der Vertrauensanker 230 eine zweite Sicherheitsfunktion der zweiten Sicherheitsanwendung 316 ausführt und bereitstellt. Die Ladeanwendung 210 übergibt dazu die erste Sicherheitsan¬ wendung 214 mit der zugehörigen Integritätsinformation, beispielsweise eine digitale Signatur über die Integritätsinformation, dem Betriebssystem 220, damit das Betriebssystem 230 über den Treiber 222 an den Sicherheitsanker 330 eine erste Datenübertragung 301 zu dem ersten Zeitpunkt ti durchführen kann und eine erste Anforderung zur Bereitstellung der ersten Sicherheitsfunktion der ersten Sicherheitsanwendung 214 stellen kann. Analog wird eine zweite Datenübertragung 302 zum zweiten
Zeitpunkt t2 für die zweite Sicherheitsanwendung 316 durchge¬ führt. Die zweite Sicherheitsfunktion wird dann analog zur ersten Sicherheitsfunktion bereitgestellt. Der Treiber 222 schickt hierzu beispielsweise die erste An¬ forderung, die die erste Sicherheitsanwendung 214 und die zugehörigen Integritätsinformationen umfasst, zum ersten Zeit- punkt ti an den Vertrauensanker 330, damit der Vertrauensanker 330 die erste Sicherheitsanwendung 214 ausführt und die erste Sicherheitsfunktion bereitstellt.
Der Treiber 222 schickt zum zweiten Zeitpunkt t2 beispiels- weise eine zweite Anforderung, die die zweite Sicherheitsan¬ wendung 316 und die zugehörige Integritätsinformation umfasst, an den Vertrauensanker 330, damit der Vertrauensanker 330 die zweite Sicherheitsanwendung 316 ausführt und die zweite Sicherheitsfunktion bereitstellt.
Zunächst wird die erste Sicherheitsanwendung 214 durch die Steuerungsanwendung 232 in einen zweiten internen Speicher des Vertrauensankers geladen, und die Steuerungsanwendung 232 überprüft anschließend die Integrität der ersten Sicherheits- anwendung 214 mit Hilfe der Integritätsinformation.
Erst wenn die Überprüfung der Integrität der ersten Sicherheitsanwendung erfolgreich war, wird diese als eine im Vertrauensanker 230 auszuführende Sicherheitsanwendung 234 ange- sehen.
Die Steuerungsanwendung 232 lädt dann beispielsweise von dem zweiten internen Speicher die erste Sicherheitsanwendung 214 in einen ersten internen Speicher des Vertrauensankers oder in einen internen Anwendungsspeicher des Vertrauensankers. Die erste Sicherheitsanwendung 214 wird dann ausgeführt und die angeforderte Sicherheitsfunktion dem Betriebssystem 220, dem Vertrauensanker 330 oder der Steuerungsanwendung 232 bereitgestellt. Die erste Sicherheitsanwendung 214 oder die erste Sicherheitsfunktion kann auch Daten generieren, die auf einem dritten internen Speicher 336 des Sicherheitsmoduls abgelegt werden, damit die zweite Sicherheitsanwendung 316 die¬ se zu einem späteren Zeitpunkt nutzen kann. Wenn die zweite Sicherheitsanwendung 316 analog zur ersten Sicherheitsanwendung 214 geladen und ausgeführt wird, kann die zweite Sicherheitsfunktion die von der ersten Sicher- heitsfunktion generierten Daten aus dem dritten internen Speicher 336 lesen und verarbeiten.
Auf diese Weise lassen sich beliebig viele Sicherheitsanwendungen nacheinander laden und die Sicherheitsanwendungen kön- nen über den dritten internen Speicher 336 Daten sicherheitsgeschützt austauschen.
Durch dieses Nacheinanderschalten von Sicherheitsanwendungen wird es möglich, komplexe Funktionalitäten, die insgesamt die Ressourcen des Vertrauensankers übersteigen würden, durch eine Sequenz von Sicherheitsanwendungen zu realisieren. Beispielsweise kann die Berechnung einer SHA256-ECDSA Signatur in die Berechnung des Hashs (SHA256) und der Signatur (ECDSA) unterteilt werden. Dabei berechnet die erste Sicherheitsan- wendung 214 den SHA256 Hash, auch Prüfsumme genannt. Die zweite Sicherheitsanwendung 316 berechnet eine digitale Sig¬ natur. Der benötigte Zwischenwert (Hashwert) wird über den dritten internen Speicher 336 ausgetauscht. Der Vertrauensanker kann beispielsweise auch eine Stack- Maschine realisieren, die jeweils einzelne Befehle nachlädt.
In einer Variante enthält die erste Anforderung bereits alle auszuführenden Sicherheitsanwendungen, deren Integritätsin- formation und eine Information über die angeforderten Sicher- heitsfunktionen .
In einer weiteren Variante stellt die erste Sicherheitsanwendung Daten für eine danach ausgeführte Sicherheitsanwendung bereit. Im Einzelnen kann hierdurch beispielsweise eine Auto¬ risierung von der ersten Sicherheitsanwendung 214 zu der zweiten Sicherheitsanwendung 316 implementiert werden. Dabei hinterlegt die erste Sicherheitsanwendung neben den (optiona- len) Zwischenwerten einen Authentisierungstoken, beispielsweise in dem dritten internen Speicher 336 des Sicherheitsmoduls 330. Das Authentisierungstoken wird ausgewertet, bevor die Berechnung fortgesetzt wird. Dabei sind zwei Implementie- rungsvarianten vorstellbar:
Bei der ersten Implementierungsvariante legt die erste
Sicherheitsanwendung oder die erste Sicherheitsfunktion eine Beschränkung fest, dass nur bestimmte Sicherheitsanwendungen später nachgeladen und/oder ausgeführt werden können. Die Beschränkung wird durch die Steuerungsanwendung 232 des Vertrauensankers durchgesetzt.
In der zweiten Implementierungsvariante ist ein Akzeptieren von Zwischenergebnissen von vorher ausgeführten Sicherheitsanwendungen, beispielsweise der ersten Sicherheitsanwendung 214, durch die zweite Sicherheitsanwendung 316 auf vorgegebene Zwischenergebnisse beschränkt. Das Beschränken wird in der zweiten Implementierung von der zweiten Sicherheitsanwendung 316 durchgesetzt.
In einer weiteren Variante können die vorherigen Ausführungsbeispiele dahingehend erweitert werden, dass zusätzlich zur Überprüfung der Integrität auch noch die Autorisierung für das Nachladen bestimmter Sicherheitsanwendungen überprüft wird. Die damit zusammenhängende Autorisierungsinformation kann vom Gerätebetreiber erstellt werden und kann beispielsweise in Form einer signierten Information zur Verfügung gestellt werden. Dazu verfügt die Steuerungsanwendung über eine Erweiterung, die das Festlegen einer Besitzerinformation oder Operatorinformation ermöglicht. Dies kann während der Produktion oder auch bei der Inbetriebnahme realisiert werden. Ein möglicher Ablauf beim Laden in der Variante mit einer externen Autorisierungsinformation, beispielsweise eine Autorisie- rungs-Policy, ist aus Sicht des Sicherheitsmoduls in Fig. 4 dargestellt . Im Einzelnen zeigt Fig. 4 ein Ablaufdiagramm mit einem Startelement 405 und einem Endelement 460.
In einem ersten Verfahrensschritt 410 wird beispielsweise versucht, die Besitzerinformation oder die Operatorinformati¬ on zu lesen. In einem zweiten Verfahrensschritt 415 wird überprüft, ob die Besitzerinformation oder die Operatorinformation lesbar war. Falls das Überprüfen fehlschlägt, also die Besitzerinformati¬ on oder die Operatorinformation nicht vorhanden ist, wird beispielsweise in einem Verfahrensschritt 420 eine (Daten-) Quelle der nachzuladenden Sicherheitsanwendung oder eine Art, beispielsweise ein bestimmter Typ von Sicherheitsanwendungen wie Verschlüsselungsanwendungen, der nachzuladenden Sicherheitsanwendung uneingeschränkt zum Laden und Ausführen akzeptiert .
Falls das Überprüfen erfolgreich ist, also die Besitzerinfor- mation oder die Operatorinformation vorhanden ist, wird beispielsweise in einem Verfahrensschritt 425 die Autorisie- rungsinformation geladen und die Authentizität der Autorisie- rungsinformation verifiziert. In einem Verfahrensschritt 430 wird dann entschieden, welche weiteren Verfahrensschritte anhand des Ergebnisses des Veri¬ fizierens ausgeführt werden sollen.
Falls das Verifizieren fehlschlägt, wird beispielsweise in einem Verfahrensschritt 435 eine Fehlermeldung ausgegeben und die Sicherheitsanwendung nicht geladen und/oder ausgeführt.
Falls das Verifizieren erfolgreich ist, wird beispielsweise in einem Verfahrensschritt 440 die Sicherheitsanwendung gela- den und deren Integrität überprüft. Alternativ und/oder zu¬ sätzlich wird die Autorisierungsinformation geladen und die Sicherheitsanwendung und/oder deren Sicherheitsfunktion überprüft, ob diese ausführbar sind. In einem Verfahrensschritt 445 wird dann über eine Ausführung der Sicherheitsanwendung anhand eines Ergebnisses der Überprüfung der Integrität und/oder Autorisierungsinformation entschieden.
Ist die Überprüfung erfolgreich, wird beispielsweise in einem Verfahrensschritt 455 die Sicherheitsanwendung ausgeführt und die Sicherheitsfunktion der Sicherheitsanwendung demjenigen bereitgestellt, der diese angefordert hat.
Ist die Überprüfung fehlgeschlagen, wird beispielsweise in einem Verfahrensschritt 450 eine Fehlermeldung ausgegeben und eine Ausführung der Sicherheitsanwendung unterbunden.
Die Fig. 5 zeigt ein Sicherheitsmodul 500 eines fünften Aus¬ führungsbeispiels .
Das Sicherheitsmodul 500, das beispielsweise als ein Vertrau- ensanker realisiert ist, stellt eine Sicherheitsfunktion, beispielsweise eine kryptographischen Funktion, für ein Gerät bereit. Das Sicherheitsmodul 500 umfasst einen Prozessor 510, einen ersten internen Speicher 520, eine Ladeeinheit 530, eine Überprüfungseinheit 540, eine Ausführungseinheit 550 und eine Schnittstelle 585, die mittels eines ersten Busses 580 kommunikativ miteinander in Verbindung stehen.
Im Einzelnen empfängt die Schnittstelle 585 eine Anforderung zum Ausführen einer Sicherheitsfunktion. Die Ladeeinheit 530 lädt eine Sicherheitsanwendung für die Sicherheitsfunktion mittels einer Steuerungsanwendung, wobei die Steuerungsanwendung auf einem ersten internen Speicher 520 des Sicherheitsmoduls 500 gespeichert wird und die Sicherheitsanwendung von einem sicherheitsmodulexternen Speicher übertragen wird.
Die Sicherheitsanwendung wird dann beispielsweise durch den Prozessor 510 sicherheitsmodulintern ausgeführt, sodass das in den Fig. 1-4 offenbarte Verfahren rechnergestützt ausge¬ führt werden kann.
Die Überprüfungseinheit 540 überprüft eine Integrität der Sicherheitsanwendung anhand einer Sicherheitsinformation. Die Ausführungseinheit 550 führt die Sicherheitsanwendung aus und stellt die Sicherheitsfunktion beispielsweise über die
Schnittstelle 585 bereit, wobei das Ausführen und Bereitstel¬ len nur nach dem erfolgreichen Überprüfen der Integrität durchgeführt wird.
Das Sicherheitsmodul kann beispielsweise in einem Gerät 600, wie in Fig. 6 gezeigt, integriert sein. Das Gerät 600 kann beispielsweise ein eingebettetes System, ein Herzschrittma- eher, ein Feldgerät einer Kraftwerksanlage oder ein Steuerge¬ rät einer Feuerlöschanlage sein.
Im Einzelnen umfasst das Gerät 600 ein Sicherheitsmodul 500, so wie dieses in Fig. 5 beschrieben wird. Darüber hinaus um- fasst das Gerät eine Betriebssystemkomponente 620 und eine
Treiberkomponente 630, die über einen zweiten Bus 610 mit dem Sicherheitsmodul kommunikativ in Verbindung stehen.
Benötigt die Betriebssystemkomponente 620 eine Sicherheits- funktion, sendet diese mit Hilfe der Treiberkomponente 630 eine Anforderung zum Ausführen der Sicherheitsfunktion über den zweiten Bus 610 an das Sicherheitsmodul 500. Das Sicher¬ heitsmodul stellt dann, wie in den vorherigen Ausführungsbei¬ spielen beschrieben, die Sicherheitsfunktion bereit, sofern zumindest die Integrität einer Sicherheitsanwendung, die die Sicherheitsfunktion bereitstellt, erfolgreich überprüft wurde .
Obwohl die Erfindung im Detail durch die Ausführungsbeispiele näher illustriert und beschrieben wurde, ist die Erfindung nicht durch die offenbarten Beispiele eingeschränkt, und an¬ dere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen.

Claims

Patentansprüche
1. Verfahren (100) zum Bereitstellen einer Sicherheitsfunktion, insbesondere einer kryptographischen Funktion, für ein Gerät (600), wobei folgende Verfahrensschritten ausgeführt werden :
Empfangen (110) einer Anforderung zum Ausführen der Sicherheitsfunktion;
Laden (120) einer Sicherheitsanwendung (214, 216, 316) für die Sicherheitsfunktion durch eine Steuerungsanwendung (232), wobei
die Steuerungsanwendung (232) auf einem ersten internen Speicher (520) eines Sicherheitsmoduls (500) gespeichert ist;
- die Sicherheitsanwendung (214, 216, 316) von einem sicherheitsmodulexternen Speicher übertragen wird; Überprüfen (130) einer Integrität der Sicherheitsanwendung (214, 216, 316) mittels einer Sicherheitsinformati¬ on; und
- Ausführen (140) der Sicherheitsanwendung (214, 216, 316) und Bereitstellen der Sicherheitsfunktion, wobei das Ausführen und Bereitstellen nach dem erfolgreichen Überprüfen (130) der Integrität durchgeführt wird.
2. Verfahren (100) nach dem vorhergehenden Anspruch, wobei die Sicherheitsanwendung (214, 216, 316) vor dem Überprüfen (130) mittels eines ersten kryptographischen Schlüssels ent¬ schlüsselt wird.
3. Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei
vor dem Überprüfen (130) der Sicherheitsinformation eine Headerinformation der Sicherheitsanwendung (214, 216, 316) auf deren Integrität überprüft wird; und
- die Sicherheitsanwendung (214, 216, 316) erst nach erfolgreicher Prüfung der Headerinformation geladen wird.
4. Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei die Sicherheitsanwendung (214, 216, 316) als ein Teil der Anforderung übertragen wird, ein Speicherort der Sicherheitsanwendung (214, 216, 316) als ein Teil der Anforderung übertragen wird oder die Sicherheitsanwendung (214, 216, 316) durch die Steuerungsanwendung (232) von dem sicherheitsmodul- externen Speicher geladen wird.
5. Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei die Sicherheitsanwendung (214, 216, 316) zum Entschlüs¬ seln, zum Überprüfen (130) der Sicherheitsanwendung (214, 216, 316) oder zum Überprüfen der Headerinformation in einen zweiten internen Speicher geladen wird.
6. Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei die Sicherheitsanwendung (214, 216, 316) zum Ausführen (140) in den ersten internen Speicher (520) oder in einen internen Anwendungsspeicher des Sicherheitsmoduls (500) geladen wird .
7. Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei die Sicherheitsfunktion und/oder weitere Sicherheits¬ funktionen von der Sicherheitsanwendung (214, 316) und/oder von weiteren Sicherheitsanwendungen (216, 316) bereitgestellt werden.
8. Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei ein Datenaustausch zwischen Sicherheitsanwendungen (214, 216, 316) in dem Sicherheitsmodul (500) über einen dritten internen Speicher des Sicherheitsmoduls (500) er¬ folgt .
9. Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei eine auszuführende Anzahl von Sicherheitsanwendungen (214, 216, 316) durch die Steuerungsanwendung (232) festgelegt wird.
10. Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei anhand einer Autorisierungsinformation eine auszuführende Anzahl der Sicherheitsanwendungen (214, 216, 316) festlegt wird, und/oder anhand der Autorisierungsinformation festlegt wird, ob
die Sicherheitsanwendung (214, 216, 316) ladbar ist; und/oder
die Sicherheitsanwendung (214, 216, 316) von dem sicher- heitsmodulexternen Speicher oder einem anderen Speicher- ort ladbar ist; und/oder
das Gerät (600) sich in einem vorgegebenen Betriebsmodus befindet, damit die Sicherheitsanwendung (214, 216, 316) ladbar ist; und/oder
für die Sicherheitsanwendung (214, 216, 316) vorbestimm- te Speicherbereiche des Sicherheitsmoduls (500) oder kryptographische Funktionen der Steuerungsanwendung (232) zugreifbar sind.
11. Verfahren (100) nach Anspruch 10, wobei die Autorisie- rungsinformation als Teil der Anforderung empfangen wird, die
Autorisierungsinformation in dem ersten internen Speicher (520) abgelegt wird oder in einer Headerinformation der
Sicherheitsanwendung (214, 216, 316) abgelegt wird.
12. Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei beim Laden der Sicherheitsanwendung (214, 216, 316) ein anwendungsspezifischer kryptographischer Schlüssel bereitgestellt wird.
13. Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei beim Laden der Sicherheitsanwendung (214, 216, 316) ein anwendungsspezifischer Identifizierer bereitgestellt wird.
14. Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei die Verfahrensschritte durch das Sicherheitsmodul
(500), insbesondere einem Vertrauensanker (300, 400), ausge¬ führt werden.
15. Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei beim Übertragen der Sicherheitsanwendung (214, 216, 316) eine Identitätsinformation und/oder eine Kontextinformation mit übertragen werden.
16. Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei die Sicherheitsanwendung (214) Daten für eine danach ausgeführte Sicherheitsanwendung (316) bereitstellt.
17. Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei die Anforderung zum Laden und Ausführen der Sicherheitsanwendung (214, 216, 316) von dem Sicherheitsmodul (500) erzeugt wird oder die Anforderung sicherheitsmodulextern erzeugt wird.
18. Sicherheitsmodul (500), insbesondere ein Vertrauensanker (300, 400), zum Bereitstellen einer Sicherheitsfunktion, insbesondere einer kryptographischen Funktion, für ein Gerät (600), aufweisend:
- einen Prozessor (510);
einen ersten internen Speicher (520);
eine Schnittstelle (585) zum Empfangen einer Anforderung zum Ausführen der Sicherheitsfunktion;
eine Ladeeinheit (530) zum Laden einer Sicherheitsanwen- dung (214, 216, 316) für die Sicherheitsfunktion durch eine Steuerungsanwendung (232), wobei
die Steuerungsanwendung (232) auf dem ersten internen Speicher (520) des Sicherheitsmoduls (500) ge¬ speichert ist;
- die Sicherheitsanwendung (214, 216, 316) von einem sicherheitsmodulexternen Speicher übertragen wird; eine Überprüfungseinheit (540) zum Überprüfen einer In¬ tegrität der Sicherheitsanwendung (214, 216, 316) mittels einer Sicherheitsinformation; und
- eine Ausführungseinheit (550) zum Ausführen der Sicher¬ heitsanwendung (214, 216, 316) und Bereitstellen der Sicherheitsfunktion, wobei das Ausführen und Bereitstel- len nur nach dem erfolgreichen Überprüfen der Integrität durchgeführt wird.
19. Gerät, (600) das ein Sicherheitsmodul (500) nach An- spruch 18 und/oder ein anwendungsspezifisches Sicherheitsmo¬ dul (500) oder mehrere anwendungsspezifische Sicherheitsmodu¬ le (500) nach Anspruch 18 aufweist.
20. Computerprogrammprodukt mit Programmbefehlen zur Durch- führung des Verfahrens nach einem der Ansprüche 1-17.
21. Computerprogrammprodukt mit Programmbefehlen für ein Erstellungsgerät, das mittels der Programmbefehle konfigu¬ riert wird, das Sicherheitsmodul (500) nach Anspruch 18 oder das Gerät nach Anspruch 19 zu erstellen.
22. Bereitstellungsvorrichtung für das Computerprogrammprodukt nach Anspruch 20 oder 21, wobei die Bereitstellungsvorrichtung das Computerprogrammprodukt speichert und/oder be- reitstellt.
EP16805357.7A 2015-12-15 2016-11-28 Verfahren und sicherheitsmodul zum bereitstellen einer sicherheitsfunktion für ein gerät Withdrawn EP3369027A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102015225270.1A DE102015225270A1 (de) 2015-12-15 2015-12-15 Verfahren und Sicherheitsmodul zum Bereitstellen einer Sicherheitsfunktion für ein Gerät
PCT/EP2016/079004 WO2017102295A1 (de) 2015-12-15 2016-11-28 Verfahren und sicherheitsmodul zum bereitstellen einer sicherheitsfunktion für ein gerät

Publications (1)

Publication Number Publication Date
EP3369027A1 true EP3369027A1 (de) 2018-09-05

Family

ID=57471835

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16805357.7A Withdrawn EP3369027A1 (de) 2015-12-15 2016-11-28 Verfahren und sicherheitsmodul zum bereitstellen einer sicherheitsfunktion für ein gerät

Country Status (5)

Country Link
US (1) US20180365411A1 (de)
EP (1) EP3369027A1 (de)
CN (1) CN108369623A (de)
DE (1) DE102015225270A1 (de)
WO (1) WO2017102295A1 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3534282A1 (de) * 2018-03-01 2019-09-04 Siemens Aktiengesellschaft Verfahren und sicherheitsmodul zum rechnergestützten ausführen von programmcode
EP3561709B1 (de) * 2018-04-25 2020-07-29 Siemens Aktiengesellschaft Datenverarbeitungsvorrichtung, system und verfahren zum nachweis oder zur überprüfung der sicherheit einer datenverarbeitungsvorrichtung
EP3699803A1 (de) * 2019-02-21 2020-08-26 Siemens Aktiengesellschaft Schlüsselverwaltung in einer integrierten schaltung
KR20220100669A (ko) * 2020-01-16 2022-07-15 지티이 코포레이션 서비스 애플리케이션과의 암호화된 통신을 위해 통신 네트워크에서의 애플리케이션 키 생성 및 관리를 위한 방법, 디바이스 및 시스템
US20230020841A1 (en) * 2020-02-27 2023-01-19 Google Llc Secure Element that Leverages External Resources

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5737760A (en) * 1995-10-06 1998-04-07 Motorola Inc. Microcontroller with security logic circuit which prevents reading of internal memory by external program
US7322042B2 (en) * 2003-02-07 2008-01-22 Broadon Communications Corp. Secure and backward-compatible processor and secure software execution thereon
CA2516568C (en) * 2003-02-28 2011-04-26 Research In Motion Limited System and method of protecting data on a communication device
US7774619B2 (en) * 2004-11-17 2010-08-10 Broadcom Corporation Secure code execution using external memory
US8478973B2 (en) * 2008-05-30 2013-07-02 Infineon Technologies Ag System and method for providing a secure application fragmentation environment
EP2420079A1 (de) * 2009-04-15 2012-02-22 Interdigital Patent Holdings, Inc. Validierung und/oder authentifikation einer einrichtung zur kommunikation mit einem netzwerk
US8819848B2 (en) * 2009-11-24 2014-08-26 Comcast Interactive Media, Llc Method for scalable access control decisions
US20120030547A1 (en) * 2010-07-27 2012-02-02 Carefusion 303, Inc. System and method for saving battery power in a vital-signs monitor
WO2013004854A2 (en) * 2012-09-26 2013-01-10 Nxp B.V. Processing system
CN103049694A (zh) * 2013-01-14 2013-04-17 上海慧银信息科技有限公司 一种智能金融交易终端的核心安全架构实现方法
GB2512376A (en) * 2013-03-28 2014-10-01 Ibm Secure execution of software modules on a computer
WO2015171549A2 (en) * 2014-05-05 2015-11-12 Citrix Systems, Inc. Facilitating communication between mobile applications

Also Published As

Publication number Publication date
DE102015225270A1 (de) 2017-06-22
US20180365411A1 (en) 2018-12-20
WO2017102295A1 (de) 2017-06-22
CN108369623A (zh) 2018-08-03

Similar Documents

Publication Publication Date Title
EP2899714B1 (de) Gesichertes Bereitstellen eines Schlüssels
EP3437012B1 (de) Verfahren, prozessor und gerät zur integritätsprüfung von nutzerdaten
DE102009013384B4 (de) System und Verfahren zur Bereitstellung einer sicheren Anwendungsfragmentierungsumgebung
DE102013105042A1 (de) Sicheres Flashprogrammieren eines sekundären Prozessors
WO2017102295A1 (de) Verfahren und sicherheitsmodul zum bereitstellen einer sicherheitsfunktion für ein gerät
DE102012110559A1 (de) Verfahren und Vorrichtung zum sicheren Herunterladen einer Firmware unter Verwendung eines Diagnoselinkconnectors (DLC) und dem Onstar-System
DE102012109619A1 (de) Verfahren zum Bereitstellen einer digitalen Signatur zum Sichern einer Flash-Programmierfunktion
DE102015209116A1 (de) Verfahren und Aktualisierungsgateway zum Aktualisieren eines eingebetteten Steuergerätes
DE102013108021A1 (de) Verfahren zum selektiven Software-Rollback
EP3136285B1 (de) Verfahren und speichermodul für sicherheitsgeschützte schreibvorgänge und/oder lesevorgänge auf dem speichermodul
DE102015209108A1 (de) Verfahren und Entscheidungsgateway zum Autorisieren einer Funktion eines eingebetteten Steuergerätes
DE102012109615B4 (de) Verwendung eines Manifests zur Präsenzaufzeichnung von gültiger Software und Kalibrierung
WO2019081395A1 (de) Verfahren und vorrichtung zum aktualisieren von software eines kfz-steuergerätes
DE102013108022A1 (de) Verfahren zum Aktivieren des Entwicklungsmodus eines gesicherten elektronischen Steuergeräts
EP2494526A1 (de) Verfahren zum betreiben eines tachographen und tachograph
DE102013013179A1 (de) Verfahren zum Betreiben eines Sicherheitselements
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
EP3403214B1 (de) Verfahren und einrichtung zum bereitstellen einer kryptographischen sicherheitsfunktion für den betrieb eines geräts
EP3811260B1 (de) Kryptografiemodul und betriebsverfahren hierfür
DE102018217431A1 (de) Sicherer Schlüsseltausch auf einem Gerät, insbesondere einem eingebetteten Gerät
DE102020117552A1 (de) Sichere hybrid-boot-systeme und sichere boot-verfahren für hybridsysteme
WO2024056443A1 (de) Verfahren zum überprüfen von daten in einer recheneinheit
DE102012021719A1 (de) Übermittlung von Datenelementen von einem entfernten Server an einen Endgeräte Chip
DE102020206039A1 (de) Erstellen einer Container-Instanz
EP3595256A1 (de) Vorrichtung und verfahren zum betreiben einer durch software gestalteten verarbeitungseinheit für ein gerät

Legal Events

Date Code Title Description
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

17P Request for examination filed

Effective date: 20180529

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)
17Q First examination report despatched

Effective date: 20190513

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20190924