WO2000042731A1

WO2000042731A1 - Procede de chargement securise de donnees entre des modules de securite

Info

Publication number: WO2000042731A1
Application number: PCT/FR2000/000099
Authority: WO
Inventors: Dan Butnaru; Mathias Gelze; Raphaël ROSSET
Original assignee: Schlumberger Systemes
Priority date: 1999-01-18
Filing date: 2000-01-18
Publication date: 2000-07-20
Also published as: FR2788649A1; CN1199387C; EP1142193A1; CN1339206A

Abstract

L'invention concerne un procédé de personnalisation de module de sécurité comprenant un chargement sécurisé d'une clef applicative à partir d'un premier module de sécurité vers un ensemble de plusieurs deuxièmes modules de sécurité, lesdits premier et deuxièmes modules comprenant chacun au moins une mémoire. L'invention se caractérise en ce que ledit procédé comporte des étapes selon lesquelles, lors de chaque chargement, on calcule dans le premier et deuxièmes modules une clef d'exploitation à partir d'une clef de transport identique pour chaque deuxième module dudit ensemble. La clef d'exploitation est utilisée pour le chiffrement dans le premier module de la clef applicative. Cette dernière est par la suite envoyée au deuxième module, déchiffrée et vérifiée dans ledit module. La clef d'exploitation n'est pas enregistrée dans la mémoire des modules de sécurité. L'invention s'applique, en particulier au domaine bancaire.

Description

PROCEDE DE CHARGEMENT SECURISE DE DONNEES ENTRE DES

MODULES DE SECURITE

La présente invention concerne un procédé de personnalisation d'un ensemble de plusieurs deuxièmes modules de sécurité, comprenant un chargement sécurisé d'une clef applicative à partir d'un premier module de sécurité vers lesdits deuxièmes modules de sécurité dudit ensemble, lesdits premier et deuxièmes modules comprenant chacun au moins une mémoire.

L'invention trouve une application particulièrement avantageuse lors d'une phase de personnalisation de deuxièmes modules de sécurité dans les domaines tels que le domaine de la fidélité ou le domaine bancaire.

Un tel procédé de personnalisation est effectué avant une phase d'utilisation desdits deuxièmes modules. Par exemple, lors d'une phase d'utilisation dans le domaine de la fidélité, les deuxièmes modules se trouvent dans des terminaux de stations service et sont utilisés de manière à fournir des prestations de sécurisation de transactions de débit-crédit de points de fidélité entre un desdits terminaux et des cartes de crédit d'utilisateurs. Dans le domaine bancaire, les deuxièmes modules se trouvent dans des terminaux bancaires et fournissent des prestations de sécurisation de transactions d'argent dans des cartes de crédit d'utilisateurs.

Un état de la technique connu et divulgué dans le brevet américain publié sous le numéro US 5 517 567 au nom de DAQ Electronics enseigne qu'il existe un système de cryptage de clef dont le but est une sécurisation des communications pouvant s'établir entre un deuxième module de sécurité « master unit» et un troisième module utilisateur « remote unit » lorsque ce dernier est installé dans un site distant, par exemple dans un téléphone portable. Ladite sécurisation est basée sur l'utilisation d'une clef de communication temporaire. Selon ce système, après que le module utilisateur est installé sur son site distant, on génère au moyen du deuxième module une clef de communication. Par suite, on envoie pour l'établissement de chaque communication, à partir du deuxième module au module utilisateur, la clef de communication chiffrée. La clef de communication permet un échange de messages sécurisés entre le deuxième module et le module utilisateur car elle n'est connue que de ces deux modules. En effet, ladite clef est basée sur une paire de deux nombres secrets unique à chaque module utilisateur et le deuxième module comporte toutes les paires correspondant à tous les modules utilisateurs. Le système est d'autant plus sécurisé qu'une paire de deux nombres secrets est inscrite dans la mémoire d'un module utilisateur, ladite mémoire étant volatile. Ainsi, lorsqu'une communication est terminée et lorsque le module utilisateur n'est plus alimenté, ladite paire est effacée et un fraudeur ne risque pas de découvrir les deux nombres secrets. Pour établir une autre communication, ledit système génère une autre clef de communication .

