WO2014023431A1 - Verfahren zum erzeugen von ausf?hrbarem programmcode - Google Patents

Verfahren zum erzeugen von ausf?hrbarem programmcode Download PDF

Info

Publication number
WO2014023431A1
WO2014023431A1 PCT/EP2013/002387 EP2013002387W WO2014023431A1 WO 2014023431 A1 WO2014023431 A1 WO 2014023431A1 EP 2013002387 W EP2013002387 W EP 2013002387W WO 2014023431 A1 WO2014023431 A1 WO 2014023431A1
Authority
WO
WIPO (PCT)
Prior art keywords
program code
executable
security module
portions
concurrently
Prior art date
Application number
PCT/EP2013/002387
Other languages
English (en)
French (fr)
Inventor
Michael Baldischweiler
Thomas Stocker
Original Assignee
Giesecke & Devrient Gmbh
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 Giesecke & Devrient Gmbh filed Critical Giesecke & Devrient Gmbh
Publication of WO2014023431A1 publication Critical patent/WO2014023431A1/de

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/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • 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/75—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 by inhibiting the analysis of circuitry or operation
    • G06F21/755—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 by inhibiting the analysis of circuitry or operation with measures against power attack
    • 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/77—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 in smart cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/45—Exploiting coarse grain parallelism in compilation, i.e. parallelism between groups of instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033—Test or assess software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2153—Using hardware token as a secondary aspect

