WO2006000584A1 - Module de sécurité et méthode de personnalisation d'un tel module de sécurité - Google Patents

Module de sécurité et méthode de personnalisation d'un tel module de sécurité Download PDF

Info

Publication number
WO2006000584A1
WO2006000584A1 PCT/EP2005/052988 EP2005052988W WO2006000584A1 WO 2006000584 A1 WO2006000584 A1 WO 2006000584A1 EP 2005052988 W EP2005052988 W EP 2005052988W WO 2006000584 A1 WO2006000584 A1 WO 2006000584A1
Authority
WO
WIPO (PCT)
Prior art keywords
computer codes
codes
dummy
module
security module
Prior art date
Application number
PCT/EP2005/052988
Other languages
English (en)
Inventor
Philippe Stransky
Original Assignee
Nagracard S.A.
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=34929271&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=WO2006000584(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Nagracard S.A. filed Critical Nagracard S.A.
Priority to ES05771823T priority Critical patent/ES2375484T3/es
Priority to CA002572023A priority patent/CA2572023A1/fr
Priority to JP2007518597A priority patent/JP2008504617A/ja
Priority to AT05771823T priority patent/ATE530975T1/de
Priority to KR1020067027797A priority patent/KR101226854B1/ko
Priority to EP05771823A priority patent/EP1761835B1/fr
Publication of WO2006000584A1 publication Critical patent/WO2006000584A1/fr

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
    • 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/73—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 creating or determining hardware identification, e.g. serial numbers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • 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

Definitions

  • the present invention relates to the field of secure security modules comprising at least one microprocessor and a program memory.
  • the invention also relates to the personalization of such a security module and the identification of a security module whose content has been made public.
  • These security modules are used in systems implementing cryptographic operations and are delivered in one-piece form. They are either made on a single silicon chip, or assembled on a support and embedded in a resin or protected by a sheet covering the various elements and acting as a fuse in case of attempted intrusion.
  • These secure modules have a program memory containing in particular a startup program and one or more operational programs.
  • the startup program is executed when the processor is switched on or at each. reset.
  • This startup program is stored in a ROM type memory that is to say that the access can be read only.
  • the operational program is stored in a rewritable type memory, generally EEPROM type, NVRAM or Flash.
  • One of the known attacks to discover the contents of the memory of a security module is to look for a security flaw such as a memory overflow that would allow to take control of the processor. Once this takeover is successful, it is possible to transfer the contents of the memory to the outside and to analyze the security mechanism and the keys used.
  • One of the ways to limit these illegal activities is to increase the security of the modules, so that it is particularly difficult to violate the security of this module.
  • Another way to severely limit these illegal activities is to detect the security module whose security has been violated and have allowed cloning and to act on this module by disabling it and clones it has allowed to achieve.
  • the present invention proposes to use the second means mentioned above, that is to say it proposes to introduce into the module, a means for detecting the module used for fraud.
  • each security module has a unique identification number.
  • those able to retrieve the computer codes of a security module are also able to detect the unique number of their module, from a relatively summary analysis of the contents of this module. This unique number is not published when publishing computer codes. This prevents on the one hand that one identifies the malicious person and on the other hand that one deactivates the module of origin and its clones.
  • the object of the present invention is to propose a method and a security module comprising means for identifying the security module during illegal publication of the code of this module, even though the malicious third party would have removed the identifier of this module. module.
  • the fight against the cloning of security modules is not therefore to improve the security of these modules, but to facilitate the detection of modules used for cloning, so as to render inoperative these modules.
  • European Patent EP 1 178 406 describes a method in which a unique serial number of a printed circuit is stored in a memory.
  • the serial number is first read from a bar code and then converted to digital information. This information is possibly encrypted before being introduced in one or more memories.
  • the object of the invention is, on the one hand, to make the detection of the serial number difficult and, on the other hand, to prevent an unauthorized person from knowing and modifying this serial number.
  • To hide the serial number it is stored in a large memory, so that it is difficult to locate among all other stored information. To prevent knowing and changing the number, it is encrypted.
  • the serial number is stored as a value in a given location of the memory. If a person or group of people determines the location of the serial number, that location may be made public. When publishing the computer code necessary to create a clone security module, it will suffice avoid publishing the contents of this location to prevent its security module from being detected.
  • a security module comprising a microprocessor, a program memory containing at least one operational program and a unique identification means of said module, characterized in that this identification means consists of a set of dummy computer codes, compatible with its execution by said microprocessor of the module and stored in the program memory.
  • This goal is also achieved by a method of customizing a security module by a unique identifier, this module comprising a microprocessor and a program memory containing at least one operational program, characterized in that it comprises the following steps: - generation a unique set of computer codes, called dummy computer codes, - writing this set of codes in the program memory in specific memory locations.
  • the object of the invention is also achieved by a method of identifying a security module as defined in any one of claims 1 to 6 and whose computer codes have been made accessible to the public, this method comprising the steps of: - extraction of dummy computer codes from computer codes made available to the public; processing said dummy computer codes according to predefined rules so as to deduce the identification means from said security module.
  • the main advantage of the personalization method of the invention is that the dummy computer codes are considered by a malicious third party to be part of the program and therefore seem necessary for the reproduction of a clone module.
  • the security module according to the invention and the associated method make it possible to induce a malicious person who has published the computer codes of a hacked security module to also publish the information that makes it possible to determine the number or a unique identification number of the security code. security module. With this, it is relatively easy to determine the origin of the original security module. From there, there are methods to make this original module inoperative as well as the clones it has made possible. One of these methods is for example described in the European patent application EP 04100969.7 of the same applicant.
  • FIG. 1 generally illustrates a security module according to the present invention
  • FIG. 2 represents a first embodiment of a portion of the security module of FIG. 1;
  • FIG. 3 illustrates a second embodiment of the security module of FIG. 1; and FIG. 4 illustrates a particular embodiment of the method of the invention.
  • the security module SM is a secure processor module. As such, it has at least one CPU microprocessor and a program memory containing in particular an operational program.
  • the program memory contains a first zone Z1 for starting and a second zone Z2 called working zone.
  • the first boot area is constituted by all or part of ROM memory so not rewritable. It may be that a part includes memory places in RAM or EEPROM for variables among others. It is called "start" because it is the first to be executed when powering on the security module.
  • the security module can contain a unique identification number UA1 which can be stored in a read-only memory area.
  • This UA1 number is generally accessible by the user in the form of a serial number which can be printed on the security module itself or on additional documentation for example.
  • Work area Z2 contains the operational program and the data. This zone consists of nonvolatile memory, but with the possibility of writing such as EEPROM. Zone Z2 may also contain volatile memory as RAM. In fact, this zone is generally not homogeneous and can include several memories of the ROM, RAM, EEPROM, NVRAM or Flash type.
  • the microprocessor CPU is automatically directed to the first zone Z1 when switching on or restarting (reset). This is where the first security operations are executed. These operations will use the first memory area, but also the Z2 work area if necessary.
  • the I / O block illustrates the means of communication towards the outside of the SM module, indispensable means for using the cryptographic functions and the rights stored in the memory. It is also through this that data are accidentally extracted from zone Z2 by a security breach as described above.
  • the work area Z2 contains the operational program for operating the module.
  • One embodiment of the structure of the operational program is illustrated in detail in FIGS. 2 and 3.
  • This operational program is composed of computer codes that can be represented in the form of instruction lines having definite functions if the we place our before the compilation of such a program.
  • the first type corresponds to conventional instructions called real lines, which are executed by the microprocessor according to defined criteria and which produce a result "useful" for the operation of the program.
  • the second type of instructions are instructions that are not actually executed by the microprocessor and / or that do not produce results directly.
  • These lines of instructions, called dummy lines in the rest of the text are instead used to form a unique identification means UA2 associated with the security module in question.
  • dummy lines can be either instructions that are not not executed by the microprocessor, either instructions that are actually executed, but that do not produce results that influence the progress of the operational program. In other words, the operation of the program is the same whether these codes are present or not.
  • the terms "dummy codes” or “dummy lines” should be understood as covering both of these embodiments.
  • the operational program comprises a number of actual instruction blocks B1, B2, which can form program routines, as well as a set of dummy computer codes, forming an instruction block B3, which has the same appearance as a conventional instruction block, but which is however different for each security module.
  • These computer codes are compatible for execution by the microprocessor and respond to the syntax of said microprocessor so that it is not possible, by a simple analysis of the codes, to identify the real codes, which will be executed, and the dummy codes. , which will not be executed or have any effect on the operational program.
  • the instructions contained in this dummy set are dummy lines that are not usually executed by the microprocessor or their execution does not influence the operation of the program; they are only used to form the unique identification means UA2 of the module.
  • the actual instructions are formed of real lines indicated by R in FIGS. 2 and 3 and the dummy lines are represented by the references F in these figures.
  • This instruction block B3 can preferably be inserted in the operational program to better hide itself.
  • the dummy computer codes used to form the identification means may also contain values of registers or variables for example.
  • the security module comprises, unlike the previous example in which the dummy lines are grouped together in the memory of the operational program, a certain number of dummy instruction lines. F, distributed among the real instructions R. These dummy lines form a set of unique and different computer codes for each security module.
  • the dummy lines include specific information indicating that the line in question is dummy and therefore should not be executed by the microprocessor.
  • certain real instructions contain indications relating to the location of the dummy lines.
  • Such an indication may for example be made in the form of an instruction indicating that a line arranged at a given memory location must not be processed.
  • Instructions to not handle dummy lines can be hidden, for example by indicating that the line in question should be skipped only if a condition is met. It is then possible to arrange for this condition to always be fulfilled. It is also possible to add to an actual line, an indication that the following line is dummy. According to another embodiment, nothing in the computer codes distinguishes a dummy line from a real line.
  • the security module contains stored information indicating the location of the computer codes that the microprocessor must not execute.
  • An alternative as briefly mentioned above may also consist of using as a dummy line, an instruction which is actually executed by the microprocessor, but which has no effect on the continuation of the execution of the program.
  • Such an instruction could be an indication that the program should move to the next line. It is of course possible to make this kind of "useless" instructions difficult to identify, for example by writing the instruction in the form of a conditional jump, indicating that the next line must be made only if a condition is fulfilled, while making sure that this condition is always fulfilled. Another form would be to send the program to any predetermined address if a condition is met, while making sure that this condition is never met. Another form would be to modify a rental memory that is known without significant.
  • These "useless" instructions are indicated in the text as "having no influence on the execution by the microprocessor, of the operational program", because these instructions can be deleted without the result of the execution of the program. operational level is affected.
  • dummy lines serve to identify the security module. Dummy lines that are not used to identify the security module are only present to complicate the understanding of the computer code and to prevent an attacker to detect what information he must publish if he wants to make a clone functional and what information it should omit if it does not want the unique identification number of its security module is also disclosed.
  • Such additional dummy lines can be inserted both in the embodiment in which the module includes a dummy block and in that where the instructions are scattered in the actual instructions.
  • the realization of the security module according to the invention comprises a personalization phase into which module-specific data are introduced.
  • the invention is also associated with a step of detecting a module whose computer codes have been published. This detection step consists in extracting, from the published information, the data specific to the security module.
  • the personalization method according to the invention essentially consists of generating a single set of computer codes, then writing these codes in the program memory.
  • This method of personalization depends first and foremost on the type of security module chosen and more particularly on the location of the dummy computer codes.
  • the dummy codes when the dummy codes are placed in the program memory in the form of a separate block, the dummy codes can be generated in the form of a block and then introduced into the module.
  • the actual codes forming the operational program are stored in such a way that they have free slots. Dummy codes are then generated and inserted into these free slots.
  • the dummy codes are codes actually executed by the microprocessor, these codes having however no effect on the progress of the operational program, it is possible to use a codebook.
  • This directory contains a set of pre-defined computer codes that do not influence the progress of the operational program. These codes can be, as indicated previously, a conditional jump, the writing of a value in a memory zone, the modification of a value or any other instruction which does not modify the progress of the program, that the instruction is executed or not.
  • the dummy codes of the security modules having the references SM1, SM2 and SM3 are respectively the sets (F1, F1, F3), (F3, F2, F4) and (F3, F3, F1).
  • the personalization process may further include a step to make the detection of artificial computer codes more complex.
  • a step to make the detection of artificial computer codes more complex when the dummy codes are grouped together in a given memory location in the form of a block, it is advisable to avoid that a simple comparison of the computer codes of two security modules whose security has been violated enables an attacker to locate dummy codes and thus avoid their publication.
  • an obfuscation or concealment step is well suited.
  • the step of detecting a module whose computer codes have been published as mentioned above consists in extracting, from the published information, the unique identification means of the module. security, on the one hand to possibly find the holder of the original module and on the other hand to render inoperative the module and the clones it has made possible.
  • This detection step essentially consists in comparing the published computer codes with those that were introduced in the security modules during the personalization phase. For this, different means are possible. In particular, a "line-by-line" comparison of the published codes and generated codes is possible. Another way to perform this comparison is to extract published codes, dummy codes, and then apply an operation to these dummy codes. A basic operation that can be performed is the concatenation of the bits forming the dummy codes. Another operation may consist in determining a signature (hash) of the instruction block. In fact, any operation for obtaining a single value from a single instruction block can be used. This same operation is applied to the computer codes generated during the personalization phase, then the unique values are compared.
  • the scattered dummy instructions are treated as in the previous case, illustrated in FIG. 2, so as to determine the unique identification means UA2 of the security module.
  • dummy computer codes for generating more than one identification means per security module.
  • a first means of identification could be constituted by a separate instruction block and other means of identification by scattered codes.
  • the same identification means UA2 is used not for a single security module, but for a group of security modules. This is interesting in the case where the group of modules belongs to the same person or more generally to the same entity.
  • a combination of the various embodiments above is also conceivable, that is to say for example that a security module may contain a first identification means common to a group of modules and a second identification means. unique per module.
  • the identification means UA2 can also be defined from computer codes representing values in registers.
  • the identification means UA2 replace the identification number UA1 conventionally contained in a security module.
  • the first identification number UA1 is present in the module and may for example be printed on the module if it has the form of a smart card or a key for example.
  • the identification means UA2 will be kept secret, as well as the very existence of a second identification number UA2.

Abstract

La présente invention concerne un module de sécurité comprenant un microprocesseur, une mémoire programme contenant au moins un programme opérationnel et un moyen d'identification unique dudit module. Ce module de sécurité est caractérisé en ce que le moyen d'identification est constitué d'un ensemble de codes informatiques unique et factice, compatible avec son exécution par ledit microprocesseur du module et stocké dans la mémoire programme. L'invention concerne également une méthode de personnalisation d'un module de sécurité par un identifiant unique, ce module comprenant un microprocesseur et une mémoire programme contenant au moins un programme opérationnel. La méthode de l'invention est caractérisée en ce qu'elle comprend les étapes de génération d'un ensemble unique de codes informatiques, dénommés codes informatiques factices, et d'écriture; de cet ensemble de codes dans la mémoire programme dans des emplacements mémoires spécifiques.

Description

MODULEDESÉCURITÉETMÉTHODEDEPERSONNALISATION D'UNTELMODULEDESÉCURITÉ
La présente invention concerne le domaine des modules de sécurité sécurisés comportant au moins un microprocesseur et une mémoire programme. L'invention concerne également la personnalisation d'un tel module de sécurité ainsi que l'identification d'un module de sécurité dont le contenu a été rendu public.
Ces modules de sécurité sont utilisés dans des systèmes mettant en œuvre des opérations cryptographiques et sont livrés sous forme monobloc. Ils sont soit réalisés sur une seule puce de silicium, soit assemblés sur un support et noyés dans une résine ou protégés par une feuille recouvrant les divers éléments et agissant comme fusible en cas de tentative d'intrusion.
Ces modules sécurisés ont une mémoire programme contenant en particulier un programme de démarrage et un ou des programmes opérationnels. Le programme de démarrage est exécuté lors de l'enclenchement du processeur ou à chaque. remise à zéro (reset). Ce programme de démarrage est stocké dans une mémoire de type ROM c'est-à-dire que l'accès peut se faire en lecture uniquement.
Le programme opérationnel est stocké dans une mémoire de type réinscriptible, en général de type EEPROM, NVRAM ou Flash.
Lorsque le programme de démarrage a terminé sa vérification, il débute l'exécution du programme opérationnel à une adresse convenue.
Une des attaques connues pour découvrir le contenu de la mémoire d'un module de sécurité est de rechercher une faille de sécurité telle qu'un débordement de mémoire qui permettrait de prendre le contrôle du processeur. Une fois cette prise de contrôle réussie, il est possible de transférer le contenu de la mémoire vers l'extérieur et d'analyser le mécanisme de sécurité et les clés utilisées.
A partir de la connaissance du contenu de la mémoire, on peut obtenir les clés servant à gérer les différents droits et accès aux services que contrôle le processeur. Ainsi, si un changement de clés intervient, ordonné par le centre de gestion, cette commande de changement sera encryptée par une clé présente dans la mémoire programme. En disposant de cette clé, on pourra décrypter le message de changement de clé et mettre également à jour le contenu de cette nouvelle clé.
On constate donc que lorsque la sécurité d'un module de sécurité a été violée une fois par une personne malveillante, tous les changements initiés par le centre de gestion sont sans effet sur la sécurité car les moyens de changement (nouvelle clé de transmission par exemple) utilisent des clés que cette personne a déjà en sa possession. Elle peut donc décrypter le message de mise à jour et changer également sa clé de transmission.
Lorsque la sécurité d'un module de sécurité a été violée et que le contenu de la mémoire programme est donc connu, il arrive que la personne malveillante ayant violé la sécurité de ce module publie les codes informatiques correspondant au contenu de la mémoire programme, cette publication étant notamment faite sur un réseau tel qu'Internet. Ceci permet à des tiers, possesseurs de cartes vierges, de copier ces codes et de créer ainsi des cartes clones parfaitement fonctionnelles, de façon totalement illégale.
L'un des moyens pour limiter ces activités illégales consiste à augmenter la sécurité des modules, de sorte qu'il est particulièrement difficile de violer la sécurité de ce module. Un autre moyen pour limiter fortement ces activités illégales consiste à détecter le module de sécurité dont la sécurité a été violée et ayant permis le clonage et d'agir sur ce module en le désactivant, lui et les clones qu'il a permit de réaliser.
Le document US 6,725,374 décrit un module de sécurité utilisant le premier moyen mentionné ci-dessus, à savoir l'amélioration de la sécurité par rapport aux modules antérieurs. En effet, dans le module décrit dans ce brevet, la découverte de clés est rendue plus difficile grâce à l'adjonction, dans le code informatique du module, d'éléments de "brouillage" qui brouillent des informations qui peuvent être utilisées pour extraire des clés, à savoir la consommation électrique. Ces éléments de brouillage sont formés de modules dont l'ordre d'exécution n'a pas d'importance pour le déroulement du programme. Ces éléments sont utilisés de façon aléatoire, de sorte que le traitement de deux signaux d'entrée identiques ne donnera pas deux signaux de sortie identiques. Si, malgré cette difficulté supplémentaire, une personne arrive à déterminer le contenu du module de sécurité, ce code pourra être publié et réutilisé par des tiers, sans qu'il soit possible de< retrouver la source du code publié.
La présente invention se propose d'utiliser le deuxième moyen mentionné ci-dessus, c'est-à-dire qu'elle propose d'introduire dans le module, un moyen permettant la détection du module ayant servi à une fraude.
De façon bien connue, chaque module de sécurité comporte un numéro d'identification unique. Généralement, les personnes capables d'extraire les codes informatiques d'un module de sécurité sont également capables de détecter le numéro unique de leur module, à partir d'une analyse relativement sommaire du contenu de ce module. Ce numéro unique n'est pas publié lors de la publication des codes informatiques. Ceci empêche d'une part que l'on identifie la personne malveillante et d'autre part que l'on désactive le module d'origine et ses clones.
L'objet de la présente invention est de proposer une méthode et un module de sécurité comportant des moyens d'identification du module de sécurité lors de publication illégale du code de ce module, quand bien même le tiers malveillant aurait retiré l'identifiant de ce module. Dans la présente invention, la lutte contre le clonage de modules de sécurité ne consiste donc pas à améliorer la sécurité de ces modules, mais à faciliter la détection des modules ayant servi au clonage, de façon à rendre inopérants ces modules.
Le brevet européen EP 1 178 406 décrit un procédé dans lequel un numéro de série unique d'un circuit imprimé est mémorisé dans une mémoire. Dans cette invention, le numéro de série est tout d'abord lu à partir d'un code barre, puis converti en informations numériques. Ces informations sont éventuellement chiffrées avant d'être introduites dans une ou plusieurs mémoires. Le but de l'invention est d'une part de rendre difficile la détection du numéro de série et d'autre part d'empêcher une personne non-autorisée de connaître et de modifier ce numéro de série. Pour cacher le numéro de série, il est mémorisé dans une mémoire de grande taille, de sorte qu'il est difficile à repérer parmi toutes les autres informations mémorisées. Pour empêcher de connaître et de modifier le numéro, il est chiffré.
Le fait de cacher le numéro de série ne permet pas de résoudre de façon satisfaisante le problème de l'invention. En effet, le numéro de série est mémorisé sous la forme d'une valeur dans un emplacement donné de la mémoire. Si une personne ou un groupe de personnes détermine l'emplacement du numéro de série, cet emplacement pourra être rendu public. Lors de la publication du code informatique nécessaire pour réaliser un module de sécurité clone, il suffira donc d'éviter de publier le contenu de cet emplacement pour éviter que son module de sécurité ne soit détecté.
Le but de l'invention est atteint par un module de sécurité comprenant un microprocesseur, une mémoire programme contenant au moins un programme opérationnel et un moyen d'identification unique dudit module, caractérisé en ce que ce moyen d'identification est constitué d'un ensemble de codes informatiques factice, compatible avec son exécution par ledit microprocesseur du module et stocké dans la mémoire programme.
Ce but est également atteint par une méthode de personnalisation d'un module de sécurité par un identifiant unique, ce module comprenant un microprocesseur et une mémoire programme contenant au moins un programme opérationnel, caractérisée en ce qu'elle comprend les étapes suivantes: - génération d'un ensemble unique de codes informatiques, dénommés codes informatiques factices, - écriture de cet ensemble de codes dans la mémoire programme dans des emplacements mémoires spécifiques.
Le but de l'invention est également atteint par une méthode d'identification d'un module de sécurité tel que défini dans l'une quelconque des revendications 1 à 6 et dont les codes informatiques ont été rendus accessibles au public, ce procédé comportant les étapes de : - extraction des codes informatiques factices parmi les codes informatiques rendus accessibles au public; - traitement desdits codes informatiques factices selon des règles prédéfinies de façon à en déduire le moyen d'identification dudit module de sécurité. La méthode de personnalisation de l'invention a pour principal avantage que les codes informatiques factices sont considérés par un tiers malveillant comme faisant partie du programme et semblent donc nécessaires à la reproduction d'un module clone.
Ces codes informatiques factices sont noyés dans le programme opérationnel, de sorte qu'il est difficile de repérer quelles sont les informations réellement nécessaires au bon fonctionnement du module et quelles sont celles utilisées pour générer le numéro d'identification.
Le module de sécurité selon l'invention et la méthode associée permettent d'inciter une personne malveillante ayant publié les codes informatiques d'un module de sécurité piraté à également publier les informations qui permettent de déterminer le numéro ou un numéro d'identification unique du module de sécurité. Grâce à ceci, il est relativement aisé de déterminer la provenance du module de sécurité d'origine. A partir de là, il existe des méthodes permettant de rendre inopérant ce module d'origine de même que les clones qu'il a permis de réaliser. L'une de ces méthodes est par exemple décrite dans la demande de brevet européen EP 04100969.7 du même déposant.
L'invention sera mieux comprise grâce à la description détaillée qui va suivre et qui se réfère aux dessins annexés qui sont donnés à titre d'exemple nullement limitatif, dans lesquels :
- la figure 1 illustre de façon générale un module de sécurité selon la présente invention;
- la figure 2 représente un premier mode de réalisation d'une partie du module de sécurité de la figure 1 ;
- la figure 3 illustre un deuxième mode de réalisation du module de sécurité de la figure 1 ; et - la figure 4 illustre un mode de réalisation particulier de la méthode de l'invention.
En référence à la figure 1 , le module de sécurité SM est un module processeur sécurisé. A ce titre, il dispose d'au moins un microprocesseur CPU et d'une mémoire programme contenant notamment un programme opérationnel. Dans le mode de réalisation représenté, la mémoire programme contient une première zone Z1 de démarrage et une seconde zone Z2 dite zone de travail. La première zone de démarrage est constituée par tout ou partie de mémoire ROM donc non réinscriptible. Il se peut qu'une partie comprenne des places mémoires en RAM ou EEPROM pour des variables entre autre. Elle est dite "de démarrage" du fait qu'elle est la première à être exécutée lors de la mise sous tension du module de sécurité.
De façon conventionnelle, le module de sécurité peut contenir un numéro unique d'identification UA1 qui peut être mémorisé dans une zone mémoire à lecture seule. Ce numéro UA1 est généralement accessible par l'utilisateur sous forme de numéro de série qui peut être imprimé sur le module de sécurité lui-même ou sur une documentation annexe par exemple.
La zone de travail Z2 contient le programme opérationnel et les données. Cette zone est constituée de mémoire non volatile, mais avec possibilité d'écriture telle que de l'EEPROM. La zone Z2 peut également contenir de la mémoire volatile comme de la RAM. En fait, cette zone n'est généralement pas homogène et peut comprendre plusieurs mémoires du type ROM, RAM, EEPROM, NVRAM ou Flash.
Le microprocesseur CPU est dirigé automatiquement sur la première zone Z1 lors d'un enclenchement ou un redémarrage (reset). C'est là que les premières opérations de sécurité sont exécutées. Ces opérations vont utiliser la première zone mémoire, mais également la zone de travail Z2 si nécessaire.
Sur la figure 1 , le bloc I/O illustre les moyens de communication vers l'extérieur du module SM, moyens indispensables pour utiliser les fonctions cryptographiques et les droits stockés dans la mémoire. C'est également par ce biais que des données sont extraites accidentellement de la zone Z2 par une faille de sécurité telle que décrite plus haut.
Comme indiqué précédemment, la zone de travail Z2 contient le programme opérationnel destiné au fonctionnement du module. Une forme de réalisation de la structure du programme opérationnel est illustrée de façon détaillée par les figures 2 et 3. Ce programme opérationnel est composé de codes informatiques que l'on peut représenter sous forme de lignes d'instructions ayant des fonctions déterminées si l'on se place avant la compilation d'un tel programme.
Pour la clarté de la description, il est supposé que les instructions sont réparties en blocs d'instructions référencés B1, B2, B3, qui répondent à <<* une syntaxe donnée.
Dans le module de l'invention, au moins deux types de lignes d'instructions coexistent. Le premier type correspond à des instructions conventionnelles dites lignes réelles, qui sont exécutées par le microprocesseur selon des critères définis et qui produisent un résultat "utile" pour le fonctionnement du programme. Le deuxième type d'instructions sont des instructions qui ne sont pas exécutées réellement par le microprocesseur et/ou qui ne produisent pas de résultat directement. Ces lignes d'instructions, dites lignes factices dans la suite du texte, sont par contre utilisées pour former un moyen d'identification unique UA2 associé au module de sécurité en question. En fait, les lignes factices peuvent être soit des instructions qui ne sont pas exécutées par le microprocesseur, soit des instructions qui sont réellement exécutées, mais qui ne produisent pas de résultat qui influence le déroulement du programme opérationnel. En d'autre terme, le fonctionnement du programme est le même, que ces codes soient présents ou non. Les termes de "codes factices" ou "lignes factices" doivent être compris comme recouvrant ces deux modes de réalisation.
En référence plus particulièrement au mode de réalisation illustré par la figure 2, le programme opérationnel comprend un certain nombre de blocs d'instructions réelles B1 , B2, qui peuvent former des routines de programme, ainsi qu'un ensemble de codes informatiques factice, formant un bloc d'instruction B3, qui a le même aspect qu'un bloc d'instructions conventionnel, mais qui est toutefois différent pour chaque module de sécurité. Ces codes informatiques sont compatibles pour une exécution par le microprocesseur et répondent à la syntaxe dudit microprocesseur de sorte qu'il n'est pas possible, par une simple analyse des codes, de repérer les codes réels, qui seront exécutés, et les codes factices, qui ne seront pas exécutés ou n'auront pas d'effet C.Λ sur le programme opérationnel. Les instructions, que contient cet ensemble factice sont des lignes factices qui ne sont généralement pas exécutées par le microprocesseur ou leur exécution n'influence pas le fonctionnement du programme; elles ne sont utilisées que pour former le moyen d'identification unique UA2 du module. Les instructions réelles sont formées de lignes réelles indiquées par R dans les figures 2 et 3 et les lignes factices sont représentées par les références F dans ces figures. Ce bloc d'instructions B3 peut être de préférence inséré dans le programme opérationnel pour mieux se dissimuler. Les codes informatiques factices servant à la formation du moyen d'identification peuvent également contenir des valeurs de registres ou de variables par exemple. Selon la variante de réalisation telle qu'illustrée par la figure 3, le module de sécurité comporte, contrairement à l'exemple précédent dans lequel les lignes factices sont regroupées ensemble dans la mémoire du programme opérationnel, un certain nombre de lignes d'instructions factices F, réparties parmi les instructions réelles R. Ces lignes factices forment un ensemble de codes informatiques unique et différent pour chaque module de sécurité.
Étant donné que généralement, les lignes d'instructions sont effectuées les unes après les autres, il est important que ces lignes d'instructions ne soient pas exécutées ou que leur exécution n'affecte pas le bon déroulement du programme opérationnel. Il est également important que ces codes informatiques spécifiques ne soient pas ou difficilement détectés par une personne malveillante.
Pour concilier ces contraintes, plusieurs modes de réalisation sont disponibles. Dans l'un des modes de réalisation, les lignes factices comportent une information spécifique indiquant que la ligne en question est factice et qu'elle ne doit par conséquent pas être exécutée par le microprocesseur.
Selon un autre mode de réalisation, certaines instructions réelles contiennent des indications relatives à l'emplacement des lignes factices. Une telle indication peut par exemple être faite sous la forme d'une instruction indiquant qu'il ne faut pas traiter une ligne disposée à un emplacement mémoire déterminé.
Les instructions consistant à ne pas traiter les lignes factices peuvent être dissimulées, par exemple en indiquant que la ligne en question doit être sautée seulement si une condition est remplie. Il est alors possible de s'arranger pour que cette condition soit toujours remplie. Il est également possible d'ajouter à une ligne réelle, une indication selon laquelle la ligne suivante est factice. Selon une autre forme de réalisation, rien dans les codes informatiques ne distingue une ligne factice d'une ligne réelle. Le module de sécurité contient une information mémorisée indiquant l'emplacement des codes informatiques que le microprocesseur ne doit pas exécuter.
Une variante telle que brièvement mentionnée précédemment peut également consister à utiliser comme ligne factice, une instruction qui est réellement exécutée par le microprocesseur, mais qui est sans effet sur la suite de l'exécution du programme. Une telle instruction pourrait être une indication que le programme doit passer à la ligne suivante. Il est bien entendu possible de rendre ce genre d'instructions "inutiles" difficiles à repérer, par exemple en écrivant l'instruction sous la forme d'un saut conditionnel, en indiquant que le passage à la ligne suivante doit se faire seulement si une condition déterminée est remplie, tout en s'arrangeant que cette condition soit toujours remplie. Une autre forme consisterait à envoyer le programme à une adresse prédéterminée quelconque si une condition est remplie, tout en s'arrangeant que cette condition ne soit jamais remplie. Une autre forme consisterait à modifier une location mémoire que l'on sait sans importante. Ces instructions "inutiles" sont indiquées dans le texte comme "n'ayant pas d'influence sur l'exécution par le microprocesseur, du programme opérationnel", du fait que ces instructions peuvent être supprimées sans que le résultat de l'exécution du programme opérationnel ne soit affecté.
Une manière particulièrement bien adaptée pour rendre difficile la détection de lignes factices par une personne malveillante est l'obfuscation ou la dissimulation, procédé qui consiste à rendre particulièrement complexe, la compréhension d'un code informatique décompilé.
Selon une variante de l'invention, il est également possible que seulement une partie des lignes factices servent à l'identification du module de sécurité. Les lignes factices qui ne servent pas à l'identification du module de sécurité sont uniquement présentes pour compliquer la compréhension du code informatique et pour empêcher un pirate de détecter quelles sont les informations qu'il doit publier s'il veut permettre de réaliser un clone fonctionnel et quelles sont les informations qu'il doit omettre s'il ne veut pas que le numéro unique d'identification de son module de sécurité soit également divulgué.
De telles lignes factices supplémentaires peuvent être insérées aussi bien dans le mode de réalisation dans lequel le module comporte un bloc factice que dans celui où les instructions sont disséminées dans les instructions réelles.
Il est à noter que les deux modes de réalisation, à savoir celui illustré par la figure 2 et celui illustré par la figure 3 peuvent également être combinés, c'est-à-dire que des instructions factices peuvent être introduites dans un bloc déterminé, alors que d'autres instructions factices sont en outre réparties parmi les instructions réelles.
Ibest également possible de générer plus d'un moyen d'identification ou d'introduire des informations qui permettent de générer plusieurs fois le même moyen d'identification unique UA2, de sorte que même si certaines des lignes factices sont détectées et ne sont donc pas publiées, il est malgré tout possible de déterminer le moyen d'identification UA2.
La réalisation du module de sécurité selon l'invention comporte une phase de personnalisation dans laquelle on introduit des données spécifiques au module. L'invention est également associée à une étape de détection d'un module dont les codes informatiques ont été publiés. Cette étape de détection consiste à extraire, à partir des informations publiées, les données spécifiques au module de sécurité. La méthode de personnalisation selon l'invention consiste essentiellement à générer un ensemble unique de codes informatiques, puis à écrire ces codes dans la mémoire programme.
Cette méthode de personnalisation dépend en premier lieu du type de module de sécurité choisi et plus particulièrement de l'emplacement des codes informatiques factices. En effet, lorsque les codes factices sont disposés dans la mémoire programme sous forme de bloc séparé, les codes factices peuvent être générés sous la forme d'un bloc, puis introduits dans le module.
Lorsque les codes factices sont dispersés dans le code informatique réel, les codes réels formant le programme opérationnel sont mémorisés de telle façon qu'ils comportent des emplacements libres. Des codes factices sont ensuite générés, puis insérés dans ces emplacements libres.
Dans le mode de réalisation dans lequel les codes factices sont des codes réellement exécutés par le microprocesseur, ces codes n'ayant toutefois aucun effet sur le déroulement du programme opérationnel, il est possible d'utiliser un répertoire de codes. Ce répertoire contient un ensemble de codes informatiques prédéfinis qui n'influencent pas le déroulement du programme opérationnel. Ces codes peuvent être, comme indiqués précédemment, un saut conditionnel, l'écriture d'une valeur dans une zone mémoire, la modification d'une valeur ou toute autre instruction qui ne modifie pas le déroulement du programme, que l'instruction soit exécutée ou non.
II est également possible de prévoir un procédé qui génère automatiquement des moyens d'identification à partir des codes factices contenus dans le répertoire. En effet, en connaissant le nombre de lignes d'instructions libres et éventuellement la taille des blocs à insérer, il est possible de puiser parmi les instructions de la bibliothèque, un certain nombre de codes de façon à remplir les lignes vides du programme opérationnel et de telle façon que chaque module de sécurité utilise un ensemble d'instructions unique. Cette unicité peut se faire aussi bien par les codes informatiques utilisés que par l'ordre d'utilisation de ces codes. Ce procédé est représenté schématiquement par la figure 4 dans laquelle la référence 10 illustre le répertoire des codes factices F1 , F2,... . La référence 11 représente les codes informatiques réels R1, R2,... formant le programme opérationnel. Ces codes comportent des emplacements mémoires vides.
Lors de la personnalisation des modules de sécurité, un certain nombre de codes informatiques sont choisis parmi les codes factices mémorisés dans le répertoire, de telle façon que deux modules de sécurité ne contiennent pas les mêmes codes. Ces codes sont introduits dans les emplacements mémoires libres du programme opérationnel. Dans l'exemple illustré par la figure 4, les codes factices des modules de sécurité ayant les références SM1 , SM2 et SM3 sont respectivement les ensembles (F1 , F1 , F3), (F3, F2, F4) et (F3, F3, F1).
Le procédé de personnalisation peut comporter en outre une étape visant à rendre plus complexe la détection de codes informatiques factices. En particulier, lorsque les codes factices sont regroupés dans un emplacement mémoire déterminé sous forme de bloc, il est judicieux d'éviter qu'une simple comparaison des codes informatiques de deux modules de sécurité dont la sécurité a été violée permette à une personne malveillante de repérer les codes factices et donc d'éviter leur publication. Pour résoudre ce problème, une étape d'obfuscation ou de dissimulation est bien adaptée.
L'étape de détection d'un module dont les codes informatiques ont été publiés telle que mentionnée ci-dessus consiste à extraire, à partir des informations publiées, le moyen d'identification unique du module de sécurité, d'une part pour éventuellement retrouver le titulaire du module d'origine et d'autre part pour rendre inopérant le module et les clones qu'il a permis de réaliser.
Cette étape de détection consiste essentiellement à comparer les codes informatiques publiés avec ceux qui ont été introduits dans les modules de sécurité lors de la phase de personnalisation. Pour ceci, différents moyens sont envisageables. En particulier, une comparaison "ligne par ligne" des codes publiés et des codes générés est possible. Une autre manière de réaliser cette comparaison consiste à extraire des codes publiés, les codes factices, puis à appliquer une opération à ces codes factices. Une opération basique qu'il est possible d'effectuer est la concaténation des bits formant les codes factices. Une autre opération peut consister à déterminer une signature (hash) du bloc d'instructions. En fait, toute opération permettant d'obtenir une valeur unique à partir d'un bloc d'instructions unique peut être utilisée. Cette même opération est appliquée aux codes informatiques générés lors de la phase de personnalisation, puis les valeurs uniques sont comparées.
Les instructions factices disséminées sont traitées comme dans le cas précédent, illustré par la figure 2, de façon à déterminer le moyen unique d'identification UA2 du module de sécurité.
Lorsque le moyen d'identification d'un module de sécurité dont la sécurité a été violée a été déterminé, il est alors possible de rendre inopérant le module de sécurité d'origine ainsi que les modules clones à partir de ce module d'origine.
D'autres variantes évidentes de réalisation non décrites en détail ci- dessus font également partie de l'invention. En particulier, il est possible d'introduire des codes informatiques factices permettant de générer plus d'un moyen d'identification par module de sécurité. A titre d'exemple, un premier moyen d'identification pourrait être constitué par un bloc d'instructions séparées et un autre moyen d'identification par des codes disséminés.
Il est également possible d'introduire des codes factices redondants, de sorte que le moyen d'identification puisse être extrait même si une partie des codes factices est éliminée lors de la publication.
Il est possible de prévoir qu'un même moyen d'identification UA2 soit utilisé non pas pour un module de sécurité unique, mais pour un groupe de modules de sécurité. Ceci est intéressant dans le cas où le groupe de modules appartient à une même personne ou de façon plus générale à une même entité. Une combinaison des différents modes de réalisation ci-dessus est également envisageable, c'est-à-dire par exemple qu'un module de sécurité peut contenir un premier moyen d'identification commun à un groupe de modules et un deuxième moyen d'identification unique par module.
Le moyen d'identification UA2 peut également être défini à partir de codes informatiques représentant des valeurs dans des registres.
En règle générale, il n'est pas prévu que le moyen d'identification UA2 remplace le numéro d'identification UA1 conventionnellement contenu dans un module de sécurité. Le premier numéro d'identification UA1 est présent dans le module et pourra par exemple être imprimé sur le module si celui-ci a la forme d'une carte à puce ou d'une clé par exemple.
Par opposition à ceci, le moyen d'identification UA2 sera tenu secret, de même que l'existence même d'un deuxième numéro d'identification UA2.

Claims

REVENDICATIONS
1. Module de sécurité comprenant un microprocesseur, une mémoire programme contenant au moins un programme opérationnel et un moyen d'identification unique dudit module, caractérisé en ce que ce moyen d'identification (UA2) est constitué d'un ensemble de codes informatiques factice, compatible avec son exécution par ledit microprocesseur du module et stocké dans la mémoire programme.
2. Module de sécurité selon la revendication 1 , caractérisé en ce que lesdits codes informatiques sont placés dans un bloc d'instructions spécifiques.
3. Module de sécurité selon la revendication 1 , caractérisé en ce que lesdits codes informatiques factices sont répartis parmi les codes informatiques formant le programme opérationnel.
4. Module de sécurité selon la revendication 2 ou 3, caractérisé en ce que lesdits codes informatiques factices ne sont pas exécutés par ledit microprocesseur.
5. Module de sécurité selon la revendication 2 ou 3, caractérisé en ce que lesdits codes informatiques factices ne modifient pas le déroulement du programme opérationnel exécuté par ledit microprocesseur.
6. Module de sécurité selon la revendication 1, caractérisé en ce que ledit module comprend en outre un ensemble de codes informatiques factices qui ne sont utilisés ni pour le fonctionnement du module de sécurité, ni pour former le moyen d'identification.
7. Méthode de personnalisation d'un module de sécurité par un identifiant unique, ce module comprenant un microprocesseur et une mémoire programme contenant au moins un programme opérationnel, caractérisée en ce qu'elle comprend les étapes suivantes: - génération d'un ensemble unique de codes informatiques, dénommés codes informatiques factices, - écriture de cet ensemble de codes dans la mémoire programme dans des emplacements mémoires spécifiques.
8. Méthode de personnalisation selon la revendication 7, caractérisé en ce que les codes informatiques factices disposés dans lesdits emplacements mémoires spécifiques ne sont pas exécutés par ledit microprocesseur.
9. Méthode de personnalisation selon la revendication 7, caractérisé en ce que les codes informatiques factices disposés dans lesdits emplacements mémoires spécifiques n'ont pas d'influence sur l'exécution par ledit microprocesseur du programme opérationnel.
10. Méthode de personnalisation selon la revendication 8 ou 9, caractérisé en ce que lesdits codes informatiques factices formant ledit ensemble unique sont choisis parmi une bibliothèque de codes informatiques.
11. Méthode de personnalisation selon la revendication 7, caractérisé en ce que lesdits codes informatiques factices forment un bloc d'instruction distinct des codes informatiques constituant le programme opérationnel.
12. Méthode de personnalisation selon la revendication 7, caractérisé en ce que lesdits codes informatiques factices sont dispersés parmi les codes informatiques constituant le programme opérationnel.
13. Méthode de personnalisation selon l'une quelconque des revendications 7 à 12, caractérisé en ce que les codes informatiques sont traités de façon à dissimuler la structure du programme formé par ces codes.
14. Méthode d'identification d'un module de sécurité tel que défini dans l'une quelconque des revendications 1 à 6 et dont les codes informatiques ont été rendus accessibles au public, ce procédé comportant les étapes de : - extraction des codes informatiques factices parmi les codes informatiques rendus accessibles au public; - traitement desdits codes informatiques factices selon des règles prédéfinies de façon à en déduire le moyen d'identification dudit module de sécurité.
PCT/EP2005/052988 2004-06-29 2005-06-27 Module de sécurité et méthode de personnalisation d'un tel module de sécurité WO2006000584A1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
ES05771823T ES2375484T3 (es) 2004-06-29 2005-06-27 Módulo de seguridad y método de personalización de tal módulo de seguridad.
CA002572023A CA2572023A1 (fr) 2004-06-29 2005-06-27 Module de securite et methode de personnalisation d'un tel module de securite
JP2007518597A JP2008504617A (ja) 2004-06-29 2005-06-27 セキュリティモジュール及びそのようなセキュリティモジュールのカスタマイズ方法
AT05771823T ATE530975T1 (de) 2004-06-29 2005-06-27 Sicherheitsmodul und verfahren zur individuellen anpassung eines derartigen moduls
KR1020067027797A KR101226854B1 (ko) 2004-06-29 2005-06-27 보안 모듈, 개인화 방법 및 보안 모듈 식별 방법
EP05771823A EP1761835B1 (fr) 2004-06-29 2005-06-27 Module de sécurité et méthode de personnalisation d'un tel module de sécurité

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP04103053A EP1612637A1 (fr) 2004-06-29 2004-06-29 Module de sécurité et méthode de personnalisation d'un tel module de sécurité
EP04103053.7 2004-06-29

Publications (1)

Publication Number Publication Date
WO2006000584A1 true WO2006000584A1 (fr) 2006-01-05

Family

ID=34929271

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/052988 WO2006000584A1 (fr) 2004-06-29 2005-06-27 Module de sécurité et méthode de personnalisation d'un tel module de sécurité

Country Status (10)

Country Link
US (1) US20060020549A1 (fr)
EP (2) EP1612637A1 (fr)
JP (1) JP2008504617A (fr)
KR (1) KR101226854B1 (fr)
CN (1) CN101484864A (fr)
AT (1) ATE530975T1 (fr)
CA (1) CA2572023A1 (fr)
ES (1) ES2375484T3 (fr)
TW (1) TW200607294A (fr)
WO (1) WO2006000584A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008253297A (ja) * 2007-03-30 2008-10-23 Univ Kansai Medical 医療用チューブ

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7467415B2 (en) * 2003-09-30 2008-12-16 Novell, Inc. Distributed dynamic security for document collaboration
US8015301B2 (en) * 2003-09-30 2011-09-06 Novell, Inc. Policy and attribute based access to a resource
US7299493B1 (en) * 2003-09-30 2007-11-20 Novell, Inc. Techniques for dynamically establishing and managing authentication and trust relationships
US20090249085A1 (en) * 2004-06-29 2009-10-01 Nagracard S.A. Security module and personalization method for such a security module
US8007358B2 (en) * 2005-11-22 2011-08-30 Igt Regulated gaming—multi-act games
US7664937B2 (en) * 2007-03-01 2010-02-16 Microsoft Corporation Self-checking code for tamper-resistance based on code overlapping
AU2008203513A1 (en) 2007-08-14 2009-03-05 Aristocrat Technologies Australia Pty Limited A gaming system and a method of gaming
JP2010268417A (ja) * 2009-04-16 2010-11-25 Toshiba Corp 記録装置及びコンテンツデータ再生システム

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1178406A1 (fr) * 2000-07-31 2002-02-06 Avaya Technology Corp. Masquage automatique des données d'identification d'un produit
US6725374B1 (en) * 1998-08-20 2004-04-20 Orga Kartensysteme Gmbh Method for the execution of an encryption program for the encryption of data in a microprocessor-based portable data carrier

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4430728A (en) * 1981-12-29 1984-02-07 Marathon Oil Company Computer terminal security system
US4802217A (en) * 1985-06-07 1989-01-31 Siemens Corporate Research & Support, Inc. Method and apparatus for securing access to a computer facility
US5421006A (en) * 1992-05-07 1995-05-30 Compaq Computer Corp. Method and apparatus for assessing integrity of computer system software
JP3029381B2 (ja) * 1994-01-10 2000-04-04 富士通株式会社 データ変換装置
JPH10293687A (ja) * 1997-04-18 1998-11-04 Nippon Telegr & Teleph Corp <Ntt> プログラム著作権保護方法及び装置
US6032257A (en) * 1997-08-29 2000-02-29 Compaq Computer Corporation Hardware theft-protection architecture
US6968459B1 (en) * 1999-12-15 2005-11-22 Imation Corp. Computing environment having secure storage device
US7003107B2 (en) * 2000-05-23 2006-02-21 Mainstream Encryption Hybrid stream cipher
EP1209635A1 (fr) * 2000-11-24 2002-05-29 eSecurium SA Télécommande securisée
US7181017B1 (en) * 2001-03-23 2007-02-20 David Felsher System and method for secure three-party communications
US6968454B2 (en) * 2001-12-27 2005-11-22 Quicksilver Technology, Inc. Apparatus, method and system for generating a unique hardware adaptation inseparable from correspondingly unique content
US7254586B2 (en) * 2002-06-28 2007-08-07 Microsoft Corporation Secure and opaque type library providing secure data protection of variables
JP2004046708A (ja) * 2002-07-15 2004-02-12 Sony Corp ソフトウェア提供システム、ソフトウェア提供サーバ、端末、制御プログラム、ソフトウェア提供方法、ソフトウェア利用方法、ソフトウェア提供プログラム、及びソフトウェア利用プログラム
CA2415334C (fr) * 2002-12-31 2012-04-24 Protexis Inc. Systeme de cryptage persistant des donnees critiques de logiciels permettant de commander l'execution d'un programme informatique
US7322042B2 (en) * 2003-02-07 2008-01-22 Broadon Communications Corp. Secure and backward-compatible processor and secure software execution thereon
JP2004312267A (ja) * 2003-04-04 2004-11-04 Sony Corp 画像伝送システム，撮像装置，撮像装置ユニット，鍵生成装置，およびプログラム
US7409545B2 (en) * 2003-09-18 2008-08-05 Sun Microsystems, Inc. Ephemeral decryption utilizing binding functions

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6725374B1 (en) * 1998-08-20 2004-04-20 Orga Kartensysteme Gmbh Method for the execution of an encryption program for the encryption of data in a microprocessor-based portable data carrier
EP1178406A1 (fr) * 2000-07-31 2002-02-06 Avaya Technology Corp. Masquage automatique des données d'identification d'un produit

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008253297A (ja) * 2007-03-30 2008-10-23 Univ Kansai Medical 医療用チューブ

Also Published As

Publication number Publication date
EP1612637A1 (fr) 2006-01-04
KR101226854B1 (ko) 2013-01-25
ES2375484T3 (es) 2012-03-01
US20060020549A1 (en) 2006-01-26
JP2008504617A (ja) 2008-02-14
TW200607294A (en) 2006-02-16
CA2572023A1 (fr) 2006-01-05
EP1761835B1 (fr) 2011-10-26
EP1761835A1 (fr) 2007-03-14
CN101484864A (zh) 2009-07-15
KR20070020093A (ko) 2007-02-16
ATE530975T1 (de) 2011-11-15

Similar Documents

Publication Publication Date Title
EP1761835B1 (fr) Module de sécurité et méthode de personnalisation d&#39;un tel module de sécurité
EP1570648B1 (fr) Méthode de sécurisation des mises à jour de logiciels
EP0475837B1 (fr) Procédé de gestion d&#39;un programme d&#39;application chargé dans un support à microcircuit
EP0089876B1 (fr) Procédé et dispositif de protection d&#39;un logiciel livré par un fournisseur à un utilisateur
EP1627362A1 (fr) Methode de generation d&#39;une cle de securite
EP0425053A1 (fr) Système de traitement de données comportant des moyens d&#39;authentification d&#39;une carte à mémoire, circuit électronique à utiliser dans ce système et procédé de mise en oeuvre de cette authentification
FR2681165A1 (fr) Procede de transmission d&#39;information confidentielle entre deux cartes a puces.
EP1605333B1 (fr) Contrôle de l&#39;exécution d&#39;un programme
EP2107808A1 (fr) Module de sécurité (SM) pour unité de traitement de données audio/vidéo
EP2166696B1 (fr) Protection de l&#39;intégrité de données chiffrées en utilisant un état intermédiare de chiffrement pour générer une signature
EP1756696B1 (fr) Methode de mise a jour securisee de logiciel embarque dans un module de securite
EP1029312B1 (fr) Procede de gestion securise d&#39;une memoire
CA2988357C (fr) Procede de chiffrement, procede de chiffrement, dispositifs et programmes correspondants
US20090249085A1 (en) Security module and personalization method for such a security module
FR2899409A1 (fr) Dispositif de restitution d&#39;un contenu numerique, entite electronique securisee, systeme comprenant ces elements et procede de restitution d&#39;un contenu numerique
WO2008084154A2 (fr) Traitement de donnee relative a un service numerique
WO2003023725A1 (fr) Protocole d&#39;authentification a verification d&#39;integrite de memoire
EP3239845B1 (fr) Procédé d&#39;allocation d&#39;espace mémoire
EP3360034A1 (fr) Procédé et système de sauvegarde répartie dynamique
WO2024083849A1 (fr) Encodage en boite blanche
FR2841667A1 (fr) Interface graphique utilisateur permettant d&#39;installer des programmes informatiques d&#39;un lot de demarrage
EP2153575A2 (fr) Obtention de valeurs dérivées dépendant d&#39;une valeur maîtresse secrète
WO2007025954A2 (fr) Méthode pour générer une pluralité de numéros sécurisés uniques et carte comportant un tel numéro
EP3757842A1 (fr) Modification d&#39;une mémoire d&#39;un microprocesseur sécurisé
FR3020888A1 (fr) Chiffrement d&#39;une cle de protection de secrets protegeant au moins un element sensible d&#39;une application

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2005771823

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2572023

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2007518597

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 1020067027797

Country of ref document: KR

Ref document number: 200580022003.4

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Ref document number: DE

WWE Wipo information: entry into national phase

Ref document number: 36/MUMNP/2007

Country of ref document: IN

WWP Wipo information: published in national office

Ref document number: 1020067027797

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2005771823

Country of ref document: EP