Le document cité ci-dessus décrit un système mis en oeuvre lors d'une phase d'utilisation d'un deuxième module et d'un module utilisateur, dont le but est d'établir une communication sécurisée entre les deux modules en utilisant une même clef de communication dédiée à une communication. Il ne décrit en aucune façon un système de personnalisation dont le but serait de sécuriser un chargement de clef dans un ensemble de plusieurs deuxièmes modules de sécurité. Aussi, un problème technique à résoudre par l'objet de la présente invention est de proposer un procédé de personnalisation d'un ensemble de plusieurs deuxièmes modules de sécurité comprenant un chargement sécurisé d'une clef applicative à partir d'un premier module de sécurité vers lesdits deuxièmes modules de sécurité dudit ensemble, lesdits premier et deuxièmes modules comprenant chacun au moins une mémoire, qui permettrait, d'une part, d'éviter à un fraudeur de découvrir ladite clef applicative, et, d'autre part, de gagner du temps lors de la phase de personnalisation desdits deuxièmes modules de sécurité. Une solution au problème technique posé se caractérise en ce que ledit procédé de personnalisation comporte les étapes selon lesquelles : pour chaque deuxième module dudit ensemble,

- lors de chaque chargement, on calcule dans le premier module une clef d'exploitation à partir d'une information propre au deuxième module, d'une clef de transport et d'un algorithme de diversification, ladite clef de transport se trouvant dans la mémoire du premier module de sécurité, ladite mémoire étant non volatile,

- on chiffre dans le premier module la clef applicative, à partir d'informations comprenant ladite clef d'exploitation et d'un algorithme de cryptage, ladite clef applicative se trouvant dans ladite mémoire,

- on envoie au deuxième module des données comprenant la clef applicative chiffrée, - lors de chaque chargement, on calcule dans le deuxième module la clef d'exploitation à partir de l'information propre au deuxième module, de la clef de transport et de l'algorithme de diversification, ladite même clef de transport se trouvant dans la mémoire non volatile de chaque deuxième module de sécurité dudit ensemble, ladite clef d'exploitation n'étant pas enregistrée dans la mémoire dudit deuxième module,

- on déchiffre dans le deuxième module la clef applicative chiffrée, à partir d'informations comprenant ladite clef d'exploitation et d'un algorithme de décryptage inverse de l'algorithme de cryptage. Ainsi, comme on le verra en détail plus loin, le procédé de chargement de l'invention permet, en calculant ladite clef d'exploitation et en ne la conservant que le temps du chiffrement ou du déchiffrement de la clef applicative, d'améliorer la sécurité du chargement d'une clef applicative. Par suite, un fraudeur ne pourra accéder à ladite clef d'exploitation ni par conséquent à la clef applicative. Les éventuelles fraudes sont par conséquent évitées et on n'effectue plus d'opérations qui sont coûteuses en temps pour la phase de personnalisation, le temps de calcul de la clef d'exploitation étant infime par rapport au temps d'accès nécessaire à l'enregistrement de ladite clef.

La description qui va suivre au regard des dessins annexés, donnée à titre d'exemple non limitatif, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée.

La figure 1 est un schéma montrant un premier module et plusieurs deuxièmes modules appartenant à un même ensemble.

La figure 2 est un schéma montrant le premier module et un deuxième module de la figure 1.

La figure 3 est un schéma montrant un échange de données entre le premier module et le deuxième module de la figure 2. La figure 4 un schéma montrant un deuxième échange de données entre le premier module et le deuxième module de la figure 2.

La figure 5 est un schéma montrant un troisième échange de données entre le premier module et le deuxième module de la figure 2.

La figure 6 est un schéma montrant un quatrième échange de données entre le premier module et le deuxième module de la figure 2.