Definitions

  • the present invention relates to a method for generating program code executable on a security module and to a set of corresponding security modules for executing the program code.
  • executable program code is to be construed broadly to include any form of program code that may be executed or interpreted by processors, interpreters, virtual machines, or the like. In this respect, this is to be understood as program code which is coded according to a so-called intermediate code.
  • an intermediate code is understood to be a code in a language which is arranged conceptually between a code of a source text of a high-level language, for example "Java", "C” or the like, on the one hand and a machine-oriented target language, in particular a machine code, on the other hand is.
  • Intermediate code can be generated by a compiler as part of a translation (compilation) of a source code to machine code as an intermediate result.
  • a well-known example of such an intermediate code is the so-called "3-address code.”
  • Various interpreters are known for executing this code
  • Other known examples of executable intermediate code which are executed by a corresponding compiler mainly for platform-independent execution by a "virtual address”.
  • processor such as a virtual machine, are generated, so-called bytecodes, such as Java or Java Card TM bytecode.
  • "executable program code” in the present case can also be understood as program code which is coded according to a machine-oriented target language, in particular in machine code .
  • This program code can then be executed directly by a hardware processor of the security module.
  • the nature of the attacks is manifold, ranging from, for example, merely listening to a data communication connection between such a security module and a terminal via the evaluation of the security card Resource consumption of the security module when performing a calculation, for example, the power consumption or the computing time, to technically very complex attacks specifically disturbed by the fact that by external action on the security module, for example by means of targeted light flashes on individual memory cells of a memory of the security module, input data or intermediate results of a calculation to be manipulated based on the resulting manipulated results stored in the security module sensitive data, crizspielswei - se encryption key to close.
  • security module is based on an identical product line architecture from various application areas, for example from the fields of telecommunications, banking, PayTV, etc.
  • security modules then have the same physical behavior with regard to the execution of identical program code, for example parts of the operating system, so that a successful attack on a security module from an application area, for example a credit card, has a negative impact on the security of a security module a completely different area, for example a SIM card.
  • the object of the present invention is to protect security modules with executable program code against external attacks.
  • the effects of a successful attack on a security module for other, identical security modules should be limited.
  • a source code underlying the program code preferably in a high level language such as "C", "Java” or the like.
  • concurrently executable portions of the operations defined by the source code are determined.
  • These shares can already be determined at the level of the source code. However, it is also possible that this step takes place only at the level of an intermediate code between the source code and the executable program code or only at the level of the executable program code.
  • concurrently executable portions, with respect to the same program code to be generated can also be determined at different ones of these levels. That the determination of the shares may be performed at different times and in different phases of a translation of the source code into executable program code.
  • executable program code is generated from the source code.
  • executable program code portions corresponding to previously determined concurrently executable portions are arranged for specific security module specifics for sequential executability of the generated program code.
  • Such an arrangement of the executable program code portions determines the order in which the shares are executed in a sequential execution of the thus generated program code, and thus the runtime behavior of the functionality provided by the executable program code. It goes without saying that this arrangement takes place in such a way that the overall functionality provided by the generated executable program code is not impaired and is identical for each of the possible, producible, security module-specific arrangements.
  • each generated program code is security module specific, i. group-specific or even security module-individual
  • a security module of a first group when executing the executable program code generated for this first group shows a different runtime behavior than a security module of a second group when executing the functionally identical, but with respect to the observable runtime behavior, generated for this second group deviating - executable program codes.
  • the term "concurrently executable” means those portions of the operations defined by the source code which have no causal relation to each other in pairs a calculation performed by program code portions corresponding to a first portion of results of a calculation made by program code portions corresponding to a second portion is directly or indirectly dependent or influenced. Two parts, for example two transactions, processes or threads, are thus concurrently executable or parallelizable if a time-parallel execution, a geared execution or a sequential execution in a changed order leads to the same result as a sequential execution according to a predetermined order ,
  • concurrently executable shares there may be shares that are in a sense “globally" concurrently executable, ie, shares that are not causally related to any other portion of the operations defined by the source code, but in general, the term “concurrency” is used as a relative term in the Must be understood that a predetermined amount of shares, in pairs and relative to each other, concurrently, ie for example, temporally parallel or in a modified order, can be executed. This, however, does not say anything about whether, and if so, what causal relationship between one or more of these shares is to other shares not belonging to the corresponding predetermined number of shares.
  • concurrently executable shares may also occur in an interleaved manner, for example in the case of a set of concurrently executable shares comprising one or more shares, which in turn consist of concurrently executable sub-shares.
  • the general formulation "determination of co-executable units” thus encompasses any of these types of units that can be executed globally and / or relative to other units
  • Program code shares corresponding to the calculated, concurrently executable shares, the nature and extent of the concurrent executability are observed. That is, a rearrangement of an executable program code portion in the generated program code for the subsequent sequential executable only takes place relative to the corresponding program code portions concurrently executable with respect to this executable program code portion.
  • the executable program code portions corresponding to concurrently executable portions are randomized for sequential executability of the generated program code. This makes it possible to generate security module-specific, executable program code in a very simple and unforeseeable manner for an attacker. However, it is also possible for the arrangement to be deterministic or for a safety-module-specific arrangement to include both deterministic and random elements.
  • Proportions correspond to the effect that a safety-module-specific runtime behavior manifests itself in the case of a sequential execution of the program code on the safety module. Observations and analyzes of an attacker regarding the resource consumption of a security module, which can be observed when executing a functionality provided by the executable program code generated according to the invention, for example with regard to runtime or power consumption, are thus also security module-specific and not specific to other security systems. modules or other groups of security modules that comprise the same functionality.
  • a further advantageous technical effect of the invention which ensures the security of a security module of a first group even in the case of a successful attack on a security module of another group, is the fact that a described, security module-specific arrangement of executable program code portions, which concurrently executable portions When storing the program code in a non-volatile memory of the security module usually results in a security module-specific memory image.
  • This can be drawn from a successful attack on a functionality of a security module, which is done by targeted manipulation of individual memory cells, no advantage for a corresponding attack on another security module with the same functionality, since there the corresponding memory cells in the rule, as a result according to the invention security module specific arrangement of the portions of the functionality providing executable program code, are occupied differently.
  • a number of concurrent shares may be specified.
  • This number of concurrently or concurrently executable portions would be equivalent if program code were to be generated for execution on a multi-core or multiprocessor architecture, for example, the number of cores or processors available there. The larger this number is selected or specified, the greater the number of possible arrangements of corresponding components for a sequential execution of the program code to be generated.
  • Those executable program code portions that correspond to determined concurrently executable portions may be arranged in a table when the executable program code is generated. In this case, the arrangement within the table can be carried out directly in a security-specific, preferably randomized, manner.
  • concurrently executable portions of the operations defined by the provided source code can be determined in a general manner, even from a program code already applied for a sequential execution.
  • some known program structures are particularly suitable for parallelization, such as loops. That is, as concurrently executable portions of the operations defined by the source code, portions defining a loop operation may preferably be determined.
  • i ⁇ ⁇
  • a suitable recursion defining shares This is especially true if in a call for
  • At least one of the executable program code portions corresponding to a concurrently executable portion may be optimized in the step of generating the executable program code with respect to at least one predetermined parameter.
  • Preferred parameters are, for example, runtime and / or memory requirements. This optimization may be done before or after the security module specific arrangement with respect to the other executable program code portions, which also correspond to concurrently executable portions. The optimization can continue to take place in one or more different phases of a translation process from the source code to the executable program code, that is, for example, already at the level of an intermediate code.
  • the generated executable program code as compared to a corresponding program code without optimization, also be designed security module specific. Optimization with regard to runtime, even if it only affects individual subfunctions, alters the runtime behavior of the overall functionality provided by the generated, executable program code.
  • a - even partial - optimization in terms of memory requirements affects the entire memory image.
  • Such optimization may also affect the handling of local variables in the area of the optimized, executable program code portions, and thus, for example, the occupancy of a stack, various processor registers or other memory areas, for example in the main memory of the processor during runtime.
  • various of the executable program code portions corresponding to concurrently executable portions are each optimized for different parameters. In this way, there are many other possibilities for the security-module-specific generation of the executable program code.
  • the step of determining concurrently executable portions of the operations defined by the source code is performed by a device or at least supported by such a device which is capable of generating program code executable in parallel on a multi-core and / or multi-processor architecture is set up.
  • a device can intervene or act on different levels, for example in the form of compile diodes which can be inserted into the source code or, if the source code is unchanged, by functionalities of the compiler itself.
  • Such an already existing, known device for example a compiler for generating parallel executable program code, is "misappropriated" according to the invention by using program code generated by this device and executable in parallel on a multiprocessor architecture as an intermediate result
  • the determination of concurrently executable shares will be carried out entirely by this institution and, as a rule, additionally configurable.
  • Each security module of a security module set comprises a memory and a processor for executing executable program code stored in the memory.
  • the inventive set of security modules comprises at least two groups of security modules, each of these groups comprising at least one security module.
  • the executable program code stored in a memory of a security module of the set of security modules is identical in terms of functionality for each security module of the set of security modules, but differs in terms of its runtime behavior for two security modules from different groups of security module groups.
  • a security module-specific, ie group or security module-specific runtime behavior of a functionality provided by the executable program code ensures the security of a security module of a group also with regard to on a successful attack on a security module of another group.
  • the different runtime behavior of the program code for two security modules from different groups is based in particular on the fact that the program code of a security module of a first group differs from the program code of a security module of a second group in that the executable code is generated for the security modules executable program code portions corresponding concurrently executable shares have been arranged for a sequential executability of the executable program code by the processor of the respective security module group specific.
  • a security module-specific memory image will continue to result in a non-volatile memory of the security module.
  • the present system for generating executable program code comprises a specially adapted tool for generating the sequentially executable program code for a source code and a tool for determining concurrently executable portions.
  • the generation tool is configured to provide the concurrently executable program code portions for sequential execution on the security module determined by the discovery tool.
  • a multiprocessor tool can be used for the determination.
  • the production tool is a monoprocessor tool.
  • the discovery tool may prepare the determined concurrently executable program code portions for the concurrent execution.
  • the processing supplements in particular the necessary for a concurrent execution operations (instructions), for example, each processor or program code portion to provide the (at least partly the same) required values (variables, pointers ).
  • a security module is preferably a hardware security module.
  • the security module may be a portable data carrier, such as a smart card, a USB token, an RFID token or a secure mass storage card.
  • the security module can be reversibly connected to a terminal or permanently installed in a terminal, such as a built-in SIM module (eUICC), a TPM module or NFC module.
  • FIG. 1 shows a preferred embodiment of a data carrier from a
  • FIG. 2 shows a preferred embodiment of a method according to the invention for generating executable program codes
  • FIGS. 3A to 3E results of individual partial steps of method steps from FIG. 2 and FIG. 4 the set of data carriers, subdivided into individual groups, with the data carrier from FIG. 1 as element of a group.
  • a data carrier 10 as a security module which is shown here as a chip card, comprises data communication interfaces 20, 20 ', a processor 30 and various memory 40, 50 and 60.
  • the disk 10 may also be in a different design.
  • the data carrier 10 comprises a contact field 20 for contact-type data communication and an antenna coil 20' for contactless data communication.
  • Alternative data communication interfaces may be provided. It is also possible that the data carrier 10 only supports one type of data communication, that is, only contact-based or contactless.
  • the nonvolatile, non-rewritable ROM 40 includes an operating system (OS) 42 of the volume 10 that controls the volume 10. At least portions of the operating system 42 may also be stored in the nonvolatile rewriteable memory 50. This can be present for example as FLASH memory.
  • OS operating system
  • FLASH memory FLASH memory
  • the memory 50 comprises data carrier-specific, executable program code 52, which has been generated as described below with reference to FIGS. 2 to 3D.
  • the volatile, rewritable RAM 60 serves the disk 10 as a working memory.
  • Additional data carriers 10 ", 10 '" of a set 100 of data carriers, subdivided into different groups 101, 102, 103, are present.
  • Data carriers within a group are identical with regard to the components described.
  • Data carriers 10, 10 ", 10"'of different groups 101, 102, 103 differ in that the functionality which is provided by the executable program code 52, 52 ", 52'" (compare FIGS. 3C, 3E) is provided, each having a group-specific runtime behavior and optionally leads to a group-specific memory image in a nonvolatile memory of the respective data carrier.
  • the functionality provided by the program code 52, 52 ', 52 ", 52'” is identical for all data carriers 10, 10 ", 10"'of the set 100 of data carriers, irrespective of the group membership 101, 102, 103.
  • step S1 a source code is provided.
  • This source code defines those operations which must be performed to provide the desired functionality.
  • the source code is usually in a high-level language, for example in "C”, “Java” or the like.
  • step S2 concurrently executable portions of the operations defined by the source code are determined.
  • Executable program code 52 is generated in step S3, wherein sub-step TS31 concurrently executable shares, as described below, volume-specific, are arranged.
  • This sub-step TS31 can take place before the generation of those executable program code parts which correspond to the shares determined to be concurrently executable, or else afterwards.
  • step S4 individual components determined as concurrently executable and / or the associated, generated, executable program code portions can be optimized according to various criteria. The optimization can already during, ie in the context of the translation process, so when generating the executable program code, done before, for example, finally executable machine code is generated.
  • FIGS. 3A to 3C One possible procedure for determining concurrently executable components and for arranging the corresponding program code components is outlined in FIGS. 3A to 3C.
  • a source code sequence which, for example, a loop operation encoded and can be decomposed into concurrently executable shares, is in this sense with the translated into the intermediate code sequence or equates to the piece of executable machine code that encodes this looping operation for the processor.
  • the calculation of the concurrently executable shares is usually carried out as part of a translation or compilation of the source code into the executable program code.
  • a translation proceeds in a known manner in different sub-steps. These may include the steps of lexical analysis, parsing, semantic analysis, intermediate code generation, code optimization, and code generation. Phases which may mainly concern the determination of the concurrently executable portions are, for example, the syntax analysis in which hierarchical structures of the program are recognized.
  • concurrently executable portions may be determined during the generation of intermediate code, in which the results of the preceding steps used to analyze the source code are converted into a "Abstract machine language", a suitable intermediate code, such as the 3-address code, are translated, from which the actual machine code for the present platform is subsequently generated, but it is also possible that concurrently executable portions, at least coarsely, already determined at the level of the source code, ie before the translation, or only at the level of the machine code, ie at the end of the translation Finally, various concurrently executable portions may be determined in different phases described above or in more than one phase ,
  • a first substep during the establishment of concurrently executable portions illustrated in FIG. 3A may involve a decomposition of the program code, at an appropriate level of the program code 51, into blocks.
  • Each of these blocks A to G each comprises a sequence of instructions which, when the block is reached, must be executed before the block is exited again.
  • the order in which each of the blocks can be executed may vary without affecting the end result.
  • statements within a block can be executed in different order, without any change in the result of the calculation.
  • blocks A through G need not necessarily be executed in the order indicated in FIG. 3A. Rather, it turns out that after the instructions of block A have been executed, blocks B, C and D can be executed in parallel, interleaved or in any sequential order before the program continues with block E. In other words, there is no causal between the shares of blocks B, C and D. None of these blocks requires an input which could depend, directly or indirectly, on an output of one of the other blocks. Therefore, these blocks can be determined to be executable concurrently with each other. The same applies to the sub-components F1, F2,..., Fk of the component according to block F.
  • executable program code for a multiprocessor architecture for example with three processors
  • executable program code would be generated for each of the three blocks B, C and D, which could then be executed in parallel on a respective one of the three processors.
  • parallel executable program code for one of the three processors could be generated for the sub-components F1, F2, Fk.
  • sequentially executable program code for a data carrier 10 with only one processor can be generated, as illustrated in FIG. 3C.
  • the program code portions which correspond to the proportions B, C and D or Fl, F2, Fk, respectively determined to be concurrently executable have been rearranged in a random order for a sequential execution. Due to the fact that these components can be executed in parallel, ie have no causal relationship to one another, the functionality of the overall program remains identical regardless of the order in which the arrangement takes place. The fact that the arrangement is randomized, in particular results in a data carrier-specific arrangement.
  • executable program code for a multiprocessor architecture is not first generated, as described with reference to the first variant, which first has to be decomposed and rearranged in a described manner in order to generate a sequentially executable version.
  • the random arrangement of the concurrently executable components takes place here on a plane above the machine code, for example at the level of the mentioned intermediate code.
  • Executable program code 52 is then generated only for sequential execution, the program code portions corresponding to the concurrently executable portions B, C, D or Fl, F2,..., Fk being arranged again in a volume-specific manner as shown in FIG. 3C.
  • the results, ie the generated program code 52, the first and the second variant essentially correspond to one another. Slight differences may arise in that, for example, program code generated for a truly parallel execution on a multiprocessor architecture includes additional code, for example, for multiple initialization of individual variables for each of the branches to be executed in parallel. This code can be dispensed with in the version created directly for sequential execution. In this respect, each results in a different memory image. With regard to the runtime behavior, however, practically no discernible differences are to be expected.
  • the functionality for determining concurrently executable components is provided by a suitably configured compiler, in particular by a compiler which is set up to generate program code which can be executed in real parallel fashion on a multiprocessor architecture.
  • the method described for generating the sequentially executable, volume-specific program code makes use of such a compiler or a comparable device. It can further be provided that, alternatively or additionally, shares can already be specified at the level of the source code, which can be executed concurrently. This can be done, for example, by means of suitable compiler directives which are suitably inserted into the program code, as they are known, for example, in connection with the programming interface "OpenMP.” By means of such directives, the compiler can be informed, for example, that it is basically intended to be sequentially executable Shares, so-called “sections", for example, the above-mentioned proportions B, C and D, can be carried out in parallel. It is up to the programmer to check the conditions of concurrent feasibility.
  • Such directives such program code sequences, which are known to be able to execute their instructions in a simple manner in parallel, are displayed to the compiler.
  • Particularly suitable are loop constructions in which the individual loop passes with respect to input and output data are independent of one another. This situation is indicated in FIGS. 3A and 3B with the block F and the sub-parts F1, F2,..., Fk.
  • one or more of the shares determined as concurrently executable can be optimized with respect to one or more parameters, for example the proportions C and B, whereby the optimized components C and B emphasized in different hatched form
  • Known compilers usually have corresponding compile options which, for example, allow program code to be optimized in several stages with regard to execution speed or memory requirement, since not all of the program code is uniformly optimized, but only selected portions Further optimization of the program code 52 'generated in this way can be achieved suitable, generate optimized intermediate code.
  • Executable program code is then first generated by a linker functionality. In this way, an optimization can be carried out, which does not concern only individual modules, but an entire program package.
  • An executable, data carrier-specific program code 52 "generated for a data carrier 10" differs from the program code 52 'generated for the data carrier 10, in that the program code portions corresponding to the concurrently executable portions B, C, D and F1, F2, Fk are designed according to a different version Order have been arranged.
  • the program code portion C has been optimized with respect to another parameter (eg, runtime instead of memory requirement). It is immediately obvious that the runtime behavior of the program code 52 "of the data carrier 10" is different from the runtime behavior of the program code 52 'of the data carrier 10.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

