et une entité électronique La présente invention concerne des procédés et des dispositifs d'échange de données, notamment d'échanges sécurisés de données, et plus particulièrement un procédé, un dispositif et un programme d'ordinateur pour optimiser la création d'un domaine applicatif sécurisé entre un système informatique et une entité électronique.

II est bien connu d'utiliser des clés cryptographiques afin de sécuriser des échanges de données entre deux systèmes informatiques ou électroniques, via un réseau de communication, par exemple au moyen du chiffrage des messages à échanger par une ou plusieurs de ces clés cryptographiques.

Dans ce contexte, il est naturellement nécessaire d'effectuer au préalable des étapes d'initialisation qui permettent à chacun des systèmes mis en œuvre (et à eux seuls) de pouvoir chiffrer et déchiffrer les messages qu'ils s'échangent.

Une solution pour ce faire est qu'une personne (par exemple un fournisseur de services ou d'applications) souhaitant communiquer de manière sécurisée avec un interlocuteur (par exemple un utilisateur du service ou de l'application) envoie physiquement à cet interlocuteur une entité électronique (par exemple de type carte à microcircuit) mémorisant les clés cryptographiques nécessaires, qui seront alors utilisées par des appareils de cette personne et cet interlocuteur pour mettre en œuvre des échanges sécurisés.

Cette solution, qui nécessite l'envoi physique de l'entité électronique, est naturellement peu pratique. En effet, il est souhaitable de pouvoir échanger à distance les clés cryptographiques nécessaires (par exemple pour installer une communication sécurisée avec un nouveau fournisseur d'applications sur une entité électronique déjà détenue par l'utilisateur).

Cependant, il est préférable de mettre en œuvre cet échange de clés cryptographiques sans recourir à un éventuel système de sécurité fourni par le réseau utilisé pour la communication à distance, afin d'assurer au maximum la sécurité de la communication entre les systèmes des deux interlocuteurs sans impliquer un organisme tiers dans cette recherche de sécurité.

L'invention permet de résoudre au moins un des problèmes exposés précédemment.

L'invention a ainsi pour objet un procédé pour optimiser la création d'un domaine applicatif sécurisé entre un système informatique et une entité électronique via un réseau de communication, ce procédé, mis en œuvre dans ladite entité électronique, comprenant les étapes suivantes,

- génération d'un code, par exemple un nombre aléatoire, et transmission dudit code généré audit système informatique ;

- suite à ladite transmission dudit code généré, réception d'un certificat et d'une signature, ladite signature ayant été calculée au moins à partir dudit code généré, ledit certificat et ladite signature étant reçus dudit système informatique et permettant l'authentification dudit système informatique ;

- vérification de la validité dudit certificat et de ladite signature reçus, ladite signature étant vérifiée selon ledit code généré, pour authentifier ledit système informatique ; et

- en réponse à ladite authentification dudit système informatique, si ledit système informatique est authentifié, génération d'au moins une clé cryptographique permettant la création dudit domaine applicatif sécurisé.

Le procédé selon l'invention permet ainsi d'optimiser la création d'un domaine applicatif sécurisé entre un système informatique et une entité électronique en limitant le nombre d'échanges de données entre ce système informatique et cette entité électronique. La signature et le certificat peuvent, par exemple, être reçus sous la forme d'un train de données unidirectionnel, notamment d'une même commande APDU.

Selon un mode de réalisation particulier, le procédé comprend en outre une étape de réception d'une instruction d'établissement d'un domaine applicatif sécurisé, ladite instruction étant reçue dudit système informatique, ladite étape de génération et de transmission dudit code étant effectuée en réponse à ladite étape de réception d'une instruction d'établissement d'un domaine applicatif sécurisé. Une telle instruction, par exemple conforme au standard GlobalPIatform, peut notamment être reçue sous forme de commande APDU.

Toujours selon un mode de réalisation particulier, ladite étape de transmission dudit code généré en réponse à ladite réception d'une instruction d'établissement d'un domaine applicatif sécurisé comprend une étape de transmission d'un accusé-réception de ladite instruction d'établissement d'un domaine applicatif sécurisé. L'accusé-réception peut être transmis avec le code généré, par exemple sous la forme d'un train de données unidirectionnel, notamment d'une même réponse APDU.

Toujours selon un mode de réalisation particulier, ladite étape de réception d'un certificat et d'une signature comprend en outre une étape de réception d'une clé cryptographique temporaire, ladite clé cryptographique temporaire étant utilisée pour générer ladite au moins une clé cryptographique permettant la création dudit domaine applicatif sécurisé.

Toujours selon un mode de réalisation particulier, ladite étape de génération d'au moins une clé cryptographique permettant la création dudit domaine applicatif sécurisé comprend une étape de calcul d'un secret commun, ladite au moins une clé cryptographique permettant la création dudit domaine applicatif sécurisé étant générée à partir dudit secret commun.

Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape d'obtention d'une clé cryptographique pour vérifier ladite signature reçue, ladite clé cryptographique pour vérifier ladite signature reçue étant extraite dudit certificat reçu.

Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de génération et de transmission d'un message de validation, ledit message de validation étant généré et transmis en réponse à ladite étape de génération d'au moins une clé cryptographique permettant la création dudit domaine applicatif sécurisé.

L'invention a également pour objet un procédé pour optimiser la création d'un domaine applicatif sécurisé entre un système informatique et une entité électronique via un réseau de communication, ce procédé, mis en œuvre dans ledit système informatique, comprenant les étapes suivantes,

- réception d'un code, ledit code étant reçu de ladite entité électronique ;

- en réponse à la réception dudit code, calcul d'une signature à partir d'au moins ledit code reçu et transmission de ladite signature calculée et d'un certificat, ledit certificat et ladite signature permettant l'authentification dudit système informatique, ladite signature calculée et ledit certificat étant transmis à ladite entité électronique ; et

- génération d'au moins une clé cryptographique permettant la création dudit domaine applicatif sécurisé.

Le procédé selon l'invention permet ainsi d'optimiser la création d'un domaine applicatif sécurisé entre un système informatique et une entité électronique en limitant le nombre d'échanges de données entre ce système informatique et cette entité électronique. La signature et le certificat peuvent, par exemple, être transmis sous la forme d'un train de données unidirectionnel, notamment d'une même commande APDU.

Selon un mode de réalisation particulier, le procédé comprend en outre une étape de transmission d'une instruction d'établissement d'un domaine applicatif sécurisé, ladite instruction étant transmise à ladite entité électronique, ladite étape de réception dudit code étant effectuée suite à ladite transmission d'une instruction d'établissement d'un domaine applicatif sécurisé. Une telle instruction, par exemple conforme au standard GlobalPIatform, peut notamment être reçue sous forme de commande APDU.

Toujours selon un mode de réalisation particulier, le procédé comprend en outre les étapes suivantes :

- génération d'une clé cryptographique temporaire comprenant une clé cryptographique privée temporaire et une clé cryptographique publique temporaire ; et

- transmission de ladite clé cryptographique publique temporaire à ladite entité électronique suite à la réception dudit code, ladite génération d'au moins une clé cryptographique permettant la création dudit domaine applicatif sécurisé étant au moins basée sur ladite clé cryptographique privée temporaire générée.

Toujours selon un mode de réalisation particulier, ladite étape de génération d'au moins une clé cryptographique permettant la création dudit domaine applicatif sécurisé comprend une étape de calcul d'un secret commun, ladite au moins une clé cryptographique permettant la création dudit domaine applicatif sécurisé étant générée à partir dudit secret commun.

Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de réception d'un message de validation, ledit message de validation étant reçu de ladite entité électronique, et une étape de contrôle dudit message de validation reçu.

L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur, un moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé décrit précédemment et un dispositif comprenant des moyens adaptés à la mise en œuvre de chacune des étapes du procédé décrit précédemment.

Les avantages procurés par ce programme d'ordinateur, ce moyen de stockage d'informations comportant des instructions de code d'un programme d'ordinateur et ce dispositif sont similaires à ceux évoqués précédemment.

D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels :

- la figure 1 représente schématiquement un exemple d'environnement dans lequel au moins un mode de réalisation de l'invention peut être mis en œuvre ; - la figure 2 illustre un exemple d'entité électronique adaptée à mettre en œuvre l'invention selon un mode de réalisation particulier ; et

- la figure 3 illustre schématiquement un exemple d'échange de données entre un système informatique d'un fournisseur de service et une entité électronique mettant en œuvre des applications de type ISD, APSD et CASD selon un mode de réalisation particulier de l'invention.

Comme cela ressort de la description qui suit, l'invention vise, de façon générale, l'échange de clés cryptographiques entre une entité électronique, par exemple une carte à microcircuit, et un système informatique proposant un service (par la mise en œuvre d'une application) à l'utilisateur détenteur de la carte à microcircuit pour créer un domaine applicatif sécurisé. Cependant, si un tel domaine est généralement établi suite à une phase d'initialisation comprenant l'authentification du système distant, l'invention permet, selon un mode de réalisation particulier, de combiner les phases d'authentification et de création du domaine applicatif sécurisé.

Ainsi, selon ce mode de réalisation, en réponse à la réception d'une commande de fourniture de service reçue d'un système informatique, une entité électronique génère un code qui est transmis au système informatique à l'origine de la commande de fourniture de service. Ce code est utilisé par le système informatique pour générer une signature qui est transmise, en retour, avec un certificat d'authentification, à l'entité électronique ayant généré et émis le code. L'entité électronique peut alors authentifier le système électronique avec le certificat et la signature reçus, calculer un secret commun et, à partir de ce dernier, générer des clés cryptographiques permettant de créer un domaine applicatif sécurisé entre l'entité électronique et le système informatique (ce dernier pouvant générer des clés cryptographiques correspondantes après avoir transmis le certificat et la signature).

Selon un autre mode de réalisation, le code généré et transmis par l'entité électronique, en réponse à la réception d'une commande de fourniture de service, peut être généré et transmis par l'entité électronique avec une requête de service, sans réception préalable d'une commande de fourniture de service, par exemple en réponse à une requête d'une application exécutée par l'entité électronique.

La figure 1 représente schématiquement un exemple d'environnement dans lequel au moins un mode de réalisation de l'invention peut être mis en œuvre. Comme illustré, la carte à microcircuit 2 est insérée dans un téléphone cellulaire 4 qui peut échanger des données, via l'infrastructure d'un réseau de communication 10, ici un réseau de téléphonie mobile déployé par un opérateur, avec des dispositifs extérieurs, en particulier le système informatique 12 proposant des services.

Les échanges de données entre le téléphone cellulaire 4 et le système informatique 12 transitent notamment par une station de base 6 ainsi que, le cas échéant, par d'autres équipements de l'opérateur, par exemple l'équipement référencé 8, qui peuvent autoriser des interconnexions à d'autres réseaux, tels que le réseau Internet, auquel est par exemple relié le système informatique 12.

Une autorité de contrôle 14 peut également entrer en communication avec le téléphone cellulaire 4 et le système informatique 12, par exemple (mais non nécessairement) à travers le réseau de communication 10.

Ce réseau de communication 10 permet l'échange de données de manière sécurisée entre les différents dispositifs.

Le fournisseur de services qui gère le système informatique 12 est par exemple une banque qui souhaite pouvoir échanger des données de manière sécurisée entre son système informatique 12 et l'ensemble formé par le téléphone cellulaire 4 et la carte à microcircuit 2. A ces fins, le fournisseur de services échange des clés cryptographiques avec la carte à microcircuit 2, de manière sécurisée et indépendamment des mécanismes de sécurité du réseau de communication 10, afin de créer un domaine applicatif sécurisé.

Comme représenté en figure 2, la carte à microcircuit 2 est équipée d'un microprocesseur 20 apte à exécuter des applications mémorisées (par exemple sous forme d'applets) dans une mémoire non volatile 22 de la carte à microcircuits 2, dont une application ISD (sigle ô'Issuer Security Domain en terminologie anglo-saxonne) fournie par l'émetteur de la carte (en général associé à l'opérateur du réseau de télécommunications 10), une application CASD (sigle de Controlling Authority Security Domain en terminologie anglo- saxonne) associée à l'autorité de contrôle 14, et une ou plusieurs applications APSD (sigle d'Application Provider Security Domain en terminologie anglo- saxonne) associées chacune à un fournisseur de services. Ces applications, qui sont aptes à mettre en œuvre des échanges de messages sécurisés et à gérer les données mémorisées dans la carte à microcircuit, permettent de créer (typiquement par instanciation d'un APSD), généralement à l'aide de clés cryptographiques, des environnements ou domaines applicatifs sécurisés (appelés security domains en terminologie anglo-saxonne). Comme illustré, la carte à microcircuit 2 comprend en outre une mémoire de travail 24, typiquement une mémoire de type RAM (acronyme de Random Access Memory en terminologie anglo-saxonne), intégrée ou non au microprocesseur 20, et une interface de communication 26. La carte à microcircuit 2 est par exemple conforme à la norme ISO 7816.

Les applications ISD, CASD et APSD sont, par exemple, conformes à la définition qui leur est donnée par la norme connue sous le nom de Global Platform (GlobalPIatform est une marque). Alternativement, ces applications peuvent être combinées ou partiellement combinées dans une ou plusieurs applications et/ou un système d'exploitation.

Le système (notamment un système d'exploitation de la carte ou une machine virtuelle et ses composants mis en œuvre par la carte) est conçu de telle sorte que l'application du domaine de sécurité a accès exclusif (ou réservé) à des données sécurisées auxquelles d'autres applications ne peuvent accéder.

II convient néanmoins de remarquer que si les autres applications ne peuvent accéder à ces données sécurisées, elles peuvent les utiliser à travers une application du domaine de sécurité concerné.

L'application ISD qui représente l'opérateur au sein de la carte à microcircuit est notamment chargée de l'installation et de l'instanciation des applications APSD.

L'application CASD est quant à elle utilisée pour la vérification des certificats et le chiffrement des données comme décrit ci-après. Chacune des applications APSD permet, de préférence, à l'aide d'un domaine applicatif sécurisé, des échanges sécurisés avec des dispositifs extérieurs. Un domaine sécurisé est ici mis en œuvre au moyen de canaux sécurisés par des ensembles de clés cryptographiques implantées dans la carte à microcircuits au cours d'une phase d'initialisation décrite en détail dans la suite, sans recourir à des mécanismes de sécurité du réseau de télécommunications 10.

Selon un mode de réalisation particulier, la norme connue sous le nom de GlobalPIatform peut être utilisée lors d'une phase d'initialisation pour créer un domaine applicatif sécurisé.

La figure 3 illustre schématiquement un exemple d'échange de données entre un système informatique d'un fournisseur de service (noté AP, sigle d'Application Provider en terminologie anglo-saxonne) et une entité électronique mettant en œuvre des applications de type ISD, APSD et CASD selon un mode de réalisation particulier de l'invention. En d'autres termes, la figure 3 représente certaines étapes de l'instanciation d'une application de type APSD

Une première étape d'échange (étape 300) a ici pour objet une demande de fourniture d'un service. Une telle demande peut prendre la forme d'une commande transmise dans une requête. Conformément à la norme GlobalPIatform, la commande install est utilisée pour créer une instance d'un service APSD dans l'entité électronique, permettant au système informatique d'offrir ce service.

Comme illustré sur la figure 3, la commande install est transmise du système informatique à l'application ISD de l'entité électronique. Selon un mode de réalisation particulier, la commande install est transmise sous forme d'un message connu sous le nom de commande APDU (sigle d'Application Protocol Data Unit en terminologie anglo-saxonne).

Sur réception de cette commande, cette application initie l'instanciation du service APSD et, ainsi, la création d'un domaine applicatif sécurisé entre l'application APSD de l'entité électronique et le système informatique. Si l'application ISD ne peut instancier le service APSD, un message d'erreur est adressé au système informatique (non représenté) et le processus prend fin.

Dans le cas contraire, au cours de cette étape d'initiation de l'instanciation du service APSD, une commande est adressée (par l'application ISD) à l'application CASD de l'entité électronique afin que l'application CASD génère un code, noté RC (sigle de Random Challenge en terminologie anglo- saxonne), par exemple un nombre aléatoire (étape 305). L'application CASD transmet ce code à l'application ISD.

Le code généré RC est alors transmis par l'application ISD de l'entité électronique au système informatique au cours d'une deuxième étape d'échange (étape 310). Un accusé-réception (ACK, consistant ou comprenant, par exemple, le message connu sous le nom de Confirmation Data selon la norme GlobalPIatform) est, de préférence, transmis par l'application ISD au système informatique avec le code généré.

Selon un mode de réalisation particulier, le code généré et, le cas échéant, l'accusé-réception peuvent être transmis sous la forme d'un train de données unidirectionnel, notamment sous la forme d'une même réponse APDU.

Selon un mode de réalisation particulier, le système informatique génère alors une paire de clés cryptographiques temporaires ou éphémères (étape 315) qui comprend une clé privée et une clé publique notées eSK.AP.KA et ePK.AP.KA, respectivement (où SK et PK sont les sigles de Secret Key et Public Key, respectivement, et KA le sigle de Key Agreement en terminologie anglo-saxonne). Ces clés cryptographiques temporaires d'agrément peuvent être utilisées, par exemple, pour l'exécution de l'un des algorithmes connus sous le nom de Diffie-Hellmann et ECKA (sigle d'Elliptic Curve Key Agreement en terminologie anglo-saxonne).

Par ailleurs, au cours d'une étape 320, le système informatique signe des données comprenant le code précédemment reçu (RC) et la clé publique temporaire générée (ePK.AP.KA) à partir d'une clé cryptographique privée notée SK.AP.DS (où DS est le sigle de Digital Signature en terminologie anglo- saxonne). Cette clé cryptographique utilisée pour signer des données peut être utilisée, par exemple, pour l'exécution de l'un des algorithmes connus sous le nom de DSA (sigle de Digital Signature Algorithm en terminologie anglo- saxonne), ECDSA (sigle à'Elliptic Curve Digital Signature Algorithm en terminologie anglo-saxonne) et RSA (sigle de Rivest Shamir Adleman). De façon générale, le calcul d'une signature peut notamment comprendre une étape d'encryptage des données à signer à l'aide d'une clé cryptographique.

La signature ainsi calculée, notée S, est alors transmise par le système informatique à l'application ISD de l'entité électronique, au cours d'une troisième étape d'échange (étape 325), avec la clé publique temporaire générée (ePK.AP.KA) et un certificat noté CERT.AP.DS. Comme illustré, l'application ISD retransmet les données reçues à l'application CASD de l'entité électronique. Alternativement, ces données peuvent être transmises directement du système informatique à l'application CASD ou à l'application APSD.

Le certificat CERT.AP.DS est ici un certificat signé par une autorité de certification (organisme tiers), à l'aide d'une clé cryptographique privée connue de cette seule autorité, comprenant un identifiant de l'émetteur (ici le système informatique) et une clé cryptographique publique correspondant à une clé cryptographique privée connue du seul émetteur (ici le système informatique), par exemple les clés PK.AP.DS et SK.AP.DS, respectivement. Le certificat comprend donc ici un identifiant de l'émetteur, une clé cryptographique publique correspondant à une clé cryptographique privée connue du seul émetteur et une signature de cet identifiant et de cette clé publique (cette signature étant obtenue à l'aide d'une clé cryptographique privée seulement connue d'une autorité de certification).

La signature calculée (S), la clé publique temporaire générée (ePK.AP.KA) et le certificat (CERT.AP.DS) peuvent être transmis, par exemple, sous la forme d'un train de données unidirectionnel, notamment sous la forme d'une même commande APDU.

Lors de la réception de ces données, l'application CASD de l'entité électronique reconnaît le système informatique (étape 330) à l'aide du certificat reçu et vérifie la validité de ce certificat en utilisant la clé cryptographique publique correspondant à la clé cryptographique privée connue de la seule autorité (utilisée pour signer le certificat) qui est accessible auprès de cette autorité (et obtenue précédemment ou sur requête). Si le certificat reçu du système informatique est valide, l'application CASD de l'entité électronique extrait de celui-ci la clé cryptographique publique PK.AP.DS (étape 330).

L'application CASD de l'entité électronique utilise alors la clé cryptographique publique PK.AP.DS, toujours au cours de l'étape 330, pour vérifier la validité de la signature S reçue (signée à l'aide de la clé cryptographique privée correspondant à la clé cryptographique publique PK.AP.DS).

La validité du certificat et de la signature reçus permet d'authentifier le système informatique.

Si la signature S reçue est valide, l'application CASD de l'entité électronique calcule, toujours au cours d'une étape 330, un secret commun, connu sous le nom de SHS (sigle de SHared Secret en terminologie anglo- saxonne), à partir de la clé cryptographique publique éphémère reçue (ePK.AP.KA) et d'une clé cryptographique privée SK.CASD.KA connue de la seule application CASD de l'entité électronique (dont une clé cryptographique publique correspondante, notée PK.CASD.KA a été précédemment transmise au système informatique ou lui est transmise sur simple requête). Le secret commun est utilisé comme graine pour la génération d'un ensemble de clés cryptographiques secrètes, noté KS (sigle de Key Set en terminologie anglo- saxonne), à l'aide d'un algorithme prédéterminé. Il est observé ici que d'autres données peuvent être utilisées comme graines, conjointement avec le secret commun, pour la génération de l'ensemble de clés cryptographiques secrètes KS.

Parallèlement, le système informatique calcule un secret commun SHS à partir de la clé cryptographique privée temporaire (eSK.AP.KA) et de la clé cryptographique publique PK.CASD.KA correspondant à la clé cryptographique privée SK.CASD.KA (étape 335). Ce secret commun est identique à celui calculé dans l'entité électronique et permet ainsi de générer (en utilisant le même algorithme) le même ensemble KS de clés cryptographiques que celui généré dans l'entité électronique. A nouveau, il est observé ici que d'autres données peuvent être utilisées comme graines, conjointement avec le secret commun, pour la génération de l'ensemble de clés cryptographiques secrètes KS.

Les clés cryptographiques (KS) générées par le système informatique et l'application CASD de l'entité électronique permettent la création d'un domaine applicatif sécurisé (noté ici secure domain).

De façon optionnelle (comme illustré par les flèches en trait pointillé), l'application CASD de l'entité électronique peut générer un message de validation (ou reçu), après avoir calculé les clés cryptographiques SHS, qui est transmis à l'application ISD puis au système électronique, lors d'une quatrième étape d'échange (étape 340), afin de permettre à ce dernier de contrôler le bon déroulement des opérations effectuées dans l'entité électronique (étape 345).

Ainsi, comme décrit en référence à la figure 3, l'invention permet, selon un mode de réalisation particulier, de limiter le nombre d'échanges entre le système informatique et l'entité électronique en combinant plusieurs étapes d'authentification d'un système distant avec la création d'un domaine applicatif sécurisé.

Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente. La présente invention ne se limite pas aux formes de réalisation décrites, d'autres variantes et combinaisons de caractéristiques sont possibles.

La présente invention a été décrite et illustrée dans la présente description détaillée en référence aux figures jointes. Toutefois, la présente invention ne se limite pas aux formes de réalisation présentées. D'autres variantes et modes de réalisation peuvent être déduits et mis en œuvre par la personne compétente dans le domaine de l'invention à la lecture de la présente description et des figures annexées. En particulier, la mise en œuvre de l'invention ne se limite pas à la création d'un domaine applicatif sécurisé entre un système informatique et une entité électronique. Elle peut être mise en œuvre entre d'autres systèmes distants, par exemple entre deux systèmes informatiques ou entre deux entités électroniques. L'entité électronique et le système informatique doivent donc être interprétés selon un sens large. De même, l'invention peut être mise en œuvre avec d'autres normes que la norme connue sous le nom de Global Platform.

L'entité électronique peut être une carte à microcircuit ou tout autre circuit intégré, de préférence sécurisé, typiquement conforme aux critères communs ou à la norme FI PS (acronyme de Fédéral Information Processing Standard en terminologie anlgo-saxonne).

Dans les revendications, le terme « comporter » n'exclut pas d'autres éléments ou d'autres étapes. L'article indéfini « un » n'exclut pas le pluriel. Un seul processeur ou plusieurs autres unités peuvent être utilisées pour mettre en œuvre l'invention. Les différentes caractéristiques présentées et/ou revendiquées peuvent être avantageusement combinées. Leur présence dans la description ou dans des revendications dépendantes différentes n'exclut pas, en effet, la possibilité de les combiner. Les signes de référence ne sauraient être compris comme limitant la portée de l'invention.