Sur la figure 1 est représenté un premier module AS de sécurité et plusieurs modules El de sécurité d'un même ensemble S (non représenté), chacun des modules (AS, El) comprenant au moins une mémoire M non volatile. Le premier module AS ainsi que les deuxièmes modules El dudit ensemble S comportent une même clef T de transport et un même algorithme ALGO 1 appelé algorithme de diversification qui se trouvent dans la mémoire M. Sur la figure 2, sont représentés le module AS ainsi qu'un module El dudit ensemble S. Chaque deuxième module El de l'ensemble S comporte la même clef de transport T. Ainsi, on différencie un ensemble de deuxièmes modules El d'un autre ensemble au moyen de ladite clef de transport T. Par exemple, deux ensembles de deuxièmes modules El correspondent à deux fournisseurs de stations service différents.

En outre, le premier module AS comporte une clef applicative TA et un algorithme ALGO2 de cryptage. On notera que les deux algorithmes ALGO 1 et ALGO2 peuvent utiliser un même algorithme de base. Chaque module El dudit ensemble S comprend une information SN qui lui est propre et au moins une application utilisateur (non représenté), par exemple une application fournissant des prestations de sécurisations de transactions de débit-crédit de points de fidélité.

Afin d'utiliser les modules El de sécurité dudit ensemble S, il faut pour chaque deuxième module El dudit ensemble S, au préalable charger une clef applicative TA du premier module AS lors d'une phase dite de personnalisation comprenant les étapes décrites ci-après. Ladite clef est transférée par l'intermédiaire d'un réseau de communication standard. On empêche un fraudeur qui espionnerait ledit réseau ou lesdits modules d'accéder à des clefs des modules, comme décrit ci- après.

Dans une première étape, lors de chaque chargement, on calcule dans le premier module AS une clef Tl d'exploitation à partir de l'information SN propre au deuxième module El, de la clef T de transport et de l'algorithme ALGO 1 de diversification, ladite clef T de transport se trouvant dans la mémoire M du premier module AS de sécurité, ladite mémoire étant non volatile. Préférentiellement, ladite mémoire M est une mémoire réinscriptible. On notera que la clef de transport T demeure valide même pendant les phases d'utilisation d'un deuxième module El, tant qu'on ne la remplace pas.

L'information SN propre au deuxième module El ne se trouve pas dans le premier module. Aussi, comme le montre la figure 3, on envoie au premier module AS l'information SN propre au deuxième module El, préalablement au calcul dans le premier module AS de la clef Tl d'exploitation. Ledit premier module AS comporte préférentiellement plusieurs clefs applicatives TA. Ladite clef Tl va servir au chargement d'une des clefs applicatives TA contenues dans le premier module AS, ladite clef applicative choisie sera chiffrée et envoyée au module El. Une clef applicative est associée à une application utilisateur. Suivant l'application se trouvant dans le deuxième module El, on choisit la clef adéquate.

Comme le montre la figure 3, pour choisir une desdites clefs applicatives TA, dans une deuxième étape, on envoie au premier module AS une information REF1 relative à une clef applicative TA, préalablement au chiffrement dans ledit module AS de la clef applicative TA et on choisit la clef applicative TA à chiffrer à partir de ladite information REF1. On peut par exemple envoyer à partir du deuxième module El une référence représentant un numéro de clef ayant une valeur de trois pour indiquer que l'on choisit la troisième clef correspondant à une application dudit module El. C'est cette dernière qui sera chargée dans le deuxième module E S'il n'existe pas de clef applicative TA référencée par ledit nombre REF1 , le premier module AS indique que ladite clef n'existe pas.

Dans une troisième étape, comme le montre la figure 3, on chiffre dans le premier module AS la clef applicative TA à partir d'informations comprenant ladite clef Tl d'exploitation et de l'algorithme ALGO2 de cryptage. Ladite clef d'exploitation se trouve temporairement dans une deuxième mémoire volatile (non représentée) du premier module AS. Afin de protéger le premier module AS contre une éventuelle fraude, postérieurement au chiffrement de la clef applicative TA, on efface la clef Tl d'exploitation sauvegardée temporairement dans ladite deuxième mémoire volatile du premier module AS. Après avoir chiffré ladite clef TA, on envoie au deuxième module

El des données DONNEES comprenant la clef applicative TA chiffrée.

