[go: up one dir, main page]

WO2014019679A1 - Verfahren zur bereitstellung von chips mit hohem re-engineering-schutz, insbesondere für digitale authentifizierungssysteme, wie chipkarten oder dergleichen, sowie danach hergestellte chips - Google Patents

Verfahren zur bereitstellung von chips mit hohem re-engineering-schutz, insbesondere für digitale authentifizierungssysteme, wie chipkarten oder dergleichen, sowie danach hergestellte chips Download PDF

Info

Publication number
WO2014019679A1
WO2014019679A1 PCT/EP2013/002251 EP2013002251W WO2014019679A1 WO 2014019679 A1 WO2014019679 A1 WO 2014019679A1 EP 2013002251 W EP2013002251 W EP 2013002251W WO 2014019679 A1 WO2014019679 A1 WO 2014019679A1
Authority
WO
WIPO (PCT)
Prior art keywords
chip
program modules
operating system
linker
chips
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.)
Ceased
Application number
PCT/EP2013/002251
Other languages
English (en)
French (fr)
Inventor
Marjan Erzen
Matthias Brüstle
Matthias Dünßer
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.)
MASKTECH INTERNATIONAL GmbH
Original Assignee
MASKTECH INTERNATIONAL 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 MASKTECH INTERNATIONAL GmbH filed Critical MASKTECH INTERNATIONAL GmbH
Publication of WO2014019679A1 publication Critical patent/WO2014019679A1/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/76—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 application-specific integrated circuits [ASIC] or field-programmable devices, e.g. field-programmable gate arrays [FPGA] or programmable logic devices [PLD]