In einem Verfahren zum Erzeugen eines auf einem portablen Datenträger ausführbaren Programmcodes wird in einem ersten Schritt (Sl) ein dem Programmcode (52) zugrunde liegender Quellcode bereitgestellt. Dann werden nebenläufig ausführbare Anteile (B, C, D) der durch den Quellcode definierten Operationen ermittelt (S2). In einem weiteren Schritt (S3) wird ausführbarer Programmcode aus dem Quellcode erzeugt. Dabei werden solche ausführbaren Programmcodeanteile, die zuvor ermittelten, nebenläufig ausführbaren Anteilen (B, C, D) entsprechen, für eine sequenzielle Ausführbarkeit des erzeugten Programmcodes (52) Sicherheitsmodulspezifisch, vorzugsweise randomisiert, angeordnet (TS31).

Description

Verfahren zum Erzeugen von ausführbarem Programmcode
Die vorliegende Erfindung betrifft ein Verfahren zum Erzeugen von auf einem Sicherheitsmodul ausführbarem Programmcode sowie eine Menge entsprechender Sicherheitsmodule zum Ausführen des Programmcodes. Im Zusammenhang mit der vorliegenden Erfindung ist der Begriff des ausführbaren Programmcodes derart breit auszulegen, dass jedwede Form von Programmcode darunterfällt, der von Prozessoren, Interpretern, virtuellen Maschinen oder dergleichen ausgeführt bzw. interpretiert werden kann. Insofern ist darunter Programmcode zu verstehen, welcher gemäß einem so genannten Zwischencode codiert ist. Als Zwischencode wird vorliegend ein Code in einer Sprache verstanden, welche konzeptionell zwischen einem Code eines Quelltextes einer Hochsprache, beispielsweise„Java",„C" oder dergleichen, auf der einen Seite und einer maschinennahen Zielsprache, insbesondere einem Maschinencode, auf der anderen Seite angeordnet ist.
Zwischencode kann von einem Compiler beispielsweise im Rahmen einer Übersetzung (Compilierung) eines Quelltextes hin zu Maschinencode als Zwischenergebnis erzeugt werden. Bekanntes Beispiel eines solchen Zwischencodes ist der so genannte„3-Adress-Code". Zum Ausführen dieses Codes sind verschiedene Interpreter bekannt. Weitere bekannte Beispiele für ausführbaren Zwischencode, welcher von einem entsprechenden Compiler vorwiegend zum plattformunabhängigen Ausführen durch einen„virtuel- len" Prozessor, beispielsweise eine Virtuellen Maschine, erzeugt wird, sind so genannte Bytecodes, wie z.B. Java- oder Java Card™-Bytecode.
Anderseits kann unter„ausführbarem Programmcode" vorliegend auch Programmcode verstanden werden, welcher gemäß einer maschinennahen Zielsprache, insbesondere in Maschinencode, codiert ist. Programmcode dieser Art kann dann direkt von einem Hardware-Prozessor des Sicherheitsmoduls ausgeführt werden. In neuerer Zeit stellen Angriffe auf Sicherheitsmodule, insbesondere Chipkarten, ein erhöhtes Sicherheitsrisiko sowohl für den individuellen Nutzer des Sicherheitsmoduls als auch für einen Hersteller der Sicherheitsmodule dar. Die Art der Angriffe ist mannigfaltig. Sie reicht beispielsweise von bloßem Abhören einer Datenkommunikationsverbindung zwischen einem sol- chen Sicherheitsmodul und einem Endgerät über das Auswerten des Ressourcenverbrauchs des Sicherheitsmoduls beim Durchführen einer Berechnung, beispielsweise des Stromverbrauchs oder der Rechenzeit, bis hin zu technisch sehr aufwendigen Angriffen. Dabei werden beispielsweise Berechnungen des Prozessors des Sicherheitsmoduls gezielt dadurch gestört, dass mittels externen Einwirkens auf das Sicherheitsmodul, beispielsweise mittels gezielter Lichtblitze auf einzelne Speicherzellen eines Speichers des Sicherheitsmoduls, Eingabedaten oder Zwischenergebnisse einer Berechnung manipuliert werden, um anhand der dadurch erhaltenen, manipulierten Ergebnisse auf in dem Sicherheitsmodul gespeicherte sensible Daten, beispielswei- se Verschlüsselungsschlüssel, zurückzuschließen.
Aus Sicht des individuellen Nutzers können bei einem solchen Angriff persönliche oder sonstige sensible Daten, beispielsweise geheime Schlüssel, ausgespäht werden. Für einen Hersteller der Sicherheitsmodule kann bereits ein erfolgreicher Angriff auf ein Sicherheitsmodul einer Serie baugleicher Sicherheitsmodule, neben dem Imageverlust, einen erheblichen Schaden bedeuten, da dann möglicherweise die ganze Serie von Sicherheitsmodulen als kompromittiert angesehen und daher zurückgerufen oder ersetzt werden muss.
Dies kann für einen Hersteller auch in dem Fall problematisch sein, in dem Sicherheitsmodul aus an sich verschiedenen Anwendungsbereichen, beispielsweise aus den Bereichen Telekommunikation, Banking, PayTV, etc., auf einer identischen Produktlinienarchitektur beruhen. Solche Sicherheitsmodule haben dann hinsichtlich der Ausführung von jeweils identisch darin vorliegendem Programmcode, beispielsweise von Teilen des Betriebssystems, dasselbe physikalische Verhalten, so dass ein erfolgreicher Angriff auf ein Sicherheitsmodul aus einem Anwendungsbereich, beispielsweise eine Kre- ditkarte, negative Auswirkungen auf die Sicherheit eines Sicherheitsmoduls aus einem ganz anderen Bereich, beispielsweise eine SIM-Karte, haben kann.
Aufgabe der vorliegenden Erfindung ist es, Sicherheitsmodule mit darauf ausführbarem Programmcode gegen externe Angriffe zu schützen. Insbe- sondere sollen die Auswirkungen, welche ein erfolgreicher Angriff auf einen Sicherheitsmodul für andere, baugleiche Sicherheitsmodule hat, begrenzt werden.
Diese Aufgabe wird durch ein Verfahren und eine Menge von Sicherheits- modulen mit den Merkmalen der unabhängigen Ansprüche gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen sind in den abhängigen Ansprüchen angegeben. Die vorliegende Erfindung basiert auf der Grundidee, für ein individuelles Sicherheitsmodul oder für Gruppen von Sicherheitsmodulen jeweils einen sicherheitsmodulspezifischen, d.h. Sicherheitsmodul- oder gruppenindividuellen ausführbaren Programmcode in der folgenden Weise zu erzeugen:
In einem ersten Schritt wird ein dem Programmcode zugrunde liegender Quellcode, vorzugsweise in einer Hochsprache, wie z.B.„C",„Java" oder dergleichen, bereitgestellt. Dann werden nebenläufig ausführbare Anteile der durch den Quellcode definierten Operationen ermittelt. Diese Anteile können dabei bereits auf der Ebene des Quellcodes ermittelt werden. Es ist aber auch möglich, dass dieser Schritt erst auf der Ebene eines Zwischencodes zwischen dem Quellcode und dem ausführbaren Programmcode oder erst auf der Ebene des ausführbaren Programmcodes stattfindet. Schließlich können nebenläufig ausführbare Anteile, mit Bezug auf denselben zu erzeugenden Programmcode, auch auf verschiedenen dieser Ebenen ermittelt werden. D.h. das Ermitteln der Anteile kann zu verschiedenen Zeitpunkten und in verschiedenen Phasen einer Übersetzung des Quellcodes zu ausführbarem Programmcode durchgeführt werden.
In einem weiteren Schritt wird ausführbarer Programmcode aus dem Quellcode erzeugt. Erfindungsgemäß werden im Schritt des Erzeugens des ausführbaren Programmcodes ausführbare Programmcodeanteile, die zuvor ermittelten, nebenläufig ausführbaren Anteilen entsprechen, für eine sequenzielle Ausführbarkeit des erzeugten Programmcodes sicherheitsmodulspezifisch angeordnet. Eine solche Anordnung der ausführbaren Programmcodeanteile bestimmt die Reihenfolge, in der die Anteile bei einer sequentiellen Ausführung des derart erzeugten Programmcodes ausgeführt werden, mithin das Laufzeit- verhalten der durch den ausführbaren Programmcode bereitgestellten Funktionalität. Es versteht sich, dass diese Anordnung dabei derart erfolgt, dass die Gesamtfunktionalität, welche durch den erzeugten, ausführbaren Programmcode bereitgestellt wird, nicht beeinträchtig wird und für jede der möglichen, erzeugbaren, sicherheitsmodulspezifischen Anordnungen iden- tisch ist.
Da jeder erzeugte Programmcode sicherheitsmodulspezifisch ist, d.h. gruppenspezifisch oder sogar sicherheitsmodulindividuell, zeigt ein Sicherheitsmodul einer ersten Gruppe beim Ausführen des für diese erste Gruppe er- zeugten, ausführbaren Programmcodes ein anderes Laufzeitverhalten als ein Sicherheitsmodul einer zweiten Gruppe beim Ausführen des für diese zweite Gruppe erzeugten - funktional identischen, aber bezüglich des beobachtbaren Laufzeitverhaltens abweichenden - ausführbaren Programmcodes. Auf diese Weise werden die jeweiligen Sicherheitsmodule gegen externe
Angriffe geschützt. Insbesondere kann ein Angreifer aus einem erfolgreichen Angriff auf ein Sicherheitsmodul der ersten Gruppe in der Regel keine Informationen gewinnen, welche für Angriffe auf Sicherheitsmodule der zweiten Gruppe nützlich sein könnten.
Als„nebenläufig ausführbar" werden im Zusammenhang mit der vorliegenden Erfindung solche Anteile der durch den Quellcode definierten Operationen verstanden, die paarweise keine kausale Beziehung zueinander aufweisen. Eine solche kausale Beziehung könnte insbesondere darin bestehen, dass eine Berechnung, welche durch Programmcodeanteile entsprechend einem ersten Anteil durchgeführt wird, von Ergebnissen einer Berechnung, welche durch Programmcodeanteile entsprechend einem zweiten Anteil erfolgt, direkt oder indirekt abhängt oder beeinflusst wird. Zwei Anteile, beispielswei- se zwei Transaktionen, Prozesse oder Threads, sind somit genau dann nebenläufig ausführbar oder parallelisierbar, wenn eine zeitlich parallele Ausführung, eine verzahnte Ausführung oder eine sequentielle Ausführung in geänderter Reihenfolge zu demselben Resultat führt wie ein sequentielles Ausführen gemäß einer vorgegebenen Reihenfolge.
Dabei kann es Anteile geben, die in gewissem Sinne„global" nebenläufig ausführbar sind, d.h. Anteile, die zu keinem anderen Anteil der durch den Quellcode definierten Operationen kausal in Beziehung stehen. Im Allgemeinen aber wird der Begriff„Nebenläufigkeit" als relativer Begriff in dem Sinne verstanden werden müssen, dass eine vorgegebene Menge von Anteilen, paarweise und relativ zueinander, nebenläufig, d.h. beispielweise zeitlich parallel oder in abgeänderter Reihenfolge, ausgeführt werden können. Dies sagt dann allerdings nichts darüber aus, ob, und wenn ja, welche kausale Beziehung zwischen einem oder mehreren dieser Anteile zu anderen, nicht zu der entsprechenden, vorgegebenen Menge von Anteilen gehörenden Anteilen bestehen. Schließlich können nebenläufig ausführbare Anteile auch in verschachtelter Weise auftreten, beispielweise im Falle einer Menge nebenläufig ausführbarer Anteile, die einen oder mehrere Anteile umfassen, welche ihrerseits aus nebenläufig ausführbaren Unteranteilen bestehen.
Die allgemeine Formulierung„Ermitteln von nebenläufig ausführbaren Anteilen" umfasst somit jede dieser Arten von global und/ oder relativ zu anderen Anteilen nebenläufig ausführbaren Anteilen. In gleicher Weise gilt, dass im Schritt des sicherheitsmodulspezif ischen Anordnens von ausführbaren Programmcodeanteilen, die den ermittelten, nebenläufig ausführbaren Anteilen entsprechen, die Art und der Umfang der nebenläufigen Ausführbarkeit beachtet werden. D.h. eine Neuanordnung eines ausführbaren Programmcodeanteils im erzeugten Programmcode zur nachfolgenden sequen- tiellen Ausführbarkeit erfolgt lediglich stets relativ zu den entsprechenden, mit Bezug auf diesen ausführbaren Programmcodeanteil nebenläufig ausführbaren Programmcodeanteilen.
Gemäß einer bevorzugten Ausführungsform des vorstehend beschriebenen Verfahrens werden die ausführbaren Programmcodeanteile, die nebenläufig ausführbaren Anteilen entsprechen, für eine sequenzielle Ausführbarkeit des erzeugten Programmcodes randomisiert angeordnet. Dies ermöglicht auf sehr einfache und für einen Angreifer nicht vorhersehbare Weise das Erzeugen von sicherheitsmodulspezifischem, ausführbarem Programmcode. Es ist allerdings auch möglich, dass das Anordnen deterministisch erfolgt oder dass eine Vorschrift zum sicherheitsmodulspezifischen Anordnen sowohl deterministische als auch zufällige Elemente umfasst.
Wie bereits erwähnt, hat ein sicherheitsmodulspezifisches Anordnen derje- nigen ausführbaren Programmcodeanteile, die nebenläufig ausführbaren
Anteilen entsprechen, die Auswirkung, dass sich bei einer sequentiellen Ausführung des Programmcodes auf dem Sicherheitsmodul ein sicherheitsmodulspezifisches Laufzeitverhalten zeigt. Beobachtungen und Analysen eines Angreifers hinsichtlich des Ressourcenverbrauchs eines Sicherheitsmoduls, welcher sich beim Ausführen einer durch den erfindungsgemäß erzeugten, ausführbaren Programmcode bereitgestellten Funktionalität beobachten lässt, beispielsweise hinsichtlich der Laufzeit oder des Stromverbrauchs, sind damit ebenfalls sicherheitsmodulspezifisch und nicht auf andere Sicher- heitsmodule oder andere Gruppen von Sicherheitsmodulen, welche dieselbe Funktionalität umfassen, übertragbar.
Ein weiterer vorteilhafter technischer Effekt der Erfindung, welcher die Si- cherheit eines Sicherheitsmoduls einer ersten Gruppe auch bei einem erfolgreichen Angriff auf ein Sicherheitsmodul einer anderen Gruppe gewährleistet, ist die Tatsache, dass eine beschriebene, sicherheitsmodulspezif ische Anordnung von ausführbaren Programmcodeanteilen, welche nebenläufig ausführbaren Anteilen entsprechen, beim Speichern des Programmcodes in ei- nem nichtflüchtigen Speicher des Sicherheitsmoduls in der Regel ein sicher- heitsmodulspezifisches Speicherabbild ergibt. Damit kann aus einem erfolgreichen Angriff auf eine Funktionalität eines Sicherheitsmoduls, welche durch gezielte Manipulation einzelner Speicherzellen erfolgt ist, kein Vorteil für einen entsprechenden Angriff auf ein weiteres Sicherheitsmodul mit der gleichen Funktionalität gezogen werden, da dort die entsprechenden Speicherzellen in der Regel, als Folge der erfindungsgemäßen Sicherheitsmodul- spezifischen Anordnung der Anteile des die Funktionalität bereitstellenden ausführbaren Programmcodes, abweichend belegt sind. Im Rahmen des Schritts des Ermitteins von nebenläufig ausführbaren Anteilen kann eine Anzahl von gleichzeitig nebenläufig ausführbaren Anteilen vorgegeben werden. Diese Anzahl von gleichzeitig nebenläufig oder parallel ausführbaren Anteilen entspräche, wenn Programmcode zum Ausführen auf einer Mehrkern- oder Mehrprozessorarchitektur erzeugt werden sollte, bei- spielsweise der Anzahl der dort bereitstehenden Kerne oder Prozessoren. Je größer diese Anzahl gewählt oder vorgegeben wird, desto großer ist die Anzahl von möglichen Anordnungen entsprechender Anteile für eine sequentielle Ausführung des zu erzeugenden Programmcodes. Diejenigen ausführbaren Programmcodeanteile, die ermittelten, nebenläufig ausführbaren Anteilen entsprechen, können beim Erzeugen des ausführbaren Programmcodes in einer Tabelle angeordnet werden. Dabei kann die Anordnung innerhalb der Tabelle direkt sicherheitsmodulspezifisch, bevor- zugt randomisiert, erfolgen. Es ist aber auch möglich, zuerst eine Tabelle zu erstellen, welche die entsprechenden Programmcodeanteile in einer vorgegebenen Reihenfolge umfasst, beispielsweise in der Reihenfolge, in der die Anteile ermittelt worden sind. In einem nachfolgenden Schritt kann dann eine sicherheitsmodulspezifische Anordnung dieser Anteile, beispielsweise durch Permutation der Tabelleneinträge, erfolgen. Die Reihenfolge, in der die Programmcodeanteile am Ende eines der beschriebenen Prozesse in der Tabelle angeordnet sind, bestimmt die Ausführungsreihenfolge der mittels der Programmcodeanteile codierten implementierten Teilfunktionalitäten bei sequentieller Ausführung des erzeugten Programmcodes.
Grundsätzlich können nebenläufig ausführbare Anteile der durch den bereitgestellten Quellcode definierten Operationen in allgemeiner Weise, auch aus einem bereits für eine sequentielle Ausführung angelegten Programmcode, ermittelt werden. Einige bekannte Programmstrukturen eignen sich allerdings besonders zur Parallelisierung, wie beispielsweise Schleifen. D.h. als nebenläufig ausführbare Anteile der durch den Quellcode definierten Operationen können bevorzugt eine Schleifenoperation definierende Anteile ermittelt werden. Eine Schleife beispielsweise der Form (for i=0; i < 1000; i++){a[i] := i} kann in bis zu 1000 Anteile aufgeteilt werden, jeder Anteil ent- sprechend zumindest einem Schleifendurchlauf, welche jeweils nebenläufig ausgeführt werden können. In gleicher Weise können als nebenläufig ausführbare Anteile eine geeignete Rekursion definierende Anteile ermittelt werden. Dies gilt insbesondere dann, wenn in einem Rekursionsaufruf dieselbe Funktion mehr als einmal, unabhängig voneinander und mit verschie- - lo derten Parametern, aufgerufen wird, wie dies beispielsweise bei einer bekannten, rekursiven Implementation des Quick-Sort- Algorithmus der Fall ist.
Gemäß einer weiteren bevorzugten Ausführungsform kann zumindest einer der ausführbaren Programmcodeanteile, der einem nebenläufig ausführbaren Anteil entspricht, im Schritt des Erzeugens des ausführbaren Programmcodes hinsichtlich zumindest eines vorgegebenen Parameters optimiert werden. Bevorzugte Parameter sind beispielsweise Laufzeit und/ oder Speicherbedarf. Diese Optimierung kann vor oder nach der sicherheitsmodulspezif i- sehen Anordnung mit Bezug auf die anderen ausführbaren Programmcodeanteile erfolgen, welche ebenfalls nebenläufig ausführbaren Anteilen entsprechen. Die Optimierung kann weiterhin in einer oder mehreren verschiedenen Phasen eines Übersetzungsprozesses vom Quellcode zum ausführbaren Programmcode erfolgen, also beispielsweise auch bereits auf Ebene eines Zwischencodes.
Auf diese Weise kann der erzeugte ausführbare Programmcode, im Vergleich zu einem entsprechenden Programmcode ohne Optimierung, ebenfalls sicherheitsmodulspezifisch ausgebildet werden. Eine Optimierung be- züglich Laufzeit, auch wenn diese nur einzelne Teilfunktionalitäten betrifft, verändert das Laufzeitverhalten der durch den erzeugten, ausführbaren Programmcode bereitgestellten Gesamtfunktionalität. Eine - auch nur teilweise - Optimierung bezüglich des Speicherbedarfs beeinflusst das gesamte Speicherabbild. Eine solche Optimierung kann überdies die Behandlung lokaler Variablen im Bereich der optimierten, ausführbaren Programmcodeanteile beeinflussen, und somit während der Laufzeit beispielsweise auch die Belegung eines Stapelspeichers, verschiedener Prozessorregister oder anderer Speicherbereiche, beispielsweise im Arbeitsspeicher des Prozessors. Besonders bevorzugt werden verschiedene der ausführbaren Programmcodeanteile, die nebenläufig ausführbaren Anteilen entsprechen, jeweils hinsichtlich verschiedener Parameter optimiert. Auf diese Weise ergeben sich vielfältige, weitere Möglichkeiten des sicherheitsmodulspezifischen Erzeu- gens des ausführbaren Programmcodes.
Gemäß einer weiteren bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens wird der Schritt des Ermitteins von nebenläufig ausführbaren Anteilen der durch den Quellcode definierten Operationen von einer Einrichtung durchgeführt oder durch eine solche Einrichtung zumindest unterstützt, welche zum Erzeugen von auf einer Mehrkern- und/ oder Mehrprozessorarchitektur parallel ausführbarem Programmcode eingerichtet ist. Eine solche Einrichtung kann auf verschiedenen Ebenen eingreifen oder wirken, beispielsweise in Form von in den Quellcode einfügbaren Compilerdi- rektiven oder, bei unverändertem Quellcode, durch Funktionalitäten des Compilers selbst.
D.h. eine solche bereits vorliegende, bekannte Einrichtung, beispielsweise ein Compiler zum Erzeugen von parallel ausführbarem Programmcode, wird erfindungsgemäß„zweckentfremdet", indem durch diese Einrichtung erzeugter, parallel auf einer Mehrprozessorarchitektur ausführbarer Programmcode als Zwischenergebnis verwendet wird. Der aufwendige und in der Regel komplexe Schritt des Ermitteins von nebenläufig ausführbaren Anteilen wird vollständig von dieser Einrichtung übernommen und, in der Re- gel zusätzlich konfigurierbar, durchgeführt.
Zum erfindungsgemäßen Erzeugen des sequenziell ausführbaren, sicherheitsmodulspezifischen Programmcodes ist es abschließend lediglich erforderlich, die von der Einrichtung für eine jeweils parallele Ausführung vorge- sehenen Anteile, wie beispielsweise parallel ausführbare Threads oder dergleichen, sicherheitsmodulspezifisch, vorzugsweise randomisiert, für eine sequentielle Ausführung auf einem Datenträger mit nur einem Prozessor anzuordnen. Dabei wird ein vermeintlicher Nachteil der parallelen Pro- grammierung, nämlich das notwendig daraus resultierende, nicht genau vorhersehbare Laufzeitverhalten einer entsprechenden, parallelisierten Anwendung, erfindungsgemäß in einen Vorteil umgemünzt, indem nämlich die Nichtvorhersehbarkeit des Laufzeitverhaltens, welche erfindungsgemäß ein Sicherheitsmerkmal des Sicherheitsmoduls ist, durch eine sicherheitsmodul- spezifische Anordnung parallelisierbarer Anteile zur sequentiellen Ausführung noch verstärkt wird.
Jedes Sicherheitsmodul einer erfindungsgemäßen Menge von Sicherheitsmodulen umf asst einen Speicher und einen Prozessor zum Ausführen von in dem Speicher gespeichertem, ausführbarem Programmcode. Die erfindungsgemäße Menge von Sicherheitsmodulen umfasst zumindest zwei Gruppen von Sicherheitsmodulen, wobei jede dieser Gruppen zumindest ein Sicherheitsmodul umfasst. Erfindungsgemäß ist der jeweils in einem Speicher eines Sicherheitsmoduls der Menge von Sicherheitsmodulen gespeicherte, aus- führbare Programmcode hinsichtlich dessen Funktionalität für jedes Sicherheitsmodul der Menge von Sicherheitsmodulen identisch, unterscheidet sich jedoch hinsichtlich dessen Laufzeitverhalten für jeweils zwei Sicherheitsmodule aus unterschiedlichen Gruppen der Gruppen von Sicherheitsmodulen. Wie vorstehend bereits beschrieben, gewährleistet ein sicherheitsmodulspe- zifisches, d.h. gruppen- oder Sicherheitsmodulindividuelles Laufzeitverhalten einer durch den ausführbaren Programmcode bereitgestellten Funktionalität die Sicherheit eines Sicherheitsmoduls einer Gruppe auch im Hinblick auf einen erfolgreichen Angriff auf ein Sicherheitsmodul einer anderen Gruppe.
Wie mit Bezug auf das erfindungsgemäße Verfahren beschrieben, beruht das unterschiedliche Laufzeitverhalten des Programmcodes für zwei Sicherheitsmodule aus unterschiedlichen Gruppen insbesondere darauf, dass sich der Programmcode eines Sicherheitsmoduls einer ersten Gruppe von dem Programmcode eines Sicherheitsmoduls einer zweiten Gruppe darin unterscheidet, dass beim Erzeugen des ausführbaren Programmcodes für die Si- cherheitsmodule jeweils ausführbare Programmcodeanteile, die nebenläufig ausführbaren Anteilen entsprechen, für eine sequenzielle Ausführbarkeit des ausführbaren Programmcodes durch den Prozessor des jeweiligen Sicherheitsmoduls gruppenspezifisch angeordnet worden sind. In der Regel wird sich dabei in einem nichtflüchtigen Speicher des Sicherheitsmoduls weiterhin ein sicherheitsmodulspezifisches Speicherabbild ergeben.
Das vorliegende System zur Erstellung von ausführbarem Programmcode umfasst ein speziell angepasstes Werkzeug zum Erzeugen des sequentiell ausführbaren Programmcodes für einen Quellcode und ein Werkzeug zur Ermittlung von nebenläufig ausführbaren Anteilen. Das Erzeugungswerkzeug ist eingerichtet die von dem Werkzeug zur Ermittlung ermittelten nebenläufig ausführbaren Programmcodeanteile für eine sequenzielle Ausführung auf dem Sicherheitsmodul bereitzustellen. Vorzugsweise kann ein Mul- tiprozessor- Werkzeug zur Ermittlung verwendet werden. Das Erzeugungs- Werkzeug ist dagegen ein Monoprozessor- Werkzeug. Das Ermittlungswerkzeug kann die ermittelten nebenläufig ausführbaren Programmcodeanteile für die nebenläufige Ausführung aufbereiten. Die Aufbereitung ergänzt insbesondere die für eine nebenläufige Ausführung nötigen Operationen (Anweisungen), beispielsweise um jedem Prozessor bzw. Programmcodeanteil die (zumindest teilweise gleichen) erforderlichen Werte (Variablen, Zeiger ...) zur Verfügung zu stellen.
Ein Sicherheitsmodul ist vorzugsweise ein Hardware-Sicherheitsmodul. Das Sicherheitsmodul kann ein tragbarer Datenträger sein, wie beispielsweise eine Chipkarte, ein USB-Token, ein RFID-Token oder eine sichere Massen- speicherkarte. Das Sicherheitsmodul kann reversibel mit einem Endgerät verbunden werden oder fest in ein Endgerät eingebaut sein, wie beispielsweise ein eingebautetes SIM-Modul (eUICC), ein TPM-Modul oder NFC- Modul.
Die vorliegende Erfindung wird im Folgenden mit Bezug auf die beiliegenden Zeichnungen beispielhaft beschrieben. Darin zeigen: Figur 1 eine bevorzugte Ausführungsform eines Datenträgers aus einer
Variante einer erfindungsgemäßen Menge von Datenträgern;
Figur 2 Schritte einer bevorzugten Ausführungsform eines erfindungsgemäßen Verfahrens zum Erzeugen ausführbaren Programm- codes;
Figuren 3A bis 3E Ergebnisse einzelner Teilschritte von Verfahrensschritten aus Fig. 2 und Figur 4 die Menge von Datenträgern, unterteilt in einzelne Gruppen, mit dem Datenträger aus Fig. 1 als Element einer Gruppe.
Mit Bezug auf Fig. 1 umfasst ein Datenträger 10 als Sicherheitsmodul, der hier als Chipkarte dargestellt ist, Datenkommunikationsschnittstellen 20, 20', einen Prozessor 30 sowie verschiedene Speicher 40, 50 und 60. Der Datenträger 10 kann auch in anderer Bauform vorliegen.
Als Datenkommunikationsschnittstellen 20, 20' umfasst der Datenträger 10 ein Kontaktfeld 20 zur kontaktbehafteten Datenkommunikation sowie eine Antennenspule 20' zur kontaktlosen Datenkommunikation. Alternative Datenkommunikationsschnittstellen können vorgesehen sein. Es ist weiterhin möglich, dass der Datenträger 10 lediglich eine Art der Datenkommunikation unterstützt, also lediglich kontaktbehaftet oder kontaktlos.
Der nicht flüchtige, nicht wiederbeschreibbare ROM-Speicher 40 umfasst ein Betriebssystem (OS) 42 des Datenträgers 10, welches den Datenträger 10 steuert. Zumindest Teile des Betriebssystems 42 können auch in dem nicht flüchtigen, wiederbeschreibbaren Speicher 50 gespeichert sein. Dieser kann beispielsweise als FLASH-Speicher vorliegen.
Der Speicher 50 umfasst datenträgerspezifischen, ausführbaren Programmcode 52, welcher, wie nachfolgend mit Bezug auf die Fig. 2 bis 3D beschrieben, erzeugt worden ist.
Der flüchtige, wiederbeschreibbare RAM-Speicher 60 dient dem Datenträger 10 als Arbeitsspeicher.
Wie in Fig. 4 gezeigt, liegen weitere Datenträger 10", 10'" einer Menge 100 von Datenträgern, unterteilt in verschiedene Gruppen 101, 102, 103, vor. Datenträger innerhalb einer Gruppe sind hinsichtlich der beschriebenen Komponenten jeweils identisch. Datenträger 10, 10", 10"' unterschiedlicher Gruppen 101, 102, 103 unterscheiden sich darin, dass die Funktionalität, welche durch den ausführbaren Programmcode 52, 52", 52'" (vgl. Fig. 3C, 3E) bereitgestellt wird, jeweils ein gruppenspezifisches Laufzeitverhalten aufweist und gegebenenfalls zu einem gruppenspezifischen Speicherabbild in einem nichtflüchtigen Speicher des jeweiligen Datenträgers führt. Die durch den Programmcode 52, 52', 52", 52'" bereitgestellte Funktionalität ist aller- dings für alle Datenträger 10, 10", 10"'der Menge 100 von Datenträgern, unabhängig von der Gruppenzugehörigkeit 101, 102, 103, identisch.
Mit Bezug auf Fig. 2 werden im Folgenden einzelne Schritte eines Verfahrens zum Erzeugen eines datenträgerspezifischen, ausführbaren Programmcodes 52 für den Datenträger 10 beschrieben.
In Schritt Sl wird ein Quellcode bereitgestellt. Dieser Quellcode definiert diejenigen Operationen, welche durchgeführt werden müssen, um die gewünschte Funktionalität bereitzustellen. Der Quellcode liegt in der Regel in einer Hochsprache, beispielsweise in„C",„Java" oder dergleichen vor.
In Schritt S2 werden nebenläufig ausführbare Anteile der durch den Quellcode definierten Operationen ermittelt. Ausführbarer Programmcode 52 wird in Schritt S3 erzeugt, wobei in Teilschritt TS31 nebenläufig ausführbare Anteile, wie nachfolgend beschrieben, datenträgerspezifisch, angeordnet werden. Dieser Teilschritt TS31 kann vor dem Erzeugen derjenigen ausführbaren Programmcodeanteile erfolgen, welche den als nebenläufig ausführbar ermittelten Anteilen entsprechen, oder aber danach. In einem optionalen vierten Schritt S4 können einzelne als nebenläufig ausführbar ermittelten Anteile und/ oder die dazugehörigen, erzeugten, ausführbaren Programmcodeanteile nach verschiedenen Kriterien optimiert werden. Auch die Optimierung kann bereits während, d.h. im Rahmen des Übersetzungsprozesses, also beim Erzeugen des ausführbaren Programmcodes, erfolgen, bevor beispielsweise abschließend ausführbarer Maschinencode erzeugt wird. Eine mögliche Vorgehensweise zum Ermitteln nebenläufig ausführbarer Anteile sowie zur Anordnung der entsprechenden Programmcodeanteile ist in den Fig. 3A bis 3C skizziert.
Sofern keine Missverständnisse zu erwarten sind, wird im Folgenden nur noch von„nebenläufig ausführbaren Anteilen" gesprochen, ohne genau zu unterscheiden, auf welcher Ebene diese gerade betrachtet werden. Dies kann beispielsweise die Ebene des Quellcodes, die Ebene eines Zwischencodes oder die Ebene eines Maschinencodes betreffen, je nachdem in welcher Phase eines nachfolgend grob skizzierten Übersetzungsprozesses diese Anteile bestimmt werden. D.h. eine Quellcodesequenz, welche beispielsweise eine Schleifenoperation codiert und in nebenläufig ausführbare Anteile zerlegt werden kann, wird in diesem Sinne mit der entsprechend in den Zwischen- code übersetzten Sequenz bzw. mit dem Stück ausführbaren Maschinencode gleichgesetzt, welcher diese Schleifenoperation für den Prozessor codiert.
Das Ermitteln der nebenläufig ausführbaren Anteile erfolgt in der Regel im Rahmen einer Übersetzung oder Compilierung des Quellcodes in den aus- führbaren Programmcode. Eine solche Übersetzung verläuft in bekannter Weise in verschiedenen Teilschritten. Diese können die Schritte der lexikalischen Analyse, der Syntaxanalyse, der semantischen Analyse, der Erzeugung von Zwischencode, der Codeoptimierung und der Codeerzeugung umfassen. Phasen, welche das Ermitteln der nebenläufig ausführbaren Anteile hauptsächlich betreffen können, sind beispielsweise die Syntaxanalyse, in der hierarchische Strukturen des Programms erkannt werden. Alternativ o- der zusätzlich können nebenläufig ausführbare Anteile während der Erzeugung von Zwischencode ermittelt werden, bei der die Ergebnisse der vorhergehenden Schritte, welche zur Analyse des Quellcodes dienten, in eine „abstrakte Maschinensprache", einen geeigneten Zwischencode, wie z.B. den 3-Adress-Code, übersetzt werden, von dem aus dann nachfolgend der tatsächliche Maschinencode für die vorliegende Plattform erzeugt wird. Es ist aber auch möglich, dass nebenläufig ausführbare Anteile, zumindest grob, bereits auf der Ebene des Quellcodes, also vor der Übersetzung, oder erst auf der Ebene des Maschinencodes, d.h. am Ende der Übersetzung, ermittelt werden. Schließlich können verschiedene, nebenläufig ausführbare Anteile in verschiedenen der vorstehend beschriebenen Phasen oder in mehr als einer Phase bestimmt werden.
Ein erster Teilschritt während des Ermitteins von nebenläufig ausführbaren Anteilen, der in Fig. 3A illustriert ist, kann eine Zerlegung des Programmcodes, auf einer geeigneten Ebene des Programmcodes 51, in Blöcke betreffen. Jeder dieser Blöcke A bis G umfasst jeweils eine Folge von Anweisun- gen, welche, wenn der Block erreicht wird, ausgeführt werden müssen, bevor der Block wieder verlassen wird. Es ist jedoch möglich, dass die Reihenfolge, in der einzelne der Blöcke ausgeführt werden können, variieren kann, ohne Einfluss auf das Endergebnis. In analoger Weise ist es möglich, dass Anweisungen innerhalb eines Blockes in verschiedener Reihenfolge ausge- führt werden können, ohne dass sich am Resultat der Berechnung etwas ändert. Diese beiden Fälle deuten auf nebenläufig ausführbare Anteile hin.
Wie mit Bezug auf Fig. 3B angedeutet, hat der bis dahin durchgeführte Über- setzungsprozess ergeben, dass die Blöcke A bis G nicht notwendig in der in Fig. 3A angedeuteten Reihenfolge ausgeführt werden müssen. Vielmehr zeigt sich, dass, nachdem die Anweisungen des Blocks A abgearbeitet worden sind, die Blöcke B, C und D parallel, verzahnt oder in beliebiger sequentieller Reihenfolge ausgeführt werden können, bevor das Programm mit Block E fortgesetzt wird. Mit anderen Worten, es besteht keine kausale Be- ziehung zwischen den Anteilen der Blöcke B, C und D. Keiner dieser Blöcke benötigt eine Eingabe, welche in direkter oder indirekter Weise von einer Ausgabe eines der anderen Blöcke abhängen könnte. Daher können diese Blöcke als - relativ zueinander - nebenläufig ausführbar ermittelt werden. Das gleiche gilt für die Unteranteile Fl, F2, ..., Fk des Anteils gemäß Block F.
Gemäß einer ersten Variante kann ausgehend von diesem Zwischenergebnis ausführbarer Programmcode für eine Mehrprozessorarchitektur, beispielsweise mit drei Prozessoren, erzeugt werden. Dabei würde beispielsweise für jeden der drei Blöcke B, C und D ausführbarer Programmcode erzeugt, welcher dann parallel auf jeweils einem der drei Prozessoren ausgeführt werden könnte. In analoger Weise könnte für die Unteranteile Fl, F2, Fk jeweils parallel ausführbarer Programmcode für einen der drei Prozessoren erzeugt werden.
Ausgehend von einem derart für eine Mehrprozessorarchitektur erzeugten, ausführbaren Programmcode kann sequentiell ausführbarer Programmcode für einen Datenträger 10 mit lediglich einem Prozessor erzeugt werden, wie dies in Fig. 3C illustriert ist. Dabei sind die Programmcodeanteile, welche den jeweils als nebenläufig ausführbar ermittelten Anteilen B, C und D bzw. Fl, F2, Fk, entsprechen, in zufälliger Reihenfolge für eine sequentielle Ausführung neu angeordnet worden. Aufgrund der Tatsache, dass diese Anteile parallel ausführbar sind, d.h. keine kausale Beziehung zueinander aufweisen, bleibt die Funktionalität des Gesamtprogramms identisch erhalten, egal in welcher Reihenfolge die Anordnung erfolgt. Dadurch, dass die Anordnung randomisiert erfolgt, ergibt sich insbesondere eine datenträgerspezifische Anordnung. Wird der entsprechende Programmcode 52 in einem nicht flüchtigen Speicher 50 des Datenträgers 10 gespeichert, ergibt sich ein datenträgerspezifisches Speicherabbild. Bei Ausführung des Programmcodes 52 ist ein datenträgerspezifisches Laufzeitverhalten erkennbar. Diese beiden technischen Effekte ergeben sich unmittelbar aus der Tatsache, dass die Programmcodeanteile, welche den nebenläufig ausführbaren Anteilen B, C, D bzw. Fl, F2, Fk entsprechen, datenträgerspezifisch angeordnet worden sind.
Gemäß einer zweiten Variante wird nicht erst, wie mit Bezug auf die erste Variante beschrieben, ausführbarer Programmcode für eine Mehrprozessorarchitektur erzeugt, welcher zum Erzeugen einer sequentiell ausführbaren Version erst wieder zerlegt und in beschriebener Weise neu angeordnet werden muss. Alternativ erfolgt hier die zufällige Anordnung der nebenläufig ausführbaren Anteile auf einer Ebene oberhalb des Maschinencodes, beispielsweise auf der Ebene des erwähnten Zwischencodes. Ausführbarer Programmcode 52 wird dann lediglich zur sequentiellen Ausführung erzeugt, wobei die den nebenläufig ausführbaren Anteilen B, C, D bzw. Fl, F2, ..., Fk entsprechenden Programmcodeanteile erneut datenträgerspezifisch, wie in Fig. 3C gezeigt, angeordnet werden.
Die Resultate, d.h. der erzeugte Programmcode 52, der ersten und der zwei- ten Variante entsprechen einander im Wesentlichen. Leichte Unterschiede können sich dadurch ergeben, dass beispielsweise Programmcode, welcher für eine echt parallele Ausführung auf einer Mehrprozessorarchitektur erzeugt worden ist, zusätzlichen Code umfasst, beispielsweise für eine mehrfache Initialisierung einzelner Variablen für jeden der parallel auszuführenden Zweige. Dieser Code ist in der direkt zur sequentiellen Ausführung erzeugten Version verzichtbar. Insofern ergibt sich ein jeweils unterschiedliches Speicherabbild. Hinsichtlich des Laufzeitverhaltens hingegen sind praktisch keine erkennbaren Unterschiede zu erwarten. Grundsätzlich wird die Funktionalität zum Ermitteln nebenläufig ausführbarer Anteile durch einen entsprechend eingerichteten Compiler bereitgestellt, insbesondere durch einen Compiler, der eingerichtet ist, Programmcode zu erzeugen, welcher auf einer Mehrprozessorarchitektur echt parallel ausge- führt werden kann. Das beschriebene Verfahren zum Erzeugen des sequentiell ausführbaren, datenträgerspezifischen Programmcodes macht sich, wie beschrieben, einen solchen Compiler oder eine vergleichbare Einrichtung zunutze. Es kann weiter vorgesehen sein, dass alternativ oder zusätzlich, auf der Ebene des Quellcodes bereits Anteile vorgegeben werden können, welche nebenläufig ausgeführt werden können. Dies kann beispielsweise mittels geeigneter Compiler-Direktiven erfolgen, die in den Programmcode geeignet eingefügt werden, wie diese z.B. im Zusammenhang mit der Programmierschnitt- stelle„OpenMP" bekannt sind. Mittels solcher Direktiven kann dem Compiler beispielsweise mitgeteilt werden, dass grundsätzlich als sequentiell ausführbar vorgesehene Anteile, so genannte„sections", z.B. die vorstehend angegebenen Anteile B, C und D, nebenläufig ausgeführt werden können. Dabei obliegt es dem Programmierer, die Bedingungen der nebenläufigen Aus- führbarkeit zu überprüfen.
Weiter können mittels geeigneter Direktiven solche Programmcodesequenzen, von denen bekannt ist, dass deren Anweisungen in einfacher Weise parallel ausgeführt werden können, dem Compiler angezeigt werden. Beson- ders geeignet sind Schleifenkonstruktionen, bei denen die einzelnen Schlei- fendurchläufe bezüglich Ein- und Ausgabedaten unabhängig voneinander sind. Diese Situation ist in den Fig. 3A und 3B mit dem Block F und den Unteranteilen Fl, F2, ..., Fk angedeutet. Der Block F könnte beispielsweise die Schleife (for i=0; i<k; i++){f[i]:=2*i+l} umfassen. Mittels einer Compilerdirek- tive wird der Compiler angewiesen, die Schleife zu parallelisieren. Dieser erkennt, dass die einzelnen Schleifendurchläufe unabhängig voneinander sind und erzeugt entsprechend k nebenläufig ausführbare Unteranteile Fl, F2, ..., Fk.
Es kann vorteilhaft sein, im Schritt des Ermitteins von nebenläufig ausführbaren Anteilen eine Anzahl von gleichzeitig nebenläufig ausführbaren Anteilen vorzugeben. Im vorhergehenden Beispiel hätte somit auch mit Bezug auf den Block F die Anzahl der Unteranteile beschränkt werden können.
Wie bereits erwähnt und mit Bezug auf Fig. 3D illustriert, können ein oder mehrere der als nebenläufig ausführbar ermittelten Anteile hinsichtlich eines oder mehrerer Parameter optimiert werden, beispielsweise die Anteile C und B, wobei sich die verschieden schraffiert hervorgehobenen optimierten An- teile C und B" ergeben. Bekannte Compiler verfügen dazu in der Regel über entsprechende Compile-Optionen, welche es beispielsweise erlauben, in mehreren Stufen hinsichtlich Ausführungsgeschwindigkeit oder Speicherbedarf optimierten Programmcode zu erzeugen. Dadurch, dass nicht der gesamte Programmcode einheitlich optimiert wird, sondern lediglich ausge- wählte Anteile, kann eine weitere datenträgerspezifische Ausgestaltung des in dieser Weise erzeugten Programmcodes 52' erreicht werden. Die Optimierung wirkt sich in der Regel sowohl auf das Laufzeitverhalten als auch auf die benötigten Speicherressourcen aus. Es können auch Optimierungsstufen gewählt werden, welche lediglich geeigneten, optimierten Zwischencode erzeugen. Ausführbarer Programmcode wird dann erst von einer Linker- Funktionalität erzeugt. Auf diese Weise kann einer Optimierung durchgeführt werden, welche nicht lediglich einzelne Module, sondern ein gesamtes Programmpaket betrifft. Es versteht sich, dass die Optimierung alternativ oder zusätzlich auch auf solche Anteile A, E und G erstreckt werden kann, die nicht nebenläufig ausführbar sind. In Fig. 3E ist exemplarisch ein für einen Datenträger 10" (vgl. Fig. 4) erzeugter, ausführbarer, datenträgerspezifischer Programmcode 52" gezeigt. Dieser unterscheidet sich von dem Programmcode 52', welcher für den Datenträger 10 erzeugt worden ist, einmal dahingehend, dass die den nebenläufig ausführbaren Anteilen B, C, D bzw. Fl, F2, Fk entsprechenden Programm- codeanteile für die sequentielle Ausführbarkeit gemäß einer abweichenden Reihenfolge angeordnet worden sind. Zum zweiten ist lediglich der Programmcodeanteil C optimiert worden, und zwar hinsichtlich eines anderen Parameters (beispielsweise Laufzeit anstelle von Speicherbedarf). Es ist unmittelbar einsichtig, dass das Laufzeitverhalten des Programmcodes 52" des Datenträgers 10" unterschiedlich ist von dem Laufzeitverhalten des Programmcodes 52' des Datenträgers 10.