Dans une quatrième étape, on déchiffre dans le deuxième module El la clef applicative TA chiffrée, à partir d'informations comprenant ladite clef Tl d'exploitation et d'un algorithme ALGO2P de décryptage inverse de l'algorithme ALGO2 de cryptage. Dans cette étape, afin de retrouver la clef applicative TA choisie, il est nécessaire d'utiliser la même clef Tl d'exploitation qui a été utilisée pour le cryptage de ladite clef applicative TA dans le premier module AS de sécurité. A cette fin, préalablement au déchiffrement de la clef applicative TA chiffrée, lors de chaque chargement, on calcule dans le deuxième module El la clef Tl d'exploitation à partir de l'information SN propre au deuxième module El, de la clef T de transport et de l'algorithme ALGO 1 de diversification, ladite même clef T de transport se trouvant dans la mémoire M non volatile de chaque deuxième module El de sécurité dudit ensemble S, ladite clef Tl d'exploitation n'étant pas enregistrée dans la mémoire M d'un deuxième module El. Préférentiellement la mémoire M du deuxième module est réinscriptible. Ladite clef Tl d'exploitation est sauvegardée temporairement dans une deuxième mémoire volatile (non représentée) du deuxième module El. On notera que ledit calcul peut se faire à tout moment avant le déchiffrement de la clef applicative TA. Les éléments nécessaires au calcul de la clef Tl d'exploitation dans le deuxième module El de sécurité sont les mêmes que ceux utilisés pour le calcul de la clef Tl d'exploitation dans le premier module AS. Par conséquent, les deux clefs Tl sont identiques et on retrouve bien dans le deuxième module El la clef applicative TA choisie. Il n'a pas été nécessaire d'envoyer la clef Tl d'exploitation à travers le réseau de communication.

Dans une cinquième étape, postérieurement au déchiffrement de la clef applicative TA et préférentiellement juste après ledit déchiffrement, on efface la clef Tl d'exploitation sauvegardée temporairement dans ladite deuxième mémoire volatile du deuxième module El.

Le fait, d'une part, de ne pas envoyer une clef d'exploitation Tl à travers le réseau de communication, d'autre part, de ne pas enregistrer une clef Tl d'exploitation dans une mémoire M non volatile d'un deuxième module El, et enfin, le fait que ladite clef d'exploitation n'existe dans le deuxième module que le temps de déchiffrement de la clef applicative TA, rend une fraude plus difficile à effectuer dans la mesure où si un fraudeur veut trouver une clef applicative TA, il doit auparavant retrouver la clef Tl d'exploitation utilisée. Enfin, cela facilite la personnalisation et une mise sur le terrain d'un nième deuxième module El dans la mesure où pour personnaliser les deuxièmes modules il n'est plus nécessaire d'effectuer deux chargements, un premier d'une clef Tl d'exploitation et un deuxième d'une clef applicative TA, mais simplement un chargement d'une clef applicative TA. On se libère ainsi de du premier chargement qui est habituellement effectué par une entité différente du premier module AS, ce qui complique généralement d'autant plus les choses.

A l'instar du premier module AS, un module El comprend préférentiellement plusieurs clefs applicatives TA. Ainsi, au moyen d'un deuxième module El, on peut gérer plusieurs applications. De plus, cela améliore la sécurité desdits modules, étant donné qu'un fraudeur aura plus de difficulté à, d'une part, découvrir une clef applicative parmi d'autres, et d'autre part, à savoir à qu'elle application elle est dédiée. Dans l'exemple précédent concernant le domaine de la fidélité, lors de l'utilisation d'un deuxième module El, celui-ci doit pouvoir fournir différentes prestations telles que la sécurisation des transactions de débit-crédit de points pour par exemple différents types de carburant. Il est ainsi important d'avoir différentes clefs applicatives TA dans ledit module El pour gérer la sécurisation de ces différents types de transactions, ces derniers représentant différentes applications.