Definitions

  • the invention relates to a method for providing chips having the features of the preamble of claim 1 and chips produced thereafter.
  • the method is used in particular for the provision of chips with high reengineering protection, especially for so-called embedded systems, in particular, for example, for digital authentication systems such as smart cards or the like as well as for other microprocessor-controlled systems.
  • Digital authentication devices such as smart cards are used in many areas to provide access to protected data or systems that are accessible only to a particular group of users. Users include both natural persons and automated systems for machine-machine communication. Authentication elements are understood in particular to include elements for creating electronic signatures.
  • chip Under chip is generally understood here an integrated circuit with at least one memory and a microprocessor. Such a chip does not necessarily have to be integrated in a card as a carrier.
  • memory sticks USB sticks
  • other media are also available as carrier media.
  • chip cards in particular portable data carriers, are referred to as chip cards.
  • Such smart cards are used, for example, as means of payment (cash cards) as sim cards for mobile phones, as electronic tickets, as signature cards or as decoder cards, for example in payment offers (pay-TV) or other access systems.
  • cash cards means of payment
  • signature cards for example in payment offers (pay-TV) or other access systems.
  • decoder cards for example in payment offers (pay-TV) or other access systems.
  • chips are also used in identification cards or ID cards, such as passports, identity card, driver's license, health cards, etc.
  • smart cards In these smart cards also called smart cards, data security plays a major role.
  • user-specific authentication and access data are stored on the card itself as sensitive data, such as user-related keys, which can be used to generate electronic signatures, among other things.
  • sensitive personal data such as biometric data
  • biometric data may also be stored.
  • EP 2 249 291 A1 a method for increasing the security of an existing contactless smart card technology is described, which also deals with the same problem.
  • the cryptographic process in the security operating system is stored in a ROM memory chip of the chip.
  • the encryption algorithm is therefore firmly established by the interconnection of the individual electronic components in the ROM memory in the manner of a "firmware".
  • the circuit pattern of the ROM memory therefore, it is fundamentally possible to draw conclusions about the structure of the encryption algorithm and the entire operating system structure.
  • the operating system also contains further information worthy of protection, such as a data protocol (IP), in particular for memory management.
  • IP data protocol
  • the operating system poses a certain security gap because of the risk of re-engineering its construction.
  • Information about the exact timing of stored in the operating system program parts are obtained, so that targeted attacks or influencing the process can be made.
  • a special command in the sequence program can be influenced in a targeted manner, for example a safety-related jump after an (EEPROM) write operation.
  • the procedure is usually such that the ROM memory module is successively ground and analyzed layer by layer with regard to the circuit pattern. Due to the small dimension of such ROM modules and the high mechanical load in this re-engineering a large number of individual ROM memory modules are usually required for this. Flash-based chips can also use similar techniques for re-engineering. In addition to the authentication systems, a re-engineering protection of chips is generally of particular importance in any sensitive application or in principle to reduce the potential for attack.
  • EP 0 929 040 A also describes the problem of replicating chip cards.
  • the microprocessor systems of different chip cards ie the system consisting of microprocessor and program memory, differ, so that the chip cards are not constructed identically.
  • individual command lines of the program code are exchanged according to a key.
  • the microprocessor is also changed in each case, in such a way that he knows the changed command sequence or that he retrieves the individual commands according to their changed order.
  • the double change so on the one hand the order of the commands in the program code and on the other side of the fetch order of each command line by the microprocessor, the same program function is fulfilled.
  • the same program function is fulfilled.
  • this is associated with a high cost and can be implemented economically only for a manageable number of different variants of the microprocessor system.
  • the object of the invention is to increase the security for such chips, in particular by protecting the operating system against re-engineering.
  • a plurality of, preferably for all chips of a common authentication system is a common security Operating system is provided, which is composed of individual interconnected program modules.
  • the individual program modules are in this case combined differently with the aid of a linker for different chips, so that a chip-specific, executable operating system is generated for a respective chip and read into a preferably writable memory of this chip.
  • the different chip-specific operating systems have the same functionality with each other, are therefore identical in terms of their function. However, they have a different structure due to the different combinations of the individual program modules. For the total number of all chips of a common authentication system, therefore, a variety of differently structured operating systems are provided.
  • This embodiment is based on purely software-technical changes of the program code for the operating system, so that with the same function a different structural design of the respective program code of the executable program, which forms the operating system, is created for the various smart cards. Since these are only changes to the respective program code, the effort in comparison to additional hard- wareischen changes significantly lower. This also offers the possibility of readily providing a very large number of differently configured chip-specific program codes, whereby the overall security is significantly increased. All smart cards that are equipped with the functionally identical security operating system therefore preferably have the same hardware, in particular the same microprocessor. Modifications to this are not required and are not made.
  • An executable computer program such as the safety-critical operating system of interest here, usually consists of a multiplicity of individual program modules. Such program modules are linked together. This means that the individual program modules contain jump labels or references to other program modules.
  • program modules are understood in particular to be defined program functions consisting of a plurality of individual command lines, but also constants or data. Different program modules can have different lengths.
  • the individual program modules of an executable program are regularly linked to each other by, for example, in the one program module by reference another program function in the sense of a work instruction is included. This happens, for example, by so-called jump labels, which thus represent an instruction on which command line (address) the additional program function to be called up is contained.
  • a programmer When programming an executable program code usually a programmer further program function initially in a high-level programming language, such as C, C ++, Pascal, Java, etc. source texts are written, for each demarcated program section a respective source code file is created. This source code is then translated using a compiler into a machine-readable code (target language). The source text file is here regularly converted into a so-called object file, which thus contains the instructions of the source text of the source text file in the machine-readable language.
  • a high-level programming language such as C, C ++, Pascal, Java, etc.
  • the individual program modules ie functions contained in the object files in the sense of special work instructions, must then be connected together to create an executable program, which is generally done by a so-called "linker.”
  • the individual program modules are set in a suitable order to each other, the linker also linked the individual program modules by assigning suitable jump labels
  • Object files typically contain multiple program modules, and multiple object data can be grouped together as needed.
  • linker is generally understood a computer program which assembles such individual program modules into an executable program.
  • the individual program modules are, as already mentioned, closed functional units.
  • libraries may be provided. These are put together via the linker to a static, executable program file. So this is a static link to create an executable program.
  • the individual program modules are in this case linked together in such a way that the function and the program sequence is reliably guaranteed.
  • the present embodiment is therefore based decisively on the consideration that different program modules in this linking process put together differently, so that the order of the individual program modules and thus the order of the structure of the program code is changed, but at the same time the functionality is maintained.
  • the writable memory is therefore preferably also such a flash memory or another, at least once writable memory, such as a PROM (programmable read-only memory), EPROM (erasable programmable read-only memory) or an EEPROM (Electrically Erasable Programmable Read-Only Memory).
  • PROM programmable read-only memory
  • EPROM erasable programmable read-only memory
  • EEPROM Electrically Erasable Programmable Read-Only Memory
  • ROM memories are also used.
  • a ROM memory is generally structured by means of so-called masks, so that the desired data is stored.
  • a plurality of different masks are preferably used for structuring the plurality of ROM memories.
  • the complexity increases with an increasing number of masks, so that preferably writable memories are used.
  • a different chip-specific operating system is formed on each chip. In principle, however, this is not absolutely necessary.
  • the number of differently structured operating systems is at least in the two-digit range, for example at least 50 or more.
  • the invention is based on the consideration that the operating system is composed of a plurality of individual program parts, the so-called program modules, each individual program module usually defines a self-contained subfunction of the operating system.
  • the composition of the individual program modules can vary for an identical common overall functionality, ie for a functionally identical operating system for all chip cards. Accordingly, it is provided that the individual program modules are assembled differently via the so-called linker. As a result, re-engineering is made considerably more difficult since a large number of individual memory modules is usually required for a respective re-engineering process.
  • Another advantage is the fact that the temporal (flow) behavior of the chip-specific operating system is different from chip to chip. Because if the entire program code (that is, the sum of the individual program modules) is composed differently, for example, caches (cache) are used differently, which can lead to temporally different processes. The cache behavior and thus the temporal behavior of the chip-specific operating system therefore changes from chip to chip and can not be predicted.
  • the linking of the individual program modules takes place on the chip.
  • the linker is thus integrated on the chip as an "on-board linker", which additionally increases security, because the chip is not transferred to a finished program but only individual program modules are intercepted from a computer on which the compilation was performed. to a remote computer, via which ultimately the reading into the flash Therefore, memory does not result in a successful attack to bring the security operating software in possession.
  • the on-board linker is also designed for subsequent modification, for example, extending or partially replacing the security operating software, for example as part of updates. This is therefore a so-called incremental link.
  • the program modules generated on the compiler computer are encrypted. Subsequently, these are transmitted in a preferred embodiment as an encrypted record to the linker, in which the record is decrypted and then the program modules are assembled to the executable operating system.
  • a first executable program is first generated as the first operating system in a conventional way, thus providing a reliably functioning operating system. From these, the chip-specific operating system is then first generated in a second step using the actual linker. By providing a first operating system, a certain program structure is already specified, to which the linker then resorts. It is therefore in the creation of the respective chip-specific operating system no complete restructuring of the entire program code of the operating system required, so that the amount of data to be transferred in the creation of the chip-specific operating system is kept low.
  • a conditioner is expediently provided, which is also referred to as a template generator.
  • this template pattern indicates, in particular, at which point program modules of which size are to be arranged.
  • the linker can distribute program modules of equal size at locations defined for that size. Based on the information still available to him about their reciprocal links, he then assigns the corresponding link information such as jump labels according to the then selected arrangement of the individual program modules in the template pattern.
  • the conditioner replaces the concrete links generated by the compiler linker for these selected program modules by linking pointers and passes these instructions to the linker as additional information. Based on these linking instructions, the linker makes the correct links again. Therefore, the conditioner preferably identifies only some of the program modules, for example based on a defined, uniform size, removes the concrete linking instructions (jump labels) contained in the program code of the first operating system and includes them in the supplementary information for the linker.
  • the program modules (M) have at least one uniform module size or even a plurality of uniform module sizes, or are brought to one or more uniform module sizes, before they are linked to the linker on a chip-specific basis. This increases the number of possible permutations.
  • the program modules are usually not arbitrarily permutated with each other, as e.g. Positions are given by the template pattern depending on the size.
  • module size is to be understood as meaning, in particular, the memory requirement of the respective module, that is to say the byte size.
  • the individual program modules have different module sizes due to their usually different functional scope.
  • small modules are enlarged, for example, by adding empty information. Large modules can be split and, if necessary, then enlarged again to the desired uniform module size.
  • the linker When assembling the individual program modules, the linker preferably uses the random principle, ie the linker contains a random number generator which determines which program modules are to be ranked in which order. This is done on the premise that the desired overall functionality and functionality is maintained, so that on all chips functionally identical security operating software is included. Conveniently, the number of individual program modules for the security operating system is> 50 and in particular> 100. Usually, a higher number makes sense to suitably limit the size of the individual modules. In combination with the random principle, therefore, results in a very large number of different combinations, so that a re-engineering is virtually impossible.
  • a so-called boot loader is additionally integrated on the chip, which is responsible for the communication to the outside and in particular also receives the program modules from the compiler computer.
  • the linker receives the program modules from the boot loader and then links them to the chip-specific operating system, which is then read in by the linker into the non-volatile memory (in particular flash memory).
  • program modules are first read directly into the flash memory and only then assembled by the linker to the chip-specific operating system.
  • boot loader and the linker are therefore themselves executable programs to which certain functions are assigned.
  • the boot loader and / or the linker are preferably also included in the flash memory. Alternatively, however, these can also be stored in a ROM memory.
  • the chip-specific operating system is generated in parallel on several chips.
  • a common contacting and data transmission unit is provided, via which in particular an energy and communication channel is provided, so that parallel and simultaneously the transmission of the program modules or the template operating system to the individual chips takes place.
  • the chip-specific operating system is then generated by the respective linker.
  • Several individual chips are usually generated together on a wafer.
  • the individual chips are interconnected on the wafer to form a simplified contacting and transfer unit.
  • the communication channel or path is therefore already formed on the side of the wafer.
  • the transmission of the program modules is therefore carried out before the separation of the wafer wafer.
  • FIGS. Each shows in a simplified representation based on a block diagram
  • Fig. 1 shows the basic procedure for creating a set of smart cards with chip-specific operating systems according to a first variant
  • Fig. 2 shows the procedure according to a second variant.
  • individual program modules M of an operating software OS are first programmed by a first service provider D1 and subsequently supplied to a compiler computer 2, in which the individual program modules M are compiled to form the program modules M 1 into a machine-readable code.
  • These compiled program modules M 1 are then encrypted according to the first variant shown in FIG. 1 and provided in a data file F (IW) as an encrypted data record.
  • This encrypted data set F ( ⁇ ') is transmitted to a second service provider D2, usually a service provider commissioned with the production of the individual chip cards.
  • This provides a plurality of smart cards 4 with an integrated chip 6, which has a microprocessor 8 and a non-volatile, writable memory 10 (flash memory).
  • the memory 10 has in the embodiment described here a boot loader 12 and a linker 14, which are designed as executable programs and, for example, are already pre-installed.
  • the program of the boot loader 12 and / or the linker 14 is preferably likewise transmitted in a separate, encrypted file (once) by the software service provider D1.
  • the linker 14 is included in the encrypted file F (M ').
  • the services of the service providers D1.D2 can also be made in one place by a common service provider.
  • the encrypted file F ( ⁇ ') is received by a loading computer 16 of the service provider D2. This is connected to a card device, not shown here, to transfer the data in the memory 10.
  • the communication is preferably carried out via the boot loader 12, which therefore receives the encrypted file F ( ⁇ ') from the loading computer 16, decrypts the encrypted program modules M' again and makes it available to the linker 14.
  • the linker 14 With the help of a random generator, the linker 14 then assembles the individual program modules M into a chip-specific operating system C-OS and stores this in a corresponding memory area of the memory 10. All activities of the boot loader 12 and the linker 14 are controlled by the microprocessor 8.
  • a first linker referred to as a compiler linker 18, is provided, which compiles the program modules M into the program modules M '.
  • the compiler linker 18 is designed as a linker, which links the latter to a first operating system OS before transferring the program modules M 'to the chip 6.
  • the two functions of compiling and linking can also be performed in separate functional units.
  • a kind of template pattern V is generated with the aid of a conditioner 20, which together with supplementary information I are combined in the file F (M ', V, I) to be transmitted.
  • the conditioner 20 identifies individual program modules M ', preferably those which are identical or identical to one another, in particular with regard to their size. It expediently identifies only a certain part of the program modules M ', hereinafter referred to as selected program modules M', which are marked in the template pattern V by black dots.
  • the conditioner 20 removes the specific links contained in the program code of the operating system OS between the individual program modules M' and writes this linking information into the supplementary information I transmitted.
  • the remaining program modules M 'remain untouched, i. both their position in the program code and their reciprocal links remain untouched.
  • the linker 14 finally receives this template pattern V with the associated information I and the program modules M '.
  • the linker 14 now only links the selected program modules M 'according to a random principle and assigns the corresponding linking information. In this in-fig. Therefore, only the selected identical, in particular the same size, program modules M 'permute on their respective positions within the operating system OS.
  • the chip-specific operating system C-OS is again obtained, in which, however, only a part of the program modules M 'is permuted from chip card 4 to chip card 4, as illustrated by the number sequence of the program modules M' of the chip-specific operating system C-OS in FIG. 2 is.
  • the process of generating the chip-specific operating system C-OS is repeated for each individual chip card 4 of a chip card system with a plurality (several thousand) of chip cards 4 of a system provider, ie the encrypted
  • the rare file F ( ⁇ ') only needs to be transferred once to the chip card manufacturer D2.
  • the loading computer 16 transmits this protected file F ( ⁇ ') to each individual memory 10 of the smart card 4. All smart cards of the smart card system have the same in terms of functionality operating software OS, which, however, by the chip-specific configuration with regard to their structural structure, ie the sequence of program modules M differ.
  • the random number generator ensures that virtually no chip card 4 has an identical chip-specific operating system C-OS. Reengineering is thus virtually eliminated.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Mathematical Physics (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Description

Beschreibung
Verfahren zur Bereitstellung von Chips mit hohem Re-Engineering-Schutz, insbesondere für digitale Authentifizierungssysteme, wie Chipkarten oder dergleichen, sowie danach hergestellte Chips
Die Erfindung betrifft ein Verfahren zur Bereitstellung von Chips mit den Merkmalen des Oberbegriffs des Anspruchs 1 sowie danach hergestellt Chips.
Ein derartiges Verfahren ist beispielsweise zu entnehmen aus der EP 2 249 291 A1 oder der DE 10 2004 058 882.
Das Verfahren dient insbesondere zur Bereitstellung von Chips mit hohem ReEngineering- Schutz, speziell für sogenannte eingebettete Systeme (embedded Systems), insbesondere beispielsweise für digitale Authentifizierungssysteme wie Chipkarten oder dergleichen sowie für andere Mikroprozessor-gesteuerte Systeme.
Digitale Authentifizierungselemente wie Chipkarten werden in vielen Bereichen eingesetzt, um den Zugriff auf geschützte Daten oder Systeme zu ermöglichen, die nur einem bestimmten Nutzerkreis zugänglich sind. Unter Nutzer sind hierbei sowohl natürliche Personen als auch automatisierte Systeme für Maschinen- Maschinen-Kommunikation zu verstehen. Unter Authentifizierungselemente werden insbesondere auch Elemente zur Erstellung von elektronischen Signaturen verstanden.
Unter Chip wird hier allgemein ein integrierter Schaltkreis mit zumindest einem Speicher und einem Mikroprozessor verstanden. Ein derartiger Chip braucht nicht notwendigerweise in einer Karte als Träger integriert zu sein. Es bieten sich als Trägermedien beispielsweise auch Speichersticks (USB-Sticks) sowie andere Medien an. Nachfolgend wird der Einfachheit halber für solche mit einem Chip versehene, insbesondere tragbare Datenträger von Chipkarten gesprochen.
BESTÄTIGUNGSKOPIE Derartige Chipkarten werden beispielsweise als Zahlungsmittel (Geldkarten) als Sim-Karten für Mobiltelefone, als elektronische Tickets, als Signaturkarten oder auch als Decoderkarten zum Beispiel bei Bezahlangeboten (Bezahlfernsehen) oder anderen Zugangssystemen eingesetzt. Insbesondere werden derartige Chips auch bei Identifizierungskarten oder Ausweiskarten, wie z.B. bei Pässen, beim Personalausweis, beim Führerschein, bei Gesundheitskarten etc. eingesetzt.
Bei diesen auch als Smart Cards bezeichneten Chipkarten spielt die Datensicherheit eine große Rolle. Üblicherweise sind auf der Karte selbst benutzereigene Au- thentifizierungs- und Zugangsdaten als sensible Daten hinterlegt, wie beispielsweise benutzerbezogene Schlüssel, über die unter anderem auch elektronische Signaturen erzeugt werden können. Zudem können auch sensible personenbezogene Daten (z.B. biometrisches Daten) hinterlegt sein.
Um diese sensiblen Daten auf der Karte zu sichern, werden diese mit Hilfe des Mikroprozessors über ein auf dem Chip hinterlegtes kryptographisches Verfahren vor fremdem Zugriff geschützt. Ziel eines jeden Angriffs ist das Ermitteln und der Zugriff auf die sensiblen Daten.
Es besteht ein hohes Bedürfnis, einen derartigen nicht autorisierten Zugriff auf die sensiblen Daten zu verhindern. Denn bei Kenntnis dieser Daten wird ein Missbrauch derartiger Systeme ermöglicht und es können durch unbefugte Dritte derartige Chipkarten, beispielsweise für das Bezahlfernsehen, mit den entsprechenden Zugriffsmöglichkeiten auf die geschützten Inhalte erstellt werden.
In der EP 2 249 291 A1 ist ein Verfahren zur Erhöhung der Sicherheit einer bestehenden kontaktlosen Chipkartentechnik beschrieben, welche sich ebenfalls mit der gleichen Problematik auseinandersetzt.
Bei heutigen Chipkarten ist das Kryptographieverfahren im Sicherheits- Betriebssystems in einem ROM-Speicherbaustein des Chips hinterlegt. Der Verschlüsselungs-Algorithmus ist daher durch die Verschaltung der einzelnen Elektronik-Bauteile im ROM-Speicher in diesem nach Art einer Firmware„fest einge- brannt". Anhand des Schaltungsmusters des ROM-Speichers lässt sich daher grundsätzlich auf den Aufbau des Verschlüsselungsalgorithmus sowie des gesamten Betriebssystemaufbaus rückschließen. Im Betriebssystem sind darüber hinaus weitere schützenswerte Informationen enthalten, wie beispielsweise ein Datenprotokoll (IP) insbesondere zur Speicherverwaltung.
Das Betriebssystem stellt eine gewisse Sicherheitslücke dar, da durch Re- Engineering- Verfahren die Gefahr der Analyse dessen Aufbaus besteht. Dadurch können z.B. Informationen über den genauen zeitlichen Ablauf von im Betriebssystem hinterlegten Programmteilen erhalten werden, so dass gezielte Angriffe bzw. Beeinflussungen des Ablaufs vorgenommen werden können. So kann beispielsweise ein spezieller Befehl im Ablaufprogramm gezielt beeinflusst werden, beispielsweise ein sicherheitsrelevanter Sprung nach einem (EEPROM-) Schreibvorgang.
Die genaue Kenntnis des Aufbaus des Betriebssystems, insbesondere die Kenntnis, welche Gegenmaßnahmen gegen Belauschen oder Manipulation der Datenverarbeitung umgesetzt und wie diese umgesetzt wurden, erleichtert es daher einem Angreifer, Schwachstellen des Betriebssystems als auch der zu Grunde liegenden Hardware, in die beispielsweise eine Verschlüsselungsfunktionen integriert ist, zu erkennen und auszunutzen, um auf die geschützten sensiblen Daten zugreifen zu können.
Bei diesem Re-Engineering wird üblicherweise derart vorgegangen, dass der ROM-Speicherbaustein sukzessive geschliffen wird und Schicht für Schicht im Hinblick auf das Schaltungsmuster analysiert wird. Aufgrund der geringen Dimension derartiger ROM-Bausteine und der hohen mechanischen Belastung bei diesem Re-Engineering werden dafür in der Regel eine Vielzahl von einzelnen ROM- Speicherbausteinen benötigt. Auch bei Flash-basierten Chips können ähnliche Verfahren für ein Re-Engineering eingesetzt werden. Neben den Authentifizierungssystemen ist ein Re-Engineering-Schutz von Chips generell von besonderer Bedeutung bei jeglichen sensiblen Anwendungen oder auch grundsätzlich, um das Angriffspotential zu verringern.
Aus der DE 10 2004 058 882 A1 ist ein Verfahren zum Erzeugen eines Programmcordes in einem Ladeformat für einen tragbaren Datenträger wie beispielsweise eine Chipkarte beschrieben. Diese Anmeldung geht dabei von dem Problem aus, dass bei modernen tragbaren Datenträgern zunehmend ein Nachladen von Programmcodes gewünscht ist. Bei Datenträgern, die sicherheitskritische Anwendungen beinhalten, besteht dabei das Problem, dass für das Nachladen von Programmcodes durch Dritte möglichst keine Interna des Datenträgers preisgegeben werden sollten. Das Nachladen von speziellen Programmcodes erfordert jedoch Kenntnis von den auf dem Datenträger implementierten Funktionen, sofern der nachzuladende Programmcode auf diese Funktionen zugreifen muss. Um die Sicherheit zu erhöhen, ist gemäß der DE 10 2004 058 882 A1 vorgesehen, dass eine auf dem Datenträger befindliche Bibliothek lediglich in Form einer reduzierten Pseudobibliothek für Dritte bereitgestellt wird. Dadurch besteht die Möglichkeit, sicherheitskritische Informationen geheim zu halten und gleichzeitig einem externen Programmentwickler die Pseudobibliothek an die Hand zu geben, um einen nachladbaren Programmcode erstellen zu können.
In der EP 0 929 040 A wird ebenfalls das Problem des Nachbaus von Chipkarten beschrieben. Zur Verbesserung der Sicherheit wird hierbei vorgeschlagen, dass sich die Mikroprozessorsysteme verschiedener Chipkarten, also das System bestehend aus Mikroprozessor und Programmspeicher, sich unterscheiden, so dass die Chipkarten nicht identisch aufgebaut sind. Hierbei werden einzelne Befehlszeilen des Programmcodes gemäß einem Schlüssel vertauscht. Basierend auf diesem Schlüssel ist auch der Mikroprozessor jeweils verändert, und zwar derart, dass ihm die geänderte Befehlsabfolge bekannt ist bzw. dass er die einzelnen Befehle entsprechend ihrer geänderten Reihenfolge abruft. Durch die doppelte Änderung, also auf der einen Seite der Reihenfolge der Befehle im Programmcode und auf der anderen Seite der Abrufreihenfolge der einzelnen Befehlszeile durch den Mikroprozessor, wird die gleiche Programmfunktion erfüllt. Gleichzeitig ist durch die unterschiedliche Ausbildung der verschiedenen Mikroprozessorsystemen bei verschiedenen Chipkarten ein Nachbau erschwert. Allerdings ist dies mit einem hohen Aufwand verbunden und lässt sich wirtschaftlich auch lediglich für eine überschaubare Anzahl von unterschiedlichen Varianten des Mikroprozessorsystems umsetzen.
Ausgehend hiervon liegt der Erfindung die Aufgabe zugrunde, die Sicherheit für derartige Chips zu erhöhen, insbesondere durch einen Schutz des Betriebssystems gegen ein Re-Engineering.
Die Aufgabe wird gelöst durch ein Verfahren zur Bereitstellung von Chips, insbesondere für tragbare Datenträger, speziell für digitale Authentifizierungselemente wie Chipkarten oder dergleichen, mit den Merkmalen des Anspruchs 1. Bei diesem Verfahren ist für mehrere, vorzugsweise für alle Chips eines gemeinsamen Authentifizierungssystems ein gemeinsames Sicherheits-Betriebssystem vorgesehen ist, welches aus einzelnen miteinander verknüpften Programmmodulen aufgebaut ist. Die einzelnen Programmmodule werden hierbei mit Hilfe eines Linkers für verschiedene Chips unterschiedlich miteinander kombiniert, so dass für einen jeweiligen Chip ein chipindividuelles, ausführbares Betriebssystem erzeugt und in einen vorzugsweise beschreibbaren Speicher dieses Chips eingelesen wird. Die verschiedenen chipindividuellen Betriebssysteme weisen dabei die gleiche Funktionalität untereinander auf, sind daher im Hinblick auf ihre Funktion identisch. Allerdings weisen sie aufgrund der unterschiedlichen Kombination der einzelnen Programmmodule einen unterschiedlichen Aufbau auf. Für die Gesamtzahl aller Chips eines gemeinsamen Authentifizierungssystems werden daher eine Vielzahl von unterschiedlich strukturierten Betriebssystemen bereitgestellt.
Diese Ausgestaltung basiert dabei auf rein softwaretechnischen Änderungen des Programmcodes für das Betriebssystem, so dass bei gleicher Funktion ein unterschiedlicher struktureller Aufbau des jeweiligen Programmcodes des ausführbaren Programms, welches das Betriebssystem bildet, für die verschiedenen Chipkarten geschaffen ist. Da es sich hier lediglich um Änderungen an dem jeweiligen Programmcode handelt, ist zudem der Aufwand im Vergleich zu zusätzlichen hard- waretechnischen Änderungen deutlich geringer. Dies bietet auch die Möglichkeit, ohne Weiteres eine sehr große Anzahl von unterschiedlich ausgestalteten chipindividuellen Programmcodes bereitzustellen, wodurch insgesamt die Sicherheit deutlich erhöht ist. Alle Chipkarten, die mit dem funktionell gleichen Sicherheits- Betriebssystem ausgestattet werden, weisen daher vorzugsweise die gleiche Hardware, insbesondere den gleichen Mikroprozessor auf. Modifikationen an diesem sind nicht erforderlich und werden auch nicht vorgenommen.
Ein ausführbares Computerprogramm, wie das hier interessierende sicherheitskritische Betriebssystem, besteht üblicherweise aus einer Vielzahl von einzelnen Programmmodulen. Derartige Programmmodule sind dabei miteinander verknüpft. Hierunter wird verstanden, dass die einzelnen Programmmodule Sprungmarken oder Verweisungen auf andere Programmmodule enthalten. Unter Programmmodule werden hierbei insbesondere definierte Programmfunktionen bestehend aus einer Mehrzahl von einzelnen Befehlszeilen aber auch Konstanten oder Daten verstanden. Unterschiedliche Programmmodule können dabei unterschiedliche Längen aufweisen. Die einzelnen Programmmodule eines ausführbaren Programms sind dabei regelmäßig miteinander verknüpft, indem beispielsweise in dem einen Programmmodul durch Verweis eine weitere Programmfunktion im Sinne einer Arbeitsanweisung einbezogen wird. Dies geschieht beispielsweise durch sogenannte Sprungmarken, die also eine Anweisung darstellen, an welcher Befehlszeile (Adresse) die aufzurufende weitere Programmfunktion enthalten ist.
Bei der Programmierung eines ausführbaren Programmcodes werden üblicherweise von einem Programmierer weitere Programmfunktion zunächst in einer höheren Programmiersprache, wie beispielsweise C, C++, Pascal, Java etc. Quelltexte verfasst, wobei für einen jeweiligen abgegrenzten Programmabschnitt eine jeweilige Quelltextdatei erstellt wird. Dieser Quelltext wird anschließend mit Hilfe eines Compilers in einen maschinenlesbaren Code (Zielsprache) übersetzt. Die Quelltextdatei wird hierbei regelmäßig in eine sogenannte Objektdatei überführt, welche also die Anweisungen des Quelltextes der Quelltextdatei in der maschinenlesbaren Sprache enthält. Die einzelnen Programmmodule, also in den Objektdateien enthaltenen Funktionen im Sinne von speziellen Arbeitsanweisungen, müssen dann zur Erstellung eines ausführbaren Programms noch miteinander verbunden werden, was allgemein durch einen sogenannten„Linker" geschieht. Hierbei werden die einzelnen Programmmodule in einer geeigneten Reihenfolge zueinander gesetzt, wobei der Linker zugleich die einzelnen Programmmodule durch Vergabe von z.B. geeigneten Sprungmarken miteinander geeignet verknüpft. Objektdateien enthalten üblicherweise mehrere Programmmodule. Mehrere Objektdaten wiederum können bei Bedarf zu einer Bibliothek zusammengefasst sein.
Unter Linker wird allgemein ein Computerprogramm verstanden, welches derartige einzelne Programmmodule zu einem ausführbaren Programm zusammenstellt. Bei den einzelnen Programmmodulen handelt es sich wie bereits erwähnt um abgeschlossene Funktionseinheiten. Ergänzend können auch sogenannte Bibliotheken vorgesehen sein. Diese werden über den Linker zu einer statischen, ausführbaren Programm-Datei zusammengestellt. Es handelt sich hier also um ein statisches Linken zur Erstellung eines ausführbaren Programms. Die einzelnen Programmodule werden hierbei derart miteinander verknüpft, dass die Funktion und der Programmablauf zuverlässig gewährleistet ist.
Vorliegende Ausgestaltung beruht also entscheidend auf der Überlegung, die einzelnen Programmmodule bei diesem Verlinkungsprozess unterschiedlich zusammen zusetzen, so dass die Reihenfolge der einzelnen Programmmodule und damit die Reihenfolge der Aufbau-Struktur des Programmcodes verändert ist, gleichzeitig jedoch die Funktionalität beibehalten ist.
Diese Ausgestaltung geht dabei auch von der Überlegung aus, dass bei neueren Systemen die nicht beschreibbaren ROM-Speicher durch beschreibbare Speichern, insbesondere Flash-Speichern ersetzt werden. Bei dem beschreibbaren Speicher handelt es sich daher auch vorzugsweise um einen solchen Flash- Speicher oder einen anderen, zumindest einmal beschreibbaren Speicher, beispielsweise ein PROM (Programmable Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory ) oder ein EEPROM (Electrically Erasable Programmable Read-Only Memory). Alternativ zur Verwendung von beschreibbaren Speichern werden auch ROM- Speicher eingesetzt. Ein ROM-Speicher wird allgemein mit Hilfe von sogenannten Masken strukturiert, so dass die gewünschten Daten abgespeichert werden. Bei der Verwendung von ROM-Speichern werden zur Strukturierung der mehreren ROM-Speicher vorzugsweise eine Vielzahl von unterschiedlichen Masken eingesetzt. Allerdings steigt der Aufwand mit zunehmender Zahl an Masken, so dass vorzugsweise beschreibbare Speicher verwendet werden.
Bevorzugt wird auf jedem Chip ein unterschiedliches chipindividuelles Betriebssystem ausgebildet. Grundsätzlich ist dies jedoch nicht zwingend erforderlich. Die Anzahl der unterschiedlich strukturierten Betriebssysteme liegt dabei zumindest im zweistelligen Bereich, beispielsweise bei zumindest 50 oder mehr.
Zusammenfassend baut die Erfindung also auf der Überlegung auf, dass das Betriebssystem sich aus einer Vielzahl von einzelnen Programmteilen, den sogenannten Programmmodulen zusammensetzt, wobei jedes einzelne Programmmodul üblicherweise eine in sich abgeschlossene Teilfunktion des Betriebssystems festlegt. Schließlich wird hierbei auch berücksichtigt, dass es für eine identische gemeinsame Gesamtfunktionalität, also für ein für alle Chipkarten funktional identisches Betriebssystem, die Zusammensetzung der einzelnen Programmmodule variieren kann. Entsprechend ist vorgesehen, dass die einzelnen Programmmodule über den sogenannten Linker verschieden zusammengesetzt werden. Dadurch ist ein Re-Engineering deutlich erschwert, da für ein jeweiliges Re-Engineering- Verfahren üblicherweise eine Vielzahl von einzelnen Speicherbausteinen erforderlich ist. Das Re-Engineering setzt jedoch voraus, dass alle Speicherbausteine im Hinblick auf ihren strukturellen Aufbau, welcher definiert ist durch den eingebrannten Algorithmus, identisch sind, d.h. der im Speicher hinterlegte Algorithmus (Programmcode) muss für ein sinnvolles Re-Engineering bei einer Vielzahl von einzelnen Chips nicht nur im Hinblick auf seine Funktion sondern auch im Hinblick auf seinen strukturellen Aufbau identisch sein. Durch das hier vorgestellte Verfahren wird gerade dies verhindert, so dass das Re-Engineering erschwert wenn nicht unmöglich gemacht wird.
Dies beruht insbesondere auch darauf, dass durch die Bereitstellung von chipindividuellen Betriebssystemen im beschreibbaren Speicher chipindividuelle, voneinander verschiedene (Hardware-) Strukturen erzeugt werden. Unter„unterschiedlicher struktureller Aufbau" wird daher verstanden, dass im Speicher verschiedene Hardware-Strukturen erzeugt werden, dass also beim Beschreiben des nichtflüchtigen Flash-Speichers der Programmcode quasi„eingebrannt" ist, so dass chipindividuelle, voneinander verschiedene Hardware-Strukturen bei gleichzeitig identischer Funktion erzeugt sind.
Selbst falls ein Re-Engineering eines chipindividuellen Betriebssystems gelingt, hat ein Angreifer noch keinen Zugriff auf das chipindividuelle Betriebssystem eines anderen Chips. Denn der Code dieses weiteren chipindividuellen Betriebssystems kann eben nicht vorhergesagt werden.
Ein weiterer Vorteil ist darin zu sehen, dass auch das zeitliche (Ablauf-) Verhalten des chipindividuellen Betriebssystem von Chip zu Chip verschieden ist. Denn wenn der gesamte Programmcode (also die Summe der einzelnen Programmmodule) unterschiedlich zusammengesetzt ist, werden beispielsweise Zwischenspeicher (Cache) unterschiedlich eingesetzt, was zu zeitlich anderen Abläufen führen kann. Das Cache-Verhalten und damit das zeitliche Verhalten des chipindividuellen Betriebssystems ändert sich daher von Chip zu Chip und kann nicht vorhergesagt werden.
Zweckdienlicherweise erfolgt das Verlinken der einzelnen Programmmodule auf dem Chip. Der Linker ist also als„on board Linker" auf dem Chip integriert. Dies erhöht die Sicherheit zusätzlich, da auf den Chip kein fertiges Programm sondern lediglich einzelne Programmmodule überspielt werden. Ein Abhören der Datenübertragung von einem Rechner, auf dem die Compilierung vorgenommen wurde, zu einem entfernten Rechner, über den letztendlich das Einlesen in den Flash- Speicher vorgenommen wird, führt daher ebenfalls nicht zu einem erfolgreichen Angriff, um die Sicherheits-Betriebssoftware in Besitz zu bringen.
Vorzugsweise ist der on board-Linker auch zum nachträglichen Ändern, beispielsweise Erweitern oder teilweises Ersetzen der Sicherheits-Betriebssoftware ausgebildet, beispielsweise im Rahmen von Updates. Es handelt sich hierbei also um ein sogenanntes inkrementelles Linken.
Weiterhin werden zur Erhöhung der Sicherheit in bevorzugter Weiterbildung die auf dem Compiler-Rechner erzeugten Programmmodule verschlüsselt. Anschließend werden diese in bevorzugter Ausgestaltung als verschlüsselter Datensatz zum Linker übertragen, bei dem der Datensatz entschlüsselt und anschließend die Programmmodule zum ausführbaren Betriebssystem zusammengesetzt werden.
Bei der Erstellung eines komplexen ausführbaren Programms treten teilweise Probleme auf, die erst nach dem Verlinken der einzelnen Programmmodule bei einem Testlauf festgestellt werden. Üblicherweise wird daher ein compiliertes und verlinktes ausführbares Programm mehreren Testläufen unterzogen. Gemäß einer zweckdienlichen Weiterbildung wird daher zunächst ein erstes ausführbares Programm als erstes Betriebssystem auf herkömmlichem Wege erzeugt, um somit ein zuverlässig funktionierendes Betriebssystem bereitzustellen. Aus diesen wird in einem zweiten Schritt dann erst das chipindividuelle Betriebssystem mit Hilfe des eigentlichen Linkers erzeugt. Durch die Bereitstellung eines ersten Betriebssystems ist bereits eine gewisse Programm-Struktur vorgegeben, auf die der Linker dann zurückgreift. Es ist daher bei der Erstellung des jeweiligen chipindividuellen Betriebssystems keine vollständige Neustrukturierung des gesamten Programmcodes des Betriebssystems erforderlich, so dass die Menge der zu übergebenden Daten bei der Erstellung des chipindividuellen Betriebssystems gering gehalten ist.
Dies ist insbesondere bei der Ausführungsvariante von Bedeutung, bei der der Linker als ein On-Board-Linker unmittelbar auf der Chipkarte integriert ist. Zur Erzeugung des chipindividuellen Betriebssystems aus dem ersten Betriebssystem ist dabei zweckdienlicherweise ein Aufbereiter vorgesehen, welcher auch als Template-Generator bezeichnet wird. Dieser erstellt aus dem ersten Betriebssystem ein Vorlagenmuster, welches einerseits die einzelnen Programmmodule und andererseits Informationen über deren wechselseitigen Verknüpfungen enthält. Anhand dieses Vorlagenmusters erstellt dann der Linker das chipindividuelle Betriebssystem. Es wird also auf die Erkenntnisse des getesteten ersten Betriebssystems insofern zurückgegriffen, als ein Vorlagenmuster oder auch Schnittmuster vorgegeben wird, welches eine Grobstruktur des Aufbaus des Betriebssystems vorgibt.
Da einzelne Programmmodule typischerweise unterschiedliche Größen aufweisen, gibt dieses Vorlagenmuster insbesondere an, an welcher Stelle Programmmodule mit welcher Größe anzuordnen sind. So kann der Linker beispielsweise Programmmodule gleicher Größer an den für diese Größe definierten Orten verteilen. Anhand der ihm weiterhin zur Verfügung gestellten Informationen über deren wechselseitigen Verknüpfungen vergibt er dann die entsprechenden Verknüpfungsinformationen wie beispielsweise Sprungmarken entsprechend der dann gewählten Anordnung der einzelnen Programmmodule in dem Vorlagenmuster.
In zweckdienlicher Weiterbildung ist dabei vorgesehen, dass lediglich ein Teil der Programmmodule, insbesondere ähnliche oder gleichartige, die beispielsweise hinsichtlich ihrer Größe zumindest vergleichbar oder identisch sind, zur Ausbildung des chipspezifischen Betriebssystems vom Linker unterschiedlich angeordnet, also permutiert werden. Die übrigen Programmmodule werden also insbesondere auch mit ihren wechselseitigen Verknüpfungen unverändert gegenüber dem ersten, getesteten Betriebssystem beibehalten.
Der Aufbereiter ersetzt dabei die von dem Compilerlinker erzeugten konkreten Verknüpfungen für diese ausgewählten Programmmodule durch Verknüpfungshinweise und übergibt diese Hinweise dem Linker als zusätzliche Informationen. Anhand dieser Verknüpfungshinweise nimmt der Linker die korrekten Verknüpfungen wieder vor. Der Aufbereiter identifiziert daher vorzugsweise lediglich einige der Programmmodule, beispielsweise anhand einer definierten, einheitlichen Größe, entfernt die im Programmcode des ersten Betriebssystems enthaltenen konkreten Verknüpfungshinweise (Sprungmarken) und nimmt diese in die ergänzenden Informationen für den Linker auf.
In zweckdienlicher Weiterbildung weisen die Programmmodule (M) zumindest eine einheitliche Modulgröße oder auch mehrere einheitliche Modulgrößen auf, bzw. werden auf eine oder mehrere einheitliche Modulgrößen gebracht, bevor sie über den Verlinker chipindividuell verlinkt werden. Hierdurch wird die Anzahl der möglichen Permutationen erhöht. Denn bei unterschiedlichen Modulgrößen sind die Programmmodule üblicherweise nicht beliebig miteinander permutierbar, da z.B. Positionen durch das Vorlagenmuster in Abhängigkeit der Größe vorgegeben sind. Unter Modulgröße wird hierbei insbesondere der Speicherbedarf des jeweiligen Moduls, also die Byte-Größe verstanden.
In der Regel weisen nämlich die einzelnen Programmmodule aufgrund ihres üblicherweise unterschiedlichen Funktionsumfangs unterschiedliche Modulgrößen auf. Um die Modulgröße zu vereinheitlichen werden insbesondere kleine Module vergrößert, indem beispielsweise Leerinformationen hinzugefügt werden. Große Module können geteilt und wenn erforderlich anschließend wieder auf die gewünschte einheitliche Modulgröße vergrößert werden.
Beim Zusammensetzen der einzelnen Programmmodule wird seitens des Linkers vorzugsweise das Zufallsprinzip angewandt, d.h. der Linker enthält einen Zufallsgenerator, welcher bestimmt, welche Programmmodule in welcher Reihenfolge wie aneinander gereiht werden. Dies erfolgt unter der Prämisse, dass die gewünschte Gesamt-Funktionalität und Funktionsfähigkeit erhalten wird, so dass auf allen Chips funktional die identische Sicherheits-Betriebssoftware enthalten ist. Zweckdienlicherweise liegt die Anzahl der einzelnen Programmmodule für das Sicherheits-Betriebssystem bei > 50 und insbesondere bei > 100. Üblicherweise ist eine höhere Anzahl sinnvoll, um die Größe der einzelnen Module geeignet zu begrenzen. In Kombination mit dem Zufallsprinzip ergeben sich daher eine sehr große Anzahl an verschiedenen Kombinationen, so dass ein Re-Engineering quasi unmöglich ist.
In zweckdienlicher Weiterbildung ist darüber hinaus auf dem Chip ein sogenannter Boot-Loader integriert, der für die Kommunikation nach außen zuständig ist und der insbesondere auch die Programmmodule vom Compiler-Rechner erhält. Der Linker erhält die Programmmodule vom Boot-Loader und verlinkt sie anschließend zum chipindividuellen Betriebssystem, welches anschließend vom Linker in den nicht-flüchtigen Speicher (insbesondere Flash-Speicher) eingelesen wird.
Alternativ ist es grundsätzlich auch möglich, dass die Programmmodule zunächst direkt in den Flash-Speicher eingelesen und erst anschließend vom Linker zum chipindividuellen Betriebssystem zusammengesetzt werden.
Sowohl beim Boot-Loader als auch beim Linker handelt es sich daher selbst wiederum um ausführbare Programme, denen gewisse Funktionalitäten zugewiesen sind. Der Boot-Loader und/oder der Linker sind vorzugsweise ebenfalls im Flash- Speicher enthalten. Alternativ können diese jedoch auch in einem ROM-Speicher abgelegt sein.
Vorzugsweise wird das chipindividuelle Betriebssystem parallel auf mehreren Chips erzeugt. Hierzu ist insbesondere eine gemeinsame Kontaktierungs- und Datenübertragungseinheit vorgesehen, über die insbesondere ein Energie- und Kommunikationskanal bereitgestellt wird, so dass parallel und gleichzeitig die Übertragung der Programmmodule oder des Template -Betriebssystems auf die einzelnen Chips erfolgt. Auf den einzelnen Chips wird dann von dem jeweiligen Linker das chipindividuelle Betriebssystem erzeugt. Mehrere einzelne Chips werden üblicherweise gemeinsam auf einem Wafer erzeugt. Zweckdienlicherweise sind die einzelnen Chips auf dem Wafer zur Ausbildung einer vereinfachten Kontaktierungs- und Übertragungseinheit miteinander verschaltet. Der Kommunikationskanal - oder Pfad ist daher bereits auf Seiten des Wafers ausgebildet. Bevorzugt in solchen Bereichen des Wafers, an denen bei der weiteren Bearbeitung die einzelnen Chips mechanisch voneinander getrennt werden. Die Übertragung der Programmmodule erfolgt daher vor dem Auseinandertrennen der Waferscheibe.
Dieser Aspekt der parallelen Übertragung der Programmmodule, insbesondere auch mit der Integration des Kommunikationskanals in den Wafer, wird als eigenständige Erfindung angesehen. Die Einreichung einer Teilanmeldung auf diesen Aspekt - unabhängig von der Erzeugung des chipindividuellen Betriebssystems bleibt vorbehalten.
Ein Ausführungsbeispiel der Erfindung wird nachfolgend anhand der Figuren näher erläutert. Es zeigen jeweils in einer vereinfachten Darstellung anhand eines Blockbildes
Fig. 1 den grundsätzlichen Verfahrensablauf zur Erstellung eines Satzes von Chipkarten mit chipindividuellen Betriebssystemen gemäß einer ersten Variante und
Fig. 2 den Verfahrensablauf gemäß einer zweiten Variante.
Gemäß einer ersten, zu Figur 1 beschriebenen Ausführungsvariante werden zunächst von einem ersten Dienstleister D1 einzelne Programmmodule M einer Betriebssoftware OS programmiert und anschließend einem Compiler-Rechner 2 zugeführt, in dem die einzelnen Programmmodule M zu den Programmmodulen M1 in einen maschinenlesbaren Code compiliert werden. Diese compilierten Programmmodule M1 werden gemäß der ersten in der Figur 1 dargestellten Variante anschließend verschlüsselt und in einer Datendatei F (IW) als verschlüsselter Datensatz bereitgestellt. Dieser verschlüsselte Datensatz F (Μ') wird einem zweiten Dienstleister D2, üblicherweise ein mit der Herstellung der einzelnen Chipkarten beauftragter Dienstleister übermittelt. Dieser stellt eine Vielzahl von Chipkarten 4 mit einem integrierten Chip 6 zur Verfügung, welcher einen Mikroprozessor 8 sowie einen nicht flüchtigen, beschreibbaren Speicher 10 (Flash-Speicher) aufweist. Der Speicher 10 weist bei der hier beschriebenen Ausführungsvariante einen Boot Loader 12 sowie einen Linker 14 auf, die als ausführbare Programme ausgebildet sind und beispielsweise bereits vorinstalliert sind. Das Programm des Boot Loaders 12 und/oder des Linkers 14 wird vorzugsweise ebenfalls in einer separaten, verschlüsselten Datei (einmalig) vom Software-Dienstleister D1 übermittelt. Alternativ hierzu ist der Linker 14 in der verschlüsselten Datei F(M') enthalten. Die Leistungen der Dienstleister D1.D2 können auch an einem Ort von einem gemeinsamen Dienstleister vorgenommen werden.
Die verschlüsselte Datei F (Μ') wird von einem Lade-Rechner 16 des Dienstleisters D2 empfangen. Dieser ist mit einem hier nicht näher dargestellten Kartengerät verbunden, um die Daten in den Speicher 10 zu übertragen. Die Kommunikation wird hierbei vorzugsweise über den Boot Loader 12 vorgenommen, der also vom Laderechner 16 die verschlüsselte Datei F (Μ') erhält, die verschlüsselten Programmmodule M' wieder entschlüsselt und dem Linker 14 zur Verfügung stellt. Mit Hilfe eines Zufallsgenerators setzt der Linker 14 dann die einzelnen Programmmodule M zu einem chipindividuellen Betriebssystem C-OS zusammen und legt dies in einem entsprechenden Speicherbereich des Speichers 10 ab. Alle Tätigkeiten des Boot Loaders 12 und des Linkers 14 werden hierbei über den Mikroprozessor 8 gesteuert.
Gemäß einer bevorzugten, in Fig. 2 dargestellten Alternative ist neben dem eigentlichen Linker 14 ein erster Linker, als Compilerlinker 18 bezeichnet, vorgesehen, der die Programmmodule M zu den Programmmodulen M' compiliert. Zusätzlich ist der Compilerlinker 18 als Linker ausgebildet, der vor dem Übertragen der Programmmodule M' auf den Chip 6 diese zu einem ersten Betriebssystem OS verlinkt. Alternativ können die beiden Funktionen des Compilierens und des Ver- linkens auch in getrennten Funktionseinheiten ausgeführt werden. Beim Verlinken werden die einzelnen Programmmodule M' in einer definierten Reihenfolge aneinandergereiht, wie dies in der FIG 2 durch Ziffern dargestellt ist.
Aus diesem ersten Betriebssystem OS wird mit Hilfe eines Aufbereiters 20 eine Art Vorlagenmuster V erzeugt, welches zusammen mit ergänzenden Informationen I in der zu übertragenden Datei F (M',V,I) zusammengefasst werden. In einem ersten Schritt identifiziert der Aufbereiter 20 einzelne Programmmodule M', vorzugsweise solche, die miteinander insbesondere im Hinblick auf ihre Größe gleich oder identisch sind. Zweckdienlicherweise identifiziert er dabei nur einen gewissen Teil der Programmmodule M', nachfolgend als ausgewählte Programmmodule M' bezeichnet, die im Vorlagenmuster V durch schwarze Punkte markiert sind. Zu diesen ausgewählten Programmmodulen M' entfernt der Aufbereiter 20 die im Programmcode des Betriebssystems OS enthaltenen konkreten Verlinkungen zwischen den einzelnen Programmmodulen M' und schreibt diese Verknüpfungsinnformation in die ergänzend übertragenen Informationen I. Die restlichen Programmmodule M' bleiben unberührt, d.h. sowohl ihre Position im Programmcode als auch ihre wechselseitigen Verlinkungen bleiben unangetastet.
Der Linker 14 erhält schließlich dieses Vorlagenmuster V mit den zugehörigen Informationen I und den Programmmodulen M'. Der Linker 14 verlinkt nunmehr lediglich die ausgewählten Programmmodule M' entsprechend eines Zufallsprinzips neu und vergibt die entsprechenden Verlinkungsinformationen. Bei dieser in -Fig. 2 dargestellten Ausführungsvariante permutieren daher lediglich die ausgewählten gleichartigen, insbesondere gleichgroßen Programmmodule M' auf ihren jeweiligen Positionen innerhalb des Betriebssystems OS. Schließlich wird wieder das chipspezifische Betriebssystem C-OS erhalten, bei dem allerdings nur ein Teil der Programmmodule M' von Chipkarte 4 zu Chipkarte 4 permutiert ist, wie dies durch die Ziffernabfolge der Programmmodule M' des chipindividuellen Betriebssystems C-OS in Fig. 2 illustriert ist.
Die Vorgang der Erzeugung des chipindividuellen Betriebssystems C-OS wird für jede einzelne Chipkarte 4 eines Chipkarten-Systems mit einer Vielzahl (mehrere tausend) von Chipkarten 4 eines System-Anbieters wiederholt, d.h. die verschlüs- selte Datei F (Μ') braucht nur einmal zum Chipkartenhersteller D2 übertragen werden. Der Laderechner 16 übermittelt diese geschützte Datei F (Μ') an jeden einzelnen Speicher 10 der Chipkarten 4. Alle Chipkarten des Chipkarten-Systems weisen die im Hinblick auf die Funktionalität identische Betriebssoftware OS auf, die sich jedoch durch die chipindividuelle Ausgestaltung im Hinblick auf ihren strukturellen Aufbau, also der Abfolge der Programmmodule M unterscheiden.
Durch den Zufallsgenerator ist sichergestellt, dass so gut wie keine Chipkarte 4 ein identisches chipindividuelles Betriebssystem C-OS aufweist. Ein ReEngineering ist dadurch quasi ausgeschlossen.
Bezugszeichenliste
2 Compiler-Rechner
4 Chipkarte
6 Chip
8 Mikroprozessor
10 Flash-Speicher
12 Boot Loader
14 Linker
16 Laderechner
18 Compilerlinker
20 Aufbereiter
M Programmmodule
* compilierte Programmmodule
F (M') verschlüsselte Datei
OS Betriebssystem
C-OS chipindividuelles Betriebssystem
D1 Dienstleister 1 (Softwareentwickler)
D2 Dienstleister 2 (Chipkartenhersteiler)
V Vorlagemuster
I Informationen

Claims

Ansprüche
1. Verfahren zur Bereitstellung von Chips (6) mit hohem Re-Engineering-
Schutz, insbesondere für digitale Authentifizierungseiemente wie Chipkarten (4) oder dergleichen, bei dem
für die Chips (6) ein Sicherheits-Betriebssystem (OS) vorgesehen ist, das aus einzelnen miteinander verknüpften Programmmodulen (Μ') aufgebaut ist, dadurch gekennzeichnet,
dass die einzelnen Programmmodule (Μ') mit Hilfe eines Linkers (14) für verschiedene Chips (6) unterschiedlich miteinander kombiniert werden, so dass für einen jeweiligen Chip (6) ein chipindividuelles Betriebssystem (C-OS) erzeugt und in einen Speicher ( 0) des Chips (6) eingelesen wird, wobei die chipindividuellen Betriebssysteme (C-OS) die gleiche Funktionalität jedoch einen unterschiedlichen strukturellen Aufbau aufweisen.
2. Verfahren nach Anspruch 1 ,
dadurch gekennzeichnet,
dass das chipindividuelle Betriebssystem (C-OS) in einen Flash-Speicher (10) eingelesen wird.
3. Verfahren nach Anspruch 1 oder 2,
dadurch gekennzeichnet,
dass der Linker (14) im Chip (6) integriert ist.
4. Verfahren nach einem der Ansprüche 1 bis 3,
dadurch gekennzeichnet,
dass der Linker (14) auch zum nachträglichen Ändern des chipindividuellen Betriebssystems (C-OS) ausgebildet ist.
5. Verfahren nach einem der Ansprüche 1 bis 4,
dadurch gekennzeichnet ,
dass die Programmmodule (Μ') als verschlüsselter Datensatz auf den Chip (6) übertragen werden.
6. Verfahren nach einem der Ansprüche 1 bis 5,
dadurch gekennzeichnet,
dass ein Compilerlinker (18) vorgesehen ist, der die Programmmodule (Μ') zu einem ersten Betriebssystem (OS) verlinkt, aus dem dann der Linker (14) das chipindividuelle Betriebssystem (C-OS) erzeugt.
7. Verfahren nach Anspruch 6,
dadurch gekennzeichnet ,
dass ein Aufbereiter (20) vorgesehen ist, der aus dem ersten Betriebssystem (OS) ein Vorlagenmuster (V) erzeugt, welches einerseits die einzelnen Programmmodule (IW) und andererseits Informationen (I) über deren wechselseitigen Verknüpfungen enthält, wobei der Linker (14) anhand des Vorlagenmusters (V) das chipindividuelle Betriebssystem (C-OS) erstellt.
8. Verfahren nach Anspruch 6 oder 7,
dadurch gekennzeichnet ,
dass der Linker (14) nur einen Teil der Programmmodule (Μ') gegenüber dem ersten Betriebssystem (OS) zur Ausbildung des chipspezifischen Betriebssystems (C-OS) permutiert.
9. Verfahren nach einem der vorhergehenden Ansprüche, insbesondere nach Anspruch 8
dadurch gekennzeichnet,
dass die Programmmodule (M!), insbesondere der Teil der Programmmodule (IW), der vom Linker (14) permutiert wird, eine einheitliche Modulgröße auf- weisen und / oder nachträglich auf eine einheitliche Modulgröße gebracht werden.
10. Verfahren nach einem der Ansprüche 1 bis 8,
dadurch gekennzeichnet,
dass der Linker (14) die Programmmodule (Μ') nach dem Zufallsprinzip insbesondere mit Hilfe eines Zufallsgenerators zusammensetzt.
11. Verfahren nach einem der Ansprüche 1 bis 9,
dadurch gekennzeichnet ,
dass die Anzahl der Programmmodule (M1) >50 und insbesondere >100 ist.
12. Verfahren nach einem der Ansprüche 1 bis 8,
dadurch gekennzeichnet ,
dass auf dem Chip (6) ein Boot Loader (12) integriert ist, der die Programmmodule (Μ') empfängt
13. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
dass parallel auf mehreren Chips (6) das chipindividuelle Betriebssystem (C- OS) erzeugt wird.
14. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
dass mit Hilfe einer gemeinsamen Kontaktier- und Übertragungseinheit die Programmmodule (Μ') parallel auf mehrere Chips (6) übertragen werden.
15. Chips (6), hergestellt mit einem Verfahren nach einem der vorhergehenden Ansprüche.
PCT/EP2013/002251 2012-08-02 2013-07-30 Verfahren zur bereitstellung von chips mit hohem re-engineering-schutz, insbesondere für digitale authentifizierungssysteme, wie chipkarten oder dergleichen, sowie danach hergestellte chips Ceased WO2014019679A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE102012213745.9 2012-08-02
DE102012213745 2012-08-02
DE102012024250.6A DE102012024250B4 (de) 2012-08-02 2012-12-12 Verfahren zur Bereitstellung von Chips mit hoher Kopierschutzfunktion, insbesondere für digitale Authentifizierungssysteme, wie Chipkarten oder dergleichen, sowie danach hergestellte Chips
DE102012024250.6 2012-12-12

Publications (1)

Publication Number Publication Date
WO2014019679A1 true WO2014019679A1 (de) 2014-02-06

Family

ID=49943859

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2013/002251 Ceased WO2014019679A1 (de) 2012-08-02 2013-07-30 Verfahren zur bereitstellung von chips mit hohem re-engineering-schutz, insbesondere für digitale authentifizierungssysteme, wie chipkarten oder dergleichen, sowie danach hergestellte chips

Country Status (2)

Country Link
DE (1) DE102012024250B4 (de)
WO (1) WO2014019679A1 (de)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0929040A2 (de) 1997-12-25 1999-07-14 Nippon Telegraph and Telephone Corporation Mikroprozessor mit Datenverschleierung
WO2002069118A2 (de) * 2001-02-22 2002-09-06 Giesecke & Devrient Gmbh Verfahren und system zur verteilten erstellung eines programms für einen programmierbaren, tragbaren datenträger
DE102004058882A1 (de) 2004-12-06 2006-06-08 Giesecke & Devrient Gmbh Erzeugen von Programmcode in einem Ladeformat und Bereitstellen von ausführbarem Programmcode
EP2249291A1 (de) 2009-05-07 2010-11-10 Masktech GmbH Verfahren zur Erhöhung der Sicherheit einer bestehenden kontaktlosen Chipkartentechnik
WO2011120122A1 (en) * 2010-03-31 2011-10-06 Irdeto Canada Corporation Method for linking and loading to protect applications

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0929040A2 (de) 1997-12-25 1999-07-14 Nippon Telegraph and Telephone Corporation Mikroprozessor mit Datenverschleierung
US6526511B1 (en) * 1997-12-25 2003-02-25 Nippon Telegraph And Telephone Corporation Apparatus and method for modifying microprocessor system at random and maintaining equivalent functionality in spite of modification, and the same microprocessor system
WO2002069118A2 (de) * 2001-02-22 2002-09-06 Giesecke & Devrient Gmbh Verfahren und system zur verteilten erstellung eines programms für einen programmierbaren, tragbaren datenträger
DE102004058882A1 (de) 2004-12-06 2006-06-08 Giesecke & Devrient Gmbh Erzeugen von Programmcode in einem Ladeformat und Bereitstellen von ausführbarem Programmcode
EP2249291A1 (de) 2009-05-07 2010-11-10 Masktech GmbH Verfahren zur Erhöhung der Sicherheit einer bestehenden kontaktlosen Chipkartentechnik
WO2011120122A1 (en) * 2010-03-31 2011-10-06 Irdeto Canada Corporation Method for linking and loading to protect applications

Also Published As

Publication number Publication date
DE102012024250A1 (de) 2014-02-06
DE102012024250B4 (de) 2023-04-13

Similar Documents

Publication Publication Date Title
EP1818844B1 (de) Verfahren zur Benutzung von Sicherheitstoken
DE102014220616A1 (de) Verfahren zum Laden von ausführbaren Programminstruktionen in eine Chipkarte im Wirkbetrieb
DE10023820B4 (de) Software-Schutzmechanismus
DE10238095B4 (de) Verfahren zum Schutz vor Manipulationen an einem Steuergerät für mindestens eine Kfz-Komponente und Steuergerät
EP2864871B1 (de) Verfahren und vorrichtung zum austausch des betriebssystems eines ressourcenbeschränkten tragbaren datenträgers
DE69521399T2 (de) Einrichtung zur Sicherung von Informationssystemen, die auf der Basis von Mikroprozessoren organisiert sind
DE10324337A1 (de) Rechnersystem sowie zugehörige Speicherarchitektur und zugehöriges Verfahren zum Durchführen eines Sicherheitsprogramms
EP2510475B1 (de) Hardware-einrichtung
DE10340411B4 (de) Vorrichtung und Verfahren zur sicheren Ausführung eines Programms
DE10340861A1 (de) Prozessorschaltung und Verfahren zum Zuordnen eines Logikchips zu einem Speicherchip
WO2004114131A1 (de) Verfahren zum nachladen einer software in den bootsektor eines programmierbaren lesespeicher
DE10218795A1 (de) Verfahren zum Herstellen eines elektronischen Sicherheitsmoduls
EP3224756B1 (de) Verfahren zum nachladen von software auf eine chipkarte durch einen nachladeautomaten
DE19716015A1 (de) Einbringen von Information auf einer Chipkarte
WO2014019679A1 (de) Verfahren zur bereitstellung von chips mit hohem re-engineering-schutz, insbesondere für digitale authentifizierungssysteme, wie chipkarten oder dergleichen, sowie danach hergestellte chips
WO2010089083A2 (de) Vorrichtung und verfahren zum verhindern von unautorisierter verwendung und/oder manipulation von software
DE102004011488B4 (de) Schutz von Software gegen Angriffe
DE60216106T2 (de) Geschützte lesung von rechnerbefehlen in einem datenverarbeitungssystem
EP2524333A1 (de) Verfahren zum bereitstellen eines sicheren zählers auf einem endgerät
DE102005046696B4 (de) Verfahren zum Erzeugen von geschütztem Programmcode und Verfahren zum Ausführen von Programmcode eines geschützten Computerprogramms sowie Computerprogrammprodukt
DE102007041873A1 (de) Installieren eines Patch in einem Smartcard-Modul
DE102005056357A1 (de) Multithreading-fähige virtuelle Maschine
DE19834486A1 (de) Verfahren und Datenverarbeitungsanordnung zum gesicherten Ausführen von Befehlen
DE102012025260A1 (de) Verfahren zum Betreiben eines portablen Datenträgers sowie ein solcher portabler Datenträger
DE102005027709A1 (de) Verfahren zum Betreiben eines tragbaren Datenträgers

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: 13752820

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: 13752820

Country of ref document: EP

Kind code of ref document: A1