Claims

P a t e n t a n s p r ü c h e 1. Verfahren zur Erzeugung eines auf einem Sicherheitsmodul (10) ausführbaren Programmcodes (52), umfassend die Schritte:
- Bereitstellen (Sl) eines Quellcodes;
- Ermitteln (S2) von nebenläufig ausführbaren Anteilen (B, C, D) der durch den Quellcode definierten Operationen;
- Erzeugen (S3) eines ausführbaren Programmcodes (52) aus dem
Quellcode;
dadurch gekennzeichnet, dass im Schritt des Erzeugens des ausführbaren Programmcodes (52) ausführbare Programmcodeanteile, die ermittelten, nebenläufig ausführbaren Anteilen (B, C, D) entsprechen, für eine sequenzielle Ausführbarkeit des erzeugten Programmcodes (52) sicherheitsmodulspezi- fisch angeordnet werden (TS31).
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die ausführbaren Programmcodeanteile, die nebenläufig ausführbaren Anteilen (B, C, D) entsprechen, für eine sequenzielle Ausführbarkeit des erzeugten Programmcodes (52) randomisiert angeordnet werden.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die ausführbaren Programmcodeanteile, die nebenläufig ausführbaren Anteilen (B, C, D) entsprechen, für eine sequenzielle Ausführbarkeit des erzeugten Programmcodes (52) derart angeordnet werden, dass sich bei Ausführung des Programmcodes (52) auf dem Sicherheitsmodul (10) ein datenträgerspezifisches Laufzeitverhalten zeigt.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die ausführbaren Programmcodeanteile, die nebenläufig ausführbaren Anteilen (B, C, D) entsprechen, für eine sequenzielle Ausführbarkeit des erzeugten Programmcodes (52) derart angeordnet werden, dass sich beim Speichern des Programmcodes (52) in einem nichtflüchtigen Speicher (50) des Sicherheitsmoduls (10) ein sicherheitsmodulspezifisches Speicherabbild ergibt.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeich- net, dass im Schritt des Ermitteins von nebenläufig ausführbaren Anteilen (B,
C, D) eine Anzahl von gleichzeitig nebenläufig ausführbaren Anteilen vorgegeben wird.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeich- net, dass ausführbare Programmcodeanteile, die ermittelten, nebenläufig ausführbaren Anteilen (B, C, D) entsprechen, in einer Tabelle angeordnet werden.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeich- net, dass als nebenläufig ausführbare Anteile (Fl, F2, ..., Fk) der durch den
Quellcode definierten Operationen eine Schleifenoperation (F) definierende Anteile ermittelt werden.
8. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeich- net, dass als nebenläufig ausführbare Anteile (B, C, D) der durch den Quellcode definierten Operationen eine Rekursion definierende Anteile ermittelt werden.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass zumindest einer der ausführbaren Programmcodeanteile, die nebenläufig ausführbaren Anteilen (B, C, D) entsprechen, hinsichtlich eines vorgegebenem Parameters optimiert wird (S4).
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass verschiedene der ausführbaren Programmcodeanteile, die nebenläufig ausführbaren Anteilen (B, C, D) entsprechen, jeweils hinsichtlich verschiedener Parameter optimiert werden.
11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass der Schritt des Ermitteins von nebenläufig ausführbaren Anteilen (B, C, D) der durch den Quellcode definierten Operationen von einer Einrichtung unterstützt wird, die zum Erzeugen von auf einer Mehrkern- oder Mehrprozessorarchitektur parallel ausführbarem Programmcode eingerichtet ist.
12. Menge (100) von Sicherheitsmodulen (10; 10", 10"') des gleichen Herstellers, wobei jeder dieser Sicherheitsmodule (10; 10"; 10"') einen Speicher (40; 50; 60) und einen Prozessor (30) zum Ausführen von in dem Speicher (50) gespeichertem, ausführbarem Programmcode (52'; 52"; 52"') umfasst, wobei die Menge (100) von Sicherheitsmodulen (10; 10"; 10'") zumindest zwei Gruppen (101; 102; 103) von Sicherheitsmodulen (10; 10"; 10"') umfasst und wobei jede dieser Gruppen (101; 102; 103) zumindest ein Sicherheitsmo- dul (10; 10"; 10'") umfasst, dadurch gekennzeichnet, dass der jeweils in einem Speicher (50) eines Sicherheitsmoduls (10; 10"; 10"') gespeicherte, ausführbare Programmcode (52'; 52"; 52"') hinsichtlich dessen Funktionalität für jedes Sicherheitsmodul (10; 10"; 10"') der Menge (100) von Sicherheitsmodulen (10; 10"; 10"') identisch ist, sich jedoch hinsichtlich dessen Lauf- zeitverhalten für jeweils zwei Sicherheitsmodul (10; 10") aus unterschiedlichen der Gruppen (101; 102) von Sicherheitsmodulen (10; 10"; 10"') unterscheidet.
13. Menge (100) von Sicherheitsmodulen (10; 10"; 10'") nach Anspruch 12, dadurch gekennzeichnet, dass das unterschiedliche Laufzeitverhalten des Programmcodes (52'; 52") für zwei Sicherheitsmodule (10; 10") aus unterschiedlichen Gruppen (101; 102) darauf beruht, dass sich der Programmcode (52') eines Sicherheitsmoduls (10) einer ersten Gruppe (101) von dem Pro- grammcode (52") eines Sicherheitsmoduls (10") einer zweiten Gruppe (102) darin unterscheidet, dass beim Erzeugen des ausführbaren Programmcodes (52'; 52") für die Sicherheitsmodule (10; 10") jeweils solche ausführbaren Programmcodeanteile, die nebenläufig ausführbaren Anteilen (B, C, D) entsprechen, für eine sequenzielle Ausführbarkeit des ausführbaren Programm- codes (52'; 52") durch den Prozessor (30) des jeweiligen Sicherheitsmoduls (10; 10") gruppenspezifisch angeordnet worden sind.
14. System zur Erzeugung eines auf einem Sicherheitsmodul (10) sequentiell ausführbaren Programmcodes (52)
- ein Werkzeug zum Erzeugen des sequentiell ausführbaren Programmcodes (52) für einen Quellcode;
gekennzeichnet durch
- ein Werkzeug zur Ermittlung von nebenläufig ausführbaren Anteilen (B, C, D) der durch den Quellcode definierten Operationen;
wobei das Werkzeug zum Erzeugen des Programmcodes eingerichtet ist, die von dem Werkzeug zur Ermittlung ermittelten nebenläufig ausführbaren Programmcodeanteile (B,C,D) für eine sequenzielle Ausführung auf dem Sicherheitsmodul (10) bereitzustellen.
15. System nach Anspruch 14 dadurch gekennzeichnet, dass das Ermittlungswerkzeug die ermittelten nebenläufig ausführbaren Programmcodeanteile (B, C, D) für eine nebenläufige Ausführung aufbereitet und das Erzeugungswerkzeug die aufbereiteten Programmcodeanteile (B, C, D) verwendet.
16. System nach Anspruch 14 oder 15 dadurch gekennzeichnet, dass das Erzeugungswerkzeug ein Monoprozessor- und/ oder Monotasking- Werkzeug ist und das Ermittlungs Werkzeug ein Mehrprozessor- und/ oder Multitasking- Werkzeug ist und das System zur Ausführung eines Verfah- rens nach einem der Ansprüche 1 bis 11 angepasst ist.
PCT/EP2013/002387 2012-08-10 2013-08-08 Verfahren zum erzeugen von ausf?hrbarem programmcode WO2014023431A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102012015899.8A DE102012015899A1 (de) 2012-08-10 2012-08-10 Verfahren zum Erzeugen von ausführbarem Programmcode
DE102012015899.8 2012-08-10

Publications (1)

Publication Number Publication Date
WO2014023431A1 true WO2014023431A1 (de) 2014-02-13

Family

ID=49182204

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2013/002387 WO2014023431A1 (de) 2012-08-10 2013-08-08 Verfahren zum erzeugen von ausf?hrbarem programmcode

Country Status (2)

Country Link
DE (1) DE102012015899A1 (de)
WO (1) WO2014023431A1 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000008542A1 (en) * 1998-07-31 2000-02-17 Koninklijke Philips Electronics N.V. Data processing device with means for counteracting analysis methods for the detection of a secret characteristic value
EP0981115A2 (de) * 1998-08-20 2000-02-23 Orga Kartensysteme GmbH Verfahren zur Ausführung eines Verschlüsselungsprogramms zur Verschlüsselung von Daten in einem mikroprozessorgestützten, tragbaren Datenträger
DE102004011488A1 (de) * 2004-03-09 2005-10-13 Giesecke & Devrient Gmbh Schutz von Software gegen Angriffe

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6668325B1 (en) * 1997-06-09 2003-12-23 Intertrust Technologies Obfuscation techniques for enhancing software security
FR2818846B1 (fr) * 2000-12-22 2004-03-05 Gemplus Card Int Procede de contre-mesure dans un composant electronique mettant en oeuvre un algorithme de cryptographie
ES2340086T3 (es) * 2007-06-29 2010-05-28 Telefonaktiebolaget Lm Ericsson (Publ) Ofuscacion de los rastros de ejecucion de un codigo de programa de ordenador.
US8781111B2 (en) * 2007-07-05 2014-07-15 Broadcom Corporation System and methods for side-channel attack prevention
US8572406B2 (en) * 2010-03-31 2013-10-29 Inside Contactless Integrated circuit protected against horizontal side channel analysis

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000008542A1 (en) * 1998-07-31 2000-02-17 Koninklijke Philips Electronics N.V. Data processing device with means for counteracting analysis methods for the detection of a secret characteristic value
EP0981115A2 (de) * 1998-08-20 2000-02-23 Orga Kartensysteme GmbH Verfahren zur Ausführung eines Verschlüsselungsprogramms zur Verschlüsselung von Daten in einem mikroprozessorgestützten, tragbaren Datenträger
DE102004011488A1 (de) * 2004-03-09 2005-10-13 Giesecke & Devrient Gmbh Schutz von Software gegen Angriffe

Also Published As

Publication number Publication date
DE102012015899A1 (de) 2014-02-13

Similar Documents

Publication Publication Date Title
DE112017004843T5 (de) Technologien für deterministischen Codeflussintegritätsschutz
DE102012200613A1 (de) System und Verfahren zur Unterstützung von JIT in einem sicheren System und zufällig zugewiesenen Speicherbereichen
DE102009050161A1 (de) Verfahren und Vorrichtung zum Testen eines Systems mit zumindest einer Mehrzahl von parallel ausführbaren Softwareeinheiten
WO2014023431A1 (de) Verfahren zum erzeugen von ausf?hrbarem programmcode
EP2936728B1 (de) Verfahren zum betreiben eines portablen datenträgers sowie ein solcher portabler datenträger
WO2016096139A1 (de) Verfahren zum bereitstellen einer sicherheitskritischen softwareapplikation auf einer computereinheit
DE102005046696B4 (de) Verfahren zum Erzeugen von geschütztem Programmcode und Verfahren zum Ausführen von Programmcode eines geschützten Computerprogramms sowie Computerprogrammprodukt
DE102004011488B4 (de) Schutz von Software gegen Angriffe
DE602004007368T2 (de) Verfahren zum verwalten eines in einem umprogrammierbaren onboard-system heruntergeladenen ausführbaren codes
DE102012015897A1 (de) Verfahren zum Ausführen vom Programmcode
EP1887458A1 (de) Pseudo-Zufallszahlengenerator für eine Chipkarte
DE102015209120A1 (de) Recheneinrichtung und Betriebsverfahren hierfür
DE602004001293T2 (de) Programmintegritätsprüfung mittels Statistiken
DE102015112837A1 (de) Vorrichtung und Verfahren zur Verhinderung des Klonens von Code
DE102015213300A1 (de) Verfahren und Vorrichtung zur Erzeugung einer Geräte-spezifischen Kennung und Geräte umfassend einen personalisierten programmierbaren Schaltungsbaustein
EP2660747B1 (de) Sicherheitsmodul
DE102008044808B4 (de) Verfahren zur Generierung von Programmcode in einem Betriebssystemspeicher und einem Applikationsspeicher eines Datenträgers
DE10307797B4 (de) Vorrichtung und Verfahren zum Ermitteln einer Unregelmäßigkeit in einem Ablauf eines Nutzprogramms
EP0977160B1 (de) Verfahren und Datenverarbeitungsanordnung zum gesicherten Ausführen von Befehlen
AT508649A2 (de) Chipkarte mit überwachung der integrität auf softwarebasis
DE102004058882A1 (de) Erzeugen von Programmcode in einem Ladeformat und Bereitstellen von ausführbarem Programmcode
DE102015201430A1 (de) Intrinsische Authentifizierung von Programcode
DE102004060548A1 (de) Ausführung eines Programms durch eine virtuelle Maschine
DE102005063499B4 (de) Compiliervorrichtung und Verfahren zum Compilieren
DE202017007536U1 (de) Induktive Äquivalenz bei der maschinellen Bearbeitung von Anweisungen

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13762746

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13762746

Country of ref document: EP

Kind code of ref document: A1