Aussi, dans une sixième étape, on envoie au deuxième module El une information REF2 relative à une clef applicative TA, préalablement au déchiffrement dans ledit module El de la clef applicative TA chiffrée, comme le montre la figure 4. L'information REF2 permet, soit de choisir la clef applicative TA qui va recevoir la valeur de la clef applicative provenant du premier module AS, soit d'indiquer un emplacement où sera chargée ladite clef TA provenant dudit premier module AS. Ainsi, on peut soit modifier une valeur d'une clef TA déjà existante dans ledit deuxième module El, soit charger une nouvelle clef applicative TA dans le deuxième module El pour une nouvelle application utilisateur.

Dans le cas où la clef applicative TA référencée par ladite information REF2 n'existe pas ou que ledit emplacement n'existe pas ou n'est pas fait pour accueillir une clef, le deuxième module El rejette la clef reçue et indique qu'une erreur s'est produite. On notera que les informations REF1 et REF2 envoyées respectivement au premier et deuxième modules de sécurité peuvent être équivalentes.

Par la suite, lors d'une phase d'utilisation, une des clefs applicatives TA se trouvant dans le deuxième module El pourra être utilisée par ledit module pour s'identifier vis-à-vis d'entités extérieures comme par exemple une carte utilisateur. Or ladite identification doit être unique. Par conséquent, ladite clef TA ne doit pas avoir de doublon. Aussi, lorsque l'on veut charger cette clef, on diversifie dans le premier module AS ladite clef applicative TA choisie, préalablement au chiffrement de ladite clef. La diversification se fait en fonction d'une information propre à chaque deuxième module.

Enfin, dans une dernière étape, on enregistre dans le deuxième module El, après le déchiffrement de la clef applicative TA chiffrée, ladite clef TA dans ledit module El. L'enregistrement dans ledit deuxième module El de la clef applicative TA se fait en fonction de l'information REF2 relative à une clef applicative TA. L'enregistrement se fait dans la mémoire M non volatile réinscriptible.

Le deuxième module El peut maintenant être utilisé et être placé sur un site utilisateur distant tel qu'un terminal de stations service. On notera qu'aucune clef Tl d'exploitation n'a été transférée du premier module AS au deuxième module El et n'a été enregistrée dans la mémoire M des modules de sécurité. Les opérations nécessaires à ces deux actions ne sont pas effectuées ce qui permet de gagner du temps lors de la phase de personnalisation. Ainsi, on ne mémorise pas une donnée secrète immédiatement utilisable par un algorithme ce qui empêche un fraudeur qui analyse ledit algorithme de découvrir ladite donnée. Ainsi, il est inutile pour le fraudeur d'espionner soit le réseau de communication soit les modules de sécurité afin de trouver la clef Tl d'exploitation utilisée.

Un autre avantage de l'objet de la présente invention se trouve dans le fait que l'information SN propre à chaque deuxième module El de sécurité est unique. La clef Tl d'exploitation, qui est diversifiée c'est à dire calculée à partir de cette information, est par conséquent unique pour chaque module El de sécurité. Par suite, la clef applicative TA chiffrée, qui est fonction de ladite clef Tl d'exploitation, n'est destinée qu'à un unique deuxième module El destinataire ce qui renforce l'aspect sécuritaire de l'invention. Si un deuxième module El n'a pas la même information SN que celle utilisée pour calculer la clef Tl d'exploitation dans le premier module AS et s'il reçoit ainsi une clef applicative TA qui ne lui est pas destinée, il rejette ladite clef et indique qu'une erreur s'est produite.

D'autres aspects sécuritaires décrits ci-dessous sont couverts par l'objet de la présente invention. L'objet de la présente invention prévoit une étape supplémentaire, montrée à la figure 4, selon laquelle on envoie au premier module AS un nombre aléatoire R issu du deuxième module El, préalablement au chiffrement dans le premier module AS de la clef applicative TA. Les informations permettant, d'une part, de chiffrer la clef applicative TA dans le premier module AS, et, d'autre part, de déchiffrer dans le deuxième module El la clef applicative TA chiffrée, comprennent le nombre aléatoire R issu du deuxième module El. L'utilisation du nombre aléatoire R pour chiffrer et déchiffrer ladite clef applicative TA évite d'avoir une même valeur de chiffrement d'une clef applicative TA destinée à un deuxième module El lorsque, par exemple, l'on charge plusieurs fois ladite clef dans ledit module. Ainsi, chaque chiffrement d'une clef applicative TA destinée à un deuxième module El est unique. Ainsi, un fraudeur qui espionne le réseau de communication et récupère les données DONNEES lors du transfert n'obtient jamais une même valeur de chiffrement et ne peut par conséquent découvrir un secret relatif à la clef applicative TA transférée.

Cependant, lors dudit transfert, le fraudeur peut avoir effectué des opérations frauduleuses qui altèrent les données transférées. Aussi, on vérifie que les données DONNEES comprenant la clef applicative TA chiffrée sont intègres. A cette fin, comme le montre la figure 5, on calcule dans le premier module AS un certificat CAS sur lesdites données DONNEES, préalablement à l'envoi desdites données, ledit certificat étant envoyé par la suite au deuxième module El et vérifié dans ledit deuxième module, préalablement au déchiffrement dans ledit deuxième module El de la clef applicative TA chiffrée. Afin d'effectuer la vérification, on calcule dans le deuxième module El un certificat CEI en fonction des données reçues et on compare les deux certificats CAS et CEI. Si une fraude ou une erreur s'est produite lors dudit transfert, la vérification du certificat CAS est erronée, le déchiffrement de la clef applicative TA ne se fait pas et le deuxième module El indique qu'une erreur s'est produite. Ce système garantit ainsi une intégrité des données DONNEES lors de leur transfert depuis le premier module AS vers le deuxième module El sur le réseau de communication et ce avant l'utilisation d'un deuxième module El c'est à dire avant leur mise en circulation sur le terrain. De plus, dans le cas où la vérification serait fausse, cela évite de faire un déchiffrement inutile et par suite de perdre du temps inutilement.

De même qu'il faut garantir l'intégrité des données transférées, de même il faut garantir l'authenticité des données qui sont enregistrées dans le deuxième module El. Ainsi, on vérifie que la clef applicative TA est authentique. A cet effet, comme le montre la figure 5, on calcule dans le premier module AS, préalablement au chiffrement de la clef applicative TA, une signature SAS de ladite clef TA, ladite signature étant envoyée par la suite au deuxième module El et vérifiée dans ledit module. La vérification de la signature de ladite clef applicative TA se fait postérieurement au déchiffrement dans le deuxième module El de ladite clef TA chiffrée et préalablement à l'enregistrement de ladite clef dans ledit module. Afin d'effectuer la vérification, on calcule dans le deuxième module El une signature SEI avec la clef applicative TA déchiffrée dans ledit module El et on compare les deux signatures SAS et SEI. Dans le cas où les deux signatures sont équivalentes, la clef applicative TA déchiffrée est authentique et est enregistrée. Dans le cas où la clef applicative TA n'est pas authentique, l'enregistrement de ladite clef ne se fait pas et le deuxième module El indique qu'une erreur s'est produite. Le système décrit ci-dessus permet ainsi de vérifier que l'on récupère bien la clef applicative TA choisie dans le premier module AS et non une autre clef. On notera que lorsque ladite signature SAS existe, le certificat CAS est calculé également en fonction de ladite signature SAS. Ladite signature fait partie des données DONNEES envoyées lors de la troisième étape décrite précédemment.

L'envoi de données telles qu'un certificat ou une signature à un module de sécurité fait appel à des opérations dont le temps d'accomplissement s'ajoute à celui de la phase de personnalisation. Aussi, comme le montre la figure 6, afin de réduire le nombre d'accès aux différents modules et ainsi de réduire le temps de personnalisation, on envoie l'ensemble des données dont a besoin un module de sécurité en une seule fois au moyen d'une unique commande. Le nombre R aléatoire, le nombre REF1 relatif à une clef applicative TA et le nombre SN propre au deuxième module El sont envoyés au premier module AS au moyen d'une unique première commande EXPORTKEY. De la même façon, la clef applicative TA chiffrée, le nombre REF2 relatif à une clef applicative TA, la signature SAS ainsi que le certificat CAS s'ils existent, sont envoyés au deuxième module El au moyen d'une unique deuxième commande IMPORTKEY. L'invention s'applique plus particulièrement dans le cas où le premier module AS de sécurité est une carte à puce. La carte à puce comprend un corps de carte plastique dans lequel est incorporé un module électronique comportant une puce à circuit intégré. Ladite puce comprend couramment deux mémoires M et une troisième mémoire volatile (RAM), la première mémoire M étant réinscriptible (EEPROM) et la deuxième non réinscriptible (ROM). La première mémoire M comprend l'ensemble des clefs applicatives TA et la clef de transport T. La troisième mémoire comprend la clef Tl d'exploitation. Celle-ci ne demeure dans ladite mémoire que le temps de chiffrement ou de déchiffrement de la clef applicative dans un module de sécurité. Les algorithmes ALGO1 de diversification et ALGO2 de cryptage peuvent se trouver dans la première ou deuxième mémoire M. Cependant, on notera qu'il n'est pas obligatoire d'avoir lesdits algorithmes dans la carte à puce. Ils peuvent se trouver dans une entité extérieure à ladite carte à puce, par exemple dans une unité centrale d'un terminal avec lequel serait connectée ladite carte à puce.

La carte à puce permet d'assurer une meilleure protection des clefs applicatives TA. Dans une carte à puce, contrairement à un terminal d'un ordinateur par exemple, lesdites clefs sont inconnues de toute entité (d'un terminal, d'un , administrateur de ladite carte, d'une autre carte à puce, ...) excepté de l'entité émettrice desdites clefs. De plus, une fraude est plus difficile à réaliser sur une carte à puce que sur une unité centrale d'un terminal par exemple. Pour les mêmes raisons, le deuxième module de sécurité est une carte à puce. On notera qu'une clef applicative TA étant dans une mémoire M non volatile, elle peut être utilisée lors de plusieurs phases d'utilisation d'un deuxième module El, car même lorsque ce dernier n'est plus alimenté, ladite clef n'est pas effacée.

Claims

REVENDICATIONS

1 - Procédé de personnalisation d'un ensemble (S) de plusieurs deuxièmes modules de sécurité (El) comprenant un chargement sécurisé d'une clef applicative (TA) à partir d'un premier module

(AS) de sécurité d'une unité centrale vers ledit ensemble de deuxièmes modules (El) de sécurité, lesdits premier et deuxièmes modules comprenant chacun au moins une mémoire (M), caractérisé en ce qu'il comporte les étapes selon lesquelles : Pour chaque deuxième module (El) dudit ensemble (S),

- lors de chaque chargement, on calcule dans le premier module (AS) une clef (Tl) d'exploitation à partir d'une information propre au deuxième module (El), d'une clef de transport (T) et d'un algorithme de diversification (ALGO1), ladite clef de transport (T) se trouvant dans la mémoire (M) du premier module de sécurité (AS), ladite mémoire (M) étant non volatile,

- on chiffre dans le premier module (AS) la clef (TA) applicative, à partir d'informations comprenant ladite clef (Tl) d'exploitation et d'un algorithme de cryptage (ALGO2), ladite clef (TA) applicative se trouvant dans ladite mémoire (M),

- on envoie au deuxième module (El) des données (DONNEES) comprenant la clef (TA) applicative chiffrée,

- lors de chaque chargement, on calcule dans le deuxième module (El) la clef (Tl) d'exploitation à partir de l'information propre au deuxième module (El), de la clef de transport (T) et de l'algorithme de diversification (ALGO 1), ladite même clef de transport (T) se trouvant dans la mémoire (M) non volatile de chaque deuxième module (El) de sécurité dudit ensemble (S), ladite clef (Tl) d'exploitation n'étant pas enregistrée dans la mémoire (M) dudit deuxième module, - on déchiffre dans le deuxième module (El) la clef applicative (TA) chiffrée, à partir d'informations comprenant ladite clef (Tl) d'exploitation et d'un algorithme de décryptage (ALGO2P) inverse de l'algorithme de cryptage (ALGO2). 2 - Procédé selon la revendication 1 , caractérisé en ce qu'il comporte en outre une étape supplémentaire selon laquelle :

- On envoie au premier module (AS) l'information propre au deuxième module (El), préalablement au calcul dans le premier module (AS) de la clef (Tl) d'exploitation. 3 - Procédé selon les revendications 1 ou 2, caractérisé en ce qu'il comporte en outre une étape supplémentaire selon laquelle :

On envoie au premier module (AS) un nombre aléatoire issu du deuxième module (El), préalablement au chiffrement dans le premier module (AS) de la clef applicative (TA) . 4 - Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comporte en outre une étape supplémentaire selon laquelle :

- On envoie au premier module (AS) une information relative à une clef applicative (TA), préalablement au chiffrement dans ledit module (AS) de la clef applicative (TA).

5 - Procédé selon la revendication 4, caractérisé en ce qu'il comporte en outre une étape supplémentaire selon laquelle :

- On choisit la clef applicative (TA) à chiffrer à partir de ladite information. 6 - Procédé selon l'une des revendications précédentes, caractérisé en ce que chaque chiffrement d'une clef applicative (TA) destinée à un deuxième module (El) est unique. 7 - Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comporte en outre une étape supplémentaire selon laquelle : - On vérifie que les données (DONNEES) comprenant la clef applicative (TA) chiffrée sont intègres.

8 - Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comporte en outre une étape supplémentaire selon laquelle :

- On envoie au deuxième module (El) une information relative à une clef applicative (TA), préalablement au déchiffrement dans ledit module (El) dudit ensemble (S) de la clef applicative (TA) chiffrée. 9 - Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comporte en outre une étape supplémentaire selon laquelle :

- On enregistre dans le deuxième module (El), après le déchiffrement de la clef applicative (TA) chiffrée, ladite clef (TA) dans ledit module (El).

10 - Procédé selon la revendication 9, caractérisé en ce que l'enregistrement dans ledit deuxième module (El) de la clef applicative (TA) se fait en fonction de l'information relative à une clef applicative (TA) . 11 - Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comporte en outre une étape supplémentaire selon laquelle :

- On vérifie que la clef applicative (TA) est authentique.

12 - Procédé selon l'une des revendications précédentes, caractérisé en ce que le premier module de sécurité (AS) est une carte à puce.

13 - Procédé selon l'une des revendications précédentes, caractérisé en ce que la mémoire (M) est une mémoire réinscriptible. 14 - Procédé selon l'une des revendications précédentes, caractérisé en ce qu'un deuxième module (El) comprend plusieurs clefs applicatives (TA).

15 - Procédé selon l'une des revendications précédentes, caractérisé en ce que le premier module (AS) comporte plusieurs clefs applicatives (TA).

16 - Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comporte en outre une étape supplémentaire selon laquelle : - Postérieurement au chiffrement de la clef applicative (TA), on efface la clef (Tl) d'exploitation sauvegardée temporairement dans une deuxième mémoire volatile du premier module (AS).

17 - Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comporte en outre une étape supplémentaire selon laquelle :

- Postérieurement au déchiffrement de la clef applicative (TA), on efface la clef (Tl) d'exploitation sauvegardée temporairement dans une deuxième mémoire (M2) volatile du deuxième module (El). 18 - Procédé selon les revendications 2 à 4 précédentes, caractérisé en ce qu'il comporte en outre une étape supplémentaire selon laquelle :

- L'information aléatoire, l'information relative (REF1) à une clef applicative (TA) et l'information (SN) propre au deuxième module (El) sont envoyées au premier module (AS) au moyen d'une unique première commande (EXPORTKEY) . 19 - Procédé selon les revendications 1 et 2 précédentes, caractérisé en ce qu'il comporte en outre une étape supplémentaire selon laquelle : La clef applicative (TA) chiffrée et l'information (REF2) relative à une clef applicative (TA), sont envoyées au deuxième module

(El) au moyen d'une unique deuxième commande

(IMPORTKEY).