FR3030831A1 - Entite electronique securisee, appareil electronique et procede de verification de l’integrite de donnees memorisees dans une telle entite electronique securisee - Google Patents

Entite electronique securisee, appareil electronique et procede de verification de l’integrite de donnees memorisees dans une telle entite electronique securisee Download PDF

Info

Publication number
FR3030831A1
FR3030831A1 FR1463256A FR1463256A FR3030831A1 FR 3030831 A1 FR3030831 A1 FR 3030831A1 FR 1463256 A FR1463256 A FR 1463256A FR 1463256 A FR1463256 A FR 1463256A FR 3030831 A1 FR3030831 A1 FR 3030831A1
Authority
FR
France
Prior art keywords
secure electronic
electronic entity
integrity
secure
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1463256A
Other languages
English (en)
Other versions
FR3030831B1 (fr
Inventor
Emmanuelle Dottax
Florian Galdo
Christophe Giraud
Jean-Philippe Vallieres
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Idemia France SAS
Original Assignee
Oberthur Technologies SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oberthur Technologies SA filed Critical Oberthur Technologies SA
Priority to FR1463256A priority Critical patent/FR3030831B1/fr
Priority to KR1020177020623A priority patent/KR20170097771A/ko
Priority to PCT/FR2015/053595 priority patent/WO2016102833A1/fr
Priority to EP15828654.2A priority patent/EP3238200A1/fr
Priority to US15/538,709 priority patent/US20170353315A1/en
Publication of FR3030831A1 publication Critical patent/FR3030831A1/fr
Application granted granted Critical
Publication of FR3030831B1 publication Critical patent/FR3030831B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44Program or device authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/64Protecting data integrity, e.g. using checksums, certificates or signatures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/602Providing cryptographic facilities or services
    • GPHYSICS
    • G09EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09CCIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/006Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving public key infrastructure [PKI] trust models
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0631Substitution permutation network [SPN], i.e. cipher composed of a number of stages or rounds each involving linear and nonlinear transformations, e.g. AES algorithms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10Integrity
    • H04W12/106Packet or message integrity

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Power Engineering (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne une entité électronique sécurisée (E) comprenant une mémoire (NV) mémorisant des données sous forme de multiplets et un module de traitement (M) conçu pour recevoir des données en provenance d'un dispositif électronique (TP). Le module de traitement (M) est conçu pour déterminer un élément de preuve d'intégrité en fonction des données reçues et d'une partie au moins des multiplets mémorisés, et pour émettre l'élément de preuve d'intégrité à destination du dispositif électronique (TP). Un procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée (E) est également décrit.

Description

DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne la vérification de l'intégrité de données mémorisées dans une entité électronique sécurisée.
Elle concerne plus particulièrement une entité électronique sécurisée, un appareil électronique et un procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée. L'invention s'applique particulièrement avantageusement dans le cas où les données mémorisées sont au moins en partie secrètes et doivent donc être 10 chiffrées lorsqu'elles sont mémorisées en dehors de l'entité électronique sécurisée. ARRIERE-PLAN TECHNOLOGIQUE On connaît des entités électroniques sécurisées, telles que des cartes à microcircuit ou des éléments sécurisés intégrés, qui mémorisent des données 15 confidentielles, par exemple des clés cryptographiques secrètes, utilisées par exemple dans des applications de chiffrement de message électronique, de signature électronique ou d'identification. Bien que ces entités électroniques sécurisées soit conçues pour rendre quasiment impossible toute intrusion dans leur fonctionnement, il est souhaitable 20 de vérifier de temps à autre, par exemple périodiquement, que les données mémorisées dans une entité électronique donnée sont intègres (c'est-à-dire qu'elles n'ont pas été altérées). OBJET DE L'INVENTION Dans ce contexte, la présente invention propose une entité électronique 25 sécurisée comprenant une mémoire mémorisant des données sous forme de multiplets et un module de traitement conçu pour recevoir des données en provenance d'un dispositif électronique, caractérisée en ce que le module de traitement est conçu pour déterminer un élément de preuve d'intégrité en fonction des données reçues et d'une partie au moins des multiplets mémorisés, et pour 30 émettre l'élément de preuve d'intégrité à destination du dispositif électronique. Ainsi, l'entité électronique sécurisée est conçue pour renvoyer un élément de preuve d'intégrité déterminé par combinaison des données reçues et des multiplets mémorisés. Un tel élément de preuve permet d'attester que les données mémorisées (sous forme de multiplets) au moment où l'entité électronique reçoit les données en provenance du dispositif électronique extérieur (par exemple un auditeur tiers) sont bien celles attendues, sans quoi l'entité électronique sécurisée ne pourrait pas produire l'élément de preuve correct. Selon des caractéristiques optionnelles (et donc non limitatives) : - les données reçues représentent une valeur aléatoire (générée par exemple par le dispositif électronique) ; - les données reçues désignent des régions de la mémoire ; - le module de traitement est conçu pour déterminer l'élément de preuve d'intégrité en fonction des multiplets mémorisés dans les régions désignées par les données reçues ; - le module de traitement est conçu pour déterminer l'élément de preuve d'intégrité en partie au moyen (c'est-à-dire au moyen notamment) d'un chiffrement des multiplets mémorisés ; - l'entité électronique sécurisée comprend un module de mise en oeuvre du chiffrement en fonction d'une clé secrète mémorisée dans l'entité électronique ; - le module de traitement est conçu pour déterminer l'élément de preuve d'intégrité au moyen d'une fonction de signature ou d'une fonction de hachage ou d'une fonction de génération de code d'authentification de message ; - ladite entité électronique sécurisée est une carte d'accès à un réseau de téléphonie mobile. L'invention propose également un téléphone cellulaire comprenant une entité électronique sécurisée telle que proposée ci-dessus, par exemple soudée au téléphone cellulaire. L'invention propose aussi un compteur de fourniture d'énergie comprenant une entité électronique sécurisée telle que proposée ci-dessus, par exemple soudée audit compteur. L'invention propose par ailleurs un système électronique embarqué pour véhicule (par exemple pour véhicule automobile) comprenant une entité électronique sécurisée telle que proposée ci-dessus, éventuellement soudée au système électronique. L'invention propose en outre un appareil électronique comprenant un module de communication en champ proche et une entité électronique sécurisée telle que proposée ci-dessus reliée au module de communication en champ proche.
L'invention propose également un procédé de vérification de l'intégrité de données mémorisées dans une entité électronique sécurisée, caractérisé en ce qu'il comprend les étapes suivantes : - émission, par un dispositif électronique, de données à destination de l'entité électronique sécurisée ; - réception des données par l'entité électronique sécurisée ; - détermination d'un élément de preuve d'intégrité en fonction des données reçues et d'une partie au moins des multiplets mémorisés dans une mémoire de l'entité électronique sécurisée ; - émission, par l'entité électronique sécurisée, de l'élément de preuve d'intégrité à destination du dispositif électronique. Un tel procédé peut comprendre en outre une étape de détermination d'une partie au moins des données émises par tirage aléatoire (par exemple au sein du dispositif électronique).
Selon une première possibilité de réalisation, les données reçues peuvent représenter une valeur aléatoire utilisée en tant que paramètre lors de l'application d'une fonction. Selon une seconde possibilité de réalisation, les données reçues peuvent désigner des régions de la mémoire ; la détermination de l'élément de preuve d'intégrité peut dans ce cas être réalisée en fonction des multiplets mémorisés dans les régions désignées par les données reçues. Selon d'autres caractéristiques optionnelles : - la détermination de l'élément de preuve d'intégrité comprend un chiffrement des multiplets mémorisés ; - le chiffrement des multiplets mémorisés utilise une clé secrète mémorisée dans l'entité électronique sécurisée ; - l'élément de preuve d'intégrité est déterminé par application d'une fonction de signature ou d'une fonction de hachage ou d'une fonction de génération de code d'authentification de message ; - ledit dispositif électronique est un auditeur tiers. DESCRIPTION DETAILLEE D'UN EXEMPLE DE REALISATION La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée.
Sur les dessins annexés : - la figure 1 représente un système dans lequel est utilisée une entité électronique sécurisée conforme à l'invention ; - la figure 2 représente schématiquement les informations mémorisées dans un serveur d'un auditeur tiers et dans une mémoire non volatile de l'entité électronique sécurisée conformément à un premier mode de réalisation de l'invention ; - la figure 3 représente les étapes principales d'un premier exemple de procédé mis en oeuvre dans le cadre de l'invention ; - la figure 4 représente les étapes principales d'un second exemple de procédé mis en oeuvre dans le cadre de l'invention ; - les figures 5 à 7 représentent schématiquement des algorithmes utilisables dans le cadre du procédé de la figure 4; - la figure 8 représente les étapes principales d'un troisième exemple de procédé mis en oeuvre dans le cadre de l'invention ; et - la figure 9 représente les étapes principales d'un quatrième exemple de procédé mis en oeuvre dans le cadre de l'invention. La figure 1 représente schématiquement les éléments principaux d'un système dans lequel peut être mise en oeuvre l'invention.
Un tel système comprend un appareil électronique A pourvu d'un module de communication COM afin d'échanger des données avec d'autres dispositifs électroniques, comme décrit ci-après. L'appareil électronique A peut être un téléphone cellulaire et/ou intelligent (en anglais : "smartphone"), une tablette numérique ou tout autre appareil électronique dont on souhaite qu'il puisse échanger des données avec des dispositifs électroniques extérieurs, par exemple un compteur de fourniture d'énergie, un appareil électroménager ou un système électronique embarqué dans un véhicule automobile. Le module de communication COM permet d'établir une communication bidirectionnelle (ici sans fil) avec une architecture de réseau N, qui est elle-même connectée au réseau Internet INT. Selon une première possibilité de réalisation, l'architecture de réseau N peut être un réseau de téléphonie mobile, auquel cas le module de communication COM est conçu pour entrer en communication avec une station de base du réseau de téléphonie mobile. Selon une seconde possibilité de réalisation, l'architecture de réseau N peut être un point d'accès d'un réseau local sans fil ou WLAN (pour "Wireless Local Area Network"), auquel cas le module de communication COM est conçu pour rejoindre ce réseau local. Dans les deux cas, le module de communication COM permet d'accéder au réseau Internet INT à travers l'architecture de réseau N. Ainsi, un processeur P de l'appareil électronique A (par exemple un microprocesseur) relié au module de communication COM peut échanger des données avec des dispositifs électroniques (tels que des ordinateurs ou des serveurs) connectés au réseau Internet, notamment un auditeur tiers (ou TPA pour "Third Party Auditor") TP et un émetteur d'entités électroniques ISS. L'appareil électronique A comprend également une entité électronique sécurisée E, par exemple une carte à microcircuit, éventuellement universelle (ou UICC pour "Universal Integrated Circuit Card') telle que visée dans la spécification technique ETSI TS 102 221, un élément sécurisé intégré (ou eSE pour "embedded Secure Element") tel que visé dans la spécification "GlobalPlatform Card Specification version 2.2.1" ou un autre type d'élément sécurisé. Dans le cas où l'entité électronique sécurisée E est une carte à microcircuit, il peut s'agir par exemple d'une carte d'accès à un réseau de téléphonie mobile, tel qu'une carte de type USIM (pour "Universal Subscriber Identity Module"), ou d'un jeton sécurisé (en anglais : "secure token"). L'entité électronique sécurisée E peut être montée dans l'appareil A de manière amovible (comme c'est le cas pour une carte à microcircuit réalisée selon l'un des formats 2FF, 3FF ou 4FF, ou, de manière générale, selon un format de dimensions inférieures à celles du format 2FF), ou de manière inamovible (par exemple soudée) comme dans le cas d'un élément sécurisé intégré (eSE déjà mentionné ci-dessus) ou une carte à microcircuit intégré (également dénommée eUICC pour "embedded Universal Integrated Circuit Card").
L'entité électronique sécurisée E est ici reliée au processeur P de l'appareil électronique A et a ainsi accès, via ce processeur P, au module de communication COM. En variante, l'entité électronique sécurisée E pourrait être directement reliée au module de communication COM. Comme illustré en figure 1, l'entité électronique sécurisée comprend elle- même un microprocesseur M, une mémoire vive V et au moins une mémoire non-volatile NV, par exemple une mémoire non volatile réinscriptible de type EEPROM (pour "Electrically Erasable and Programmable Read-Only Memory") ou Flash. La mémoire non-volatile NV mémorise des instructions de programme d'ordinateur qui, lorsqu'elles sont exécutées par le microprocesseur M, permettent la mise en oeuvre de procédés, tels que les procédés donnés ci-dessous à titre d'exemple. L'entité électronique sécurisée E mémorise également des données, notamment des données confidentielles telles que des clés secrètes (par exemple notamment les clés cryptographiques K1, K2 utilisées dans les exemples donnés ci-dessous). L'entité électronique sécurisée E peut ainsi mettre en oeuvre (comme déjà indiqué, du fait de l'exécution, par son microprocesseur M, d'instructions mémorisées dans la mémoire non-volatile NV, voire dans la mémoire vive V) un procédé de chiffrement au moyen d'une clé cryptographique et/ou un procédé de déchiffrement au moyen d'une clé cryptographique et/ou un procédé de signature au moyen d'une clé cryptographique et/ou un procédé de génération d'un code d'authentification utilisant une donnée secrète et/ou un procédé de génération d'une réponse à un défi par utilisation d'une donnée secrète Pour chacun de ces procédés, la clé cryptographique ou la donnée secrète concernée est par exemple mémorisée dans la mémoire non-volatile NV. Dans certains cas, comme le cas déjà mentionné d'une carte à microcircuit universelle ou UICC, l'entité électronique sécurisée E peut également mettre en oeuvre des procédés d'initiation et d'établissement d'une communication 25 distante via le module de communication COM implanté dans l'appareil électronique A qui héberge l'entité électronique sécurisée E, par exemple au moyen de mécanismes tels que ceux communément désignés "SIM Toolkits". L'entité électronique sécurisée E peut alors avoir l'initiative du lancement d'un échange avec des dispositifs électroniques distants, tels que l'auditeur tiers TP et 30 l'émetteur ISS. Les instructions de programme et les données sont mémorisées (ici dans la mémoire non-volatile NV) sous forme de multiplets (par exemple d'octets). L'entité électronique sécurisée E est par ailleurs conçue, du fait de sa construction physique et de la conception des programmes d'ordinateur qu'elle mémorise, de façon à rendre très difficile, voire impossible, pour un attaquant l'accès (par lecture et/ou modification) aux données confidentielles qu'elle mémorise. Ainsi, l'entité électronique sécurisée E a par exemple un niveau d'assurance EAL supérieur à 4 au sens des Critères Communs (norme I5015408), par exemple une niveau EAL4+ (VAN5) ou supérieur, et/ou un niveau supérieur à 3 selon la norme FIPS 140-2 (pour "Federal information Processing Standard'). L'appareil électronique A peut également comprendre un module de communication en champ proche COM', tel qu'un module de communication NFC (pour "Near Field Communication"). En variante, on pourrait utiliser un module de communication sans fil d'un autre type, par exemple Bluetooth, ZigBee, ou autre. Un tel module de communication en champ proche COM' est ici directement relié à l'entité électronique sécurisée E, par exemple au moyen d'une liaison de type SWP (pour "Single Wire Protocon. En variante, le module de communication en champ proche COM' pourrait être relié au processeur P de l'appareil électronique A et pourrait dans ce cas échanger des données avec l'entité électronique sécurisée E via le processeur P. Le module de communication en champ proche COM' est conçu pour entrer en communication avec un lecteur (ici un lecteur NEC) lorsque ce module COM' (de même que par conséquent l'appareil électronique A) est positionné à une distance du lecteur inférieure à un seuil prédéterminé, par exemple un seuil inférieur à 0,3 m. Le lecteur et l'entité électronique sécurisée E peuvent ainsi échanger des données selon un protocole de communication sans fil, par exemple selon la norme 150 14443. En particulier, le lecteur peut émettre des commandes (telles que des commandes de type ADPU pour "Application Protocol Data Unit") via la liaison sans fil ; le module de communication en champ proche COM' reçoit ces commandes et les transmet à l'entité électronique sécurisée E (ici via la liaison SWP). L'entité électronique sécurisée E traite ces commandes (au moyen notamment des procédés mis en oeuvre dans l'entité électronique sécurisée comme décrit ci-dessus) et émet des réponses (générées par le traitement précité) via le module de communication en champ proche COM' et à destination du lecteur. L'appareil électronique A peut ainsi notamment être utilisé, grâce aux données confidentielles mémorisées dans l'entité électronique sécurisée E et aux possibilités d'échanges fournies par le module de communication en champ proche COM', comme moyen d'identification de son porteur, par exemple dans des applications de paiement (autorisation de paiement), de transport (accès au réseau de transport via un portillon automatique commandé par le lecteur), d'identité, de fidélité, etc. On décrit à présent un premier mode de réalisation de l'invention en référence aux figures 2 et 3. Comme visible en figure 2, dans ce premier mode de réalisation, la mémoire non-volatile NV de l'entité électronique sécurisée E mémorise d'une part un système d'exploitation fixe ROS et un système d'exploitation modifiable FOS. Le système d'exploitation fixe ROS est inscrit dans la mémoire non-volatile NV lors de la production de l'entité électronique sécurisée E, par exemple lors d'une phase de personnalisation au cours de laquelle des instructions de 15 programme et des données de personnalisation sont écrites dans la mémoire non-volatile NV, ici sans possibilité de modification ultérieure. Le système d'exploitation modifiable FOS est également inscrit dans la mémoire non-volatile NV lors de la phase de personnalisation, mais peut être modifié ultérieurement, par exemple à distance selon une procédure prédéfinie au 20 cours de laquelle le microprocesseur M de l'entité électronique sécurisée E entre en communication avec un serveur distant (par exemple via le module de communication COM) et écrit dans la mémoire non-volatile NV des données reçues du serveur distant, par exemple après une étape d'authentification du serveur distant. Selon une variante envisageable, un tel système d'exploitation 25 pourrait être chargé en mémoire vive pour son exécution. Comme également visible en figure 2 , l'auditeur tiers TP mémorise une pluralité de valeurs aléatoires r1, rn et une pluralité de valeurs de vérification M1, Mn respectivement associées aux valeurs aléatoires précitées. Les valeurs de vérification Mi ne sont pas communiquées à l'entité électronique sécurisée E. 30 Les valeurs aléatoires ri sont successivement communiquées à l'entité électronique sécurisée E, de façon répartie sur la durée d'utilisation de l'entité électronique sécurisée E, comme expliqué ci-après. On utilise par exemple un nombre n de valeurs aléatoires ri (et de valeurs de vérification Mi associées) tel que l'entité électronique sécurisée E ne puisse pas mémoriser l'ensemble de ces valeurs ri, Mi. Par exemple, lors d'une phase d'évaluation du système d'exploitation modifiable FOS au cours de laquelle l'auditeur tiers TP a connaissance des données formant le système d'exploitation modifiable FOS, il détermine successivement par tirage aléatoire chacune des valeurs aléatoires ri et calcule la valeur de vérification associée Mi par application d'une fonction F à cette valeur aléatoire ri et aux données qui forment le système d'exploitation modifiable FOS : Mi = F(ri, FOS). La fonction F est telle qu'il est impossible de déterminer F(ri,FOS) sans avoir connaissance de l'ensemble des données formant le système d'exploitation modifiable FOS et que les valeurs de vérification Mi ne donnent aucune information sur les données formant le système d'exploitation modifiable FOS. La fonction F est par exemple basée sur une fonction de hachage H, appliquée à la concaténation de la valeur aléatoire ri et des données formant le système d'exploitation modifiable FOS: F(ri,F0S) = H(ri II FOS), où II est l'opérateur de concaténation. La fonction de hachage H utilisée est par exemple de type SHA-256, SHA-512 ou SHA-3. En variante, la fonction F pourrait être une fonction MAC de génération de code d'authentification de message, utilisant une clé secrète K2 et, ici encore, appliquée par exemple à la concaténation de la valeur aléatoire ri et des données formant le système d'exploitation modifiable FOS : F(ri,F0S) = MAC(K2,ri II FOS). La fonction MAC utilisée est par exemple de type HMAC (basé par exemple sur SHA-256), CMAC ou CBC-MAC (basé par exemple sur l'algorithme AES). Dans le cas de l'utilisation d'une fonction de génération de code d'authentification de message, la clé secrète 1<2 est mémorisée par l'auditeur tiers TP pour effectuer le calcul des valeurs de vérification Mi comme il vient d'être indiqué et par l'entité électronique sécurisée E pour le calcul d'un élément de preuve comme expliqué plus bas. Selon une variante envisageable, on pourrait utiliser (plutôt qu'un code d'authentification de message) une signature produite au moyen d'une clé privée d'une infrastructure à clé publique (ou PKI pour "Public Key Infrastructure"). On remarque que, pour l'application de la fonction F, on considère la forme brute des multiplets mémorisés dans la zone concernée (notamment les données formant le système d'exploitation modifiable FOS), indépendamment de ce que représentent ces multiplets lors de l'utilisation de l'entité électronique sécurisée E (les multiplets pouvant par exemple représenter comme déjà indiqué des instructions exécutables par le microprocesseur M, des données de personnalisation, des données confidentielles telles que des clés secrètes, voire des données non utilisées). La figure 3 représente un procédé d'échange de données entre l'auditeur tiers TP et l'entité électronique sécurisée E afin de vérifier que le système d'exploitation modifiable FOS est bien conforme à celui qui a été évalué (par exemple en vue de sa certification) dans la phase d'évaluation. On comprend qu'après cette phase d'évaluation, l'auditeur tiers TP n'a généralement plus accès au système d'exploitation modifiable FOS. Cet échange de données entre l'auditeur tiers TP et l'entité électronique sécurisée E est par exemple réalisé via le réseau Internet INT, l'architecture de réseau N, le module de communication COM et le processeur P de l'appareil électronique A, comme expliqué ci-dessus en référence à la figure 1. Le procédé débute à l'étape E2 par l'émission par l'auditeur tiers TP de l'un des nombres aléatoires ri à destination de l'entité électronique sécurisée. Une telle étape est par exemple mise en oeuvre périodiquement. Selon une première possibilité de réalisation, le nombre aléatoire r; émis lors de l'étape E2 est choisi aléatoirement parmi la pluralité de nombres aléatoires r1, rn mémorisés dans l'auditeur tiers TP (ce qui peut être réalisé en pratique en déterminant par tirage aléatoire, parmi les entiers compris entre 1 et n, l'indice i utilisé). Selon une seconde possibilité de réalisation, les nombres aléatoires r1, rn sont utilisés séquentiellement, l'un après l'autre.
L'entité électronique sécurisée E reçoit le nombre aléatoire ri à l'étape E4. L'entité électronique sécurisée E (en pratique son microprocesseur M, qui utilise pour ce faire la mémoire vive V) détermine alors à l'étape E6 la valeur de vérification associée au nombre aléatoire ri reçu, selon le même processus que celui utilisé par l'auditeur tiers TP lors de la phase d'évaluation, ici par application de la fonction F au nombre aléatoire reçu ri et aux données formant le système d'exploitation modifiable FOS. On note M* la valeur de vérification ainsi calculée par l'entité électronique sécurisée : M* = F(ri, FOS).
La valeur de vérification calculée M* est envoyée à l'auditeur tiers TP à l'étape E8 en tant qu'élément de preuve visant à attester que le système d'exploitation modifiable FOS n'a pas été modifié. L'auditeur tiers TP reçoit la valeur de vérification M* à l'étape E10 et la compare à l'étape E12 à celle calculée lors de la phase d'évaluation. Du fait des propriétés de la fonction F indiquées ci-dessus, si la valeur de vérification M* calculée par l'entité électronique sécurisée E est égale à la valeur de vérification Mi mémorisée par l'auditeur tiers TP, l'image mémoire correspondant au système d'exploitation modifiable FOS est bien celle attendue et le fonctionnement de l'entité électronique sécurisée peut continuer normalement (étape E16). Au contraire, si la valeur de vérification M* calculée par l'entité électronique sécurisée E diffère de la valeur de vérification Mi mémorisée par l'auditeur tiers TP, ceci signifie que le système d'exploitation modifiable FOS n'est pas conforme à celui qui a été évalué. On procède dans ce cas à l'étape E14 à laquelle on traite le problème rencontré, par exemple en émettant un message à destination de l'émetteur ISS de l'entité électronique sécurisée E, lequel peut par exemple révoquer les droits associés à l'entité électronique sécurisée E. On remarque que, la valeur r; n'étant pas prévisible, l'entité électronique sécurisée E ne peut pas calculer et mémoriser au préalable la valeur de vérification Mi associée (ce qui permettrait à l'entité électronique sécurisée E de renvoyer la valeur attendue même si le système d'exploitation FOS était ensuite modifié). Autrement dit, les données du système d'exploitation FOS mémorisées dans la mémoire non-volatile NV lors de la réception de la valeur imprévisible (ici aléatoire) ri doivent être conformes à celles présentes lors de la phase d'évaluation pour que l'entité électronique sécurisée E puisse calculer une valeur de vérification M* égale à la valeur attendue Mi. On remarque en outre que l'ensemble des données mémorisées dans la zone modifiable de la mémoire non-volatile NV (zone où est mémorisé le système d'exploitation modifiable FOS) est utilisé dans le calcul de chaque valeur de vérification Mi afin que l'entité électronique sécurisée E ne puisse pas mémoriser une copie du système d'exploitation modifiable qui lui permettrait de calculer une valeur de vérification Mi correcte même après modification (non autorisée) du système d'exploitation modifiable FOS.
Enfin, comme indiqué ci-dessus, l'entité électronique sécurisée E ne peut pas mémoriser l'ensemble des valeurs aléatoires r; et de vérification Mi, et ne peut donc pas répondre à l'auditeur tiers TP en utilisant une valeur de vérification déterminée à un moment antérieur puis mémorisée (ce qui lui permettrait d'apporter des modifications au système d'exploitation modifiable FOS après avoir traité l'ensemble des valeur aléatoires r1, rn et mémorisé les valeurs de vérification M1, , Mn associées). On décrit à présent un second mode de réalisation de l'invention en référence à la figure 4. Ce mode de réalisation concerne également le cas où un système d'exploitation modifiable FOS mémorisé dans la mémoire non-volatile NV d'une entité électronique sécurisée E est vérifié par un auditeur tiers TP, comme schématiquement représenté en figure 2. Dans ce second mode de réalisation, l'auditeur tiers TP n'a toutefois à aucun moment connaissance (en clair) des données formant le système d'exploitation modifiable FOS, mais ne dispose que d'une version chiffrée C de ces données, comme expliqué à présent. On remarque que l'on peut toutefois prévoir, lorsque l'auditeur tiers TP a également un rôle de certificateur, que la version chiffrée C des données soit générée pendant un phase initiale d'audit, sous la surveillance du certificateur.
La figure 4 représente les étapes principales d'un second exemple de procédé mis en oeuvre dans le cadre de l'invention. Ce procédé débute ainsi à l'étape E20 par une étape de chiffrement des données formant le système d'exploitation modifiable FOS par l'émetteur ISS de l'entité électronique sécurisée ISS. Cette étape de chiffrement est par exemple réalisée en appliquant aux données formant le système d'exploitation modifiable FOS un algorithme de chiffrement (ici symétrique) ENC utilisant une clé secrète K1 mémorisée par l'émetteur ISS et par l'entité électronique sécurisée E (et connue seulement de ces deux entités). Dans le cadre de son chiffrement, le système d'exploitation modifiable FOS est par exemple découpé en blocs ordonnés FOS i de taille prédéterminée (ici de 16 octets). Selon une première possibilité de réalisation, l'algorithme de chiffrement ENC est de type CBC (pour "Cipher Block Chaining") et est appliqué comme représenté en figure 5: le premier bloc FOSi est combiné à un vecteur d'initialisation IV (prédéterminé ou déterminé lors du calcul, par exemple par tirage aléatoire) par application d'un opérateur "ou exclusif' (ou XOR), c'est-à-dire par somme booléenne, puis on applique un algorithme de chiffrement AES avec la clé secrète K1 au résultat de la combinaison afin d'obtenir le premier bloc chiffré C1 ; pour les autres blocs de données du système d'exploitation modifiable FOS, on combine le bloc concerné FOS i et le bloc chiffré précédent CH au moyen d'une opération de "ou exclusif' (somme booléenne), puis on applique l'algorithme de chiffrement AES avec la clé secrète K1 au résultat de la combinaison afin d'obtenir la version chiffrée Ci du bloc courant.
Selon une seconde possibilité de réalisation, l'algorithme de chiffrement ENC est de type ECB (pour "Encoded CodeBook") et est appliqué comme représenté en figure 6: un algorithme de chiffrement AES utilisant la clé de chiffrement K1 est appliqué séparément à chaque bloc FOSi afin d'obtenir la version chiffrée Ci du bloc concerné.
Selon une troisième possibilité de réalisation, l'algorithme de chiffrement est de type CTR (de l'anglais "counter": compteur) : un compteur incrémenté de bloc en bloc est chiffré au moyen d'un algorithme de chiffrement, tel que l'algorithme de chiffrement AES, utilisant une clé secrète (par exemple la clé K1) ; la version chiffrée Cj du bloc concerné est obtenue par somme booléenne du bloc FOSi correspondant et du compteur chiffré. Quelle que soit la possibilité de réalisation utilisée, la concaténation des blocs chiffrés Ci obtenus forme la version chiffrée C du système d'exploitation modifiable FOS. La version chiffrée C du système d'exploitation modifiable FOS obtenue à l'étape E20 est envoyée à l'étape E22 à l'auditeur tiers TP. L'auditeur tiers TP reçoit ainsi lors d'une étape E24 la version chiffrée C du système d'exploitation modifiable FOS, par exemple comme déjà indiqué sous forme de blocs chiffrés C. L'auditeur tiers TP détermine alors à l'étape E26 une pluralité de nombres r1, rn par tirage aléatoire. Pour chaque nombre aléatoire ri ainsi déterminé, l'auditeur tiers TP détermine à l'étape E28 une valeur de vérification Mi associée, par exemple par application d'une fonction F au nombre aléatoire concerné ri et à la version chiffrée C du système d'exploitation modifiable FOS.
La fonction F a des propriétés identiques à celle utilisée dans le premier mode de réalisation. Par ailleurs, comme indiqué pour le premier mode de réalisation, on peut utiliser un nombre n de valeurs aléatoires ri et de valeurs de vérification Mi tel que l'entité électronique sécurisée E ne peut pas mémoriser l'ensemble de ces valeurs ri, Mi. On utilise par exemple en tant que fonction F un algorithme de type CBC-MAC (pour "Cipher Block Chaining - Message Authentication Code") en prenant en tant que vecteur d'initialisation la valeur aléatoire ri et en tant que fonction cryptographique l'algorithme de chiffrement AES utilisant une clé secrète K2, comme représenté en figure 7. Les valeurs aléatoires ri et les valeurs de vérification associées Mi sont mémorisées par l'auditeur tiers (étape E30), comme représenté à la figure 2. On remarque qu'on pourrait ici en variante s'abstenir de déterminer au préalable les valeurs aléatoires ri et de vérification Mi et de les mémoriser (voir plus bas les étapes E34 et E40). En effet, le système d'exploitation modifiable FOS étant mémorisé par l'auditeur tiers TP sous forme chiffrée, il peut conserver ces données en mémoire tout au long de l'utilisation de l'entité électronique sécurisée E. Lorsque l'entité électronique sécurisée E est utilisée (ce dont l'auditeur 20 tiers TP peut être informé par réception - non représentée sur la figure 4 - d'un message provenant de l'émetteur ISS), l'auditeur tiers TP vérifie périodiquement l'intégrité du système d'exploitation modifiable FOS comme décrit à présent. Dans l'exemple décrit ici, on initialise tout d'abord à 0 un indice i (étape E32). 25 Dans la variante susmentionnée où les valeurs aléatoires ri n'ont pas été déterminées au préalable, on détermine alors une valeur ri par tirage aléatoire à l'étape E34 (cette étape n'étant naturellement pas réalisée lorsque l'on a procédé au préalable à l'étape E26). Quel que soit le moment où la valeur aléatoire ri est déterminée (au 30 préalable à l'étape E26 ou sur le champ à l'étape E34), la valeur aléatoire ri est émise par l'auditeur tiers TP à l'étape E36 à destination de l'entité électronique sécurisée E. L'entité électronique sécurisée E reçoit la valeur aléatoire ri à l'étape E38.
L'entité électronique sécurisée E détermine alors à l'étape E42 une valeur de vérification M* sur la base de la valeur aléatoire r; et des données formant le système d'exploitation modifiable FOS, en chiffrant les données formant le système d'exploitation modifiable FOS au moyen de l'algorithme de chiffrement ENC et de la clé secrète K1 utilisés à l'étape E20, et en utilisant la fonction F utilisée à l'étape E28: M* = F(r1,ENC(Ki,F0S)). On rappelle que l'entité électronique sécurisée E mémorise pour ce faire la clé secrète (ou clé cryptographique) K1 et, dans le cas où la fonction F est de type CBC-MAC comme indiqué plus haut, la clé secrète (ou clé cryptographique) K2. Par ailleurs, lorsque le vecteur d'initialisation IV utilisé par l'émetteur ISS pour chiffrer les données formant le système d'exploitation FOS (voir ci-dessus l'étape E20) est obtenu par tirage aléatoire, ce vecteur d'initialisation IV est également mémorisé dans l'entité électronique sécurisée E. Dans la variante susmentionnée où les valeurs de vérification M; n'ont pas été déterminées au préalable, l'auditeur tiers TP détermine pendant ce temps à l'étape E40 (ou éventuellement avant envoi de la valeur aléatoire r; à l'étape E36) la valeur de vérification M; associée à la valeur aléatoire r; obtenue à l'étape E34, par application de la fonction F à cette valeur aléatoire r; et à la version chiffrée C du système d'exploitation modifiable FOS : M; = F(n,C). Cette étape n'est naturellement pas réalisée lorsque l'on a procédé au préalable à l'étape E28. Comme indiqué ci-dessus, dans les exemples qui précèdent, la fonction F est appliquée à l'ensemble des données modifiables de la mémoire non-volatile NV (c'est-à-dire dans certains cas à l'ensemble des données de la mémoire non-volatile NV).
Il est toutefois également envisageable lors des étapes E40 et E42 d'appliquer la fonction F à une partie seulement de la mémoire non-volatile NV ou du système d'exploitation modifiable FOS, par exemple à une partie seulement des blocs FOS; formant le système d'exploitation modifiable FOS. Ainsi par exemple lorsque le système d'exploitation modifiable FOS est chiffré à l'étape E20 au moyen d'un algorithme de type ECB (ou CTR), l'auditeur tiers TP peut envoyer à l'entité électronique sécurisée E lors de l'étape E36 une désignation des blocs FOS; auxquels la fonction F doit être appliquée, par exemple sous forme d'une liste {k(1), k(I)} des indices i de ces blocs (déterminée par exemple par tirage aléatoire) et les mots de vérification Mi, M* peuvent alors être déterminés en concaténant les blocs concernés : - du côté de l'auditeur tiers TP (étape E40), Mi = F(ri,Ck(l)11.- liCk(i)) ; - du côté de l'entité électronique sécurisée E (étape E42), M* = F(ri,ENC(Ki,F0Sk(l))11.- - IIENC(Ki,F0Sk(I))).
Dans tous les cas, l'entité électronique sécurisée E envoie à l'étape E44 la valeur de vérification M* déterminée à l'étape E42, en tant qu'élément de preuve de l'intégrité du système d'exploitation modifiable FOS (ou d'une partie de celui-ci) à destination de l'auditeur tiers TP. L'auditeur tiers TP peut ainsi comparer à l'étape E48 la valeur de vérification Mi déterminée par ses soins (étape E28 ou E40) à la valeur de vérification M* reçue de l'entité électronique sécurisée E. Si le résultat de la comparaison est positif, le système d'exploitation modifiable FOS mémorisé dans l'entité électronique sécurisée E correspond à celui attendu et l'auditeur tiers TP peut attendre une durée prédéterminée (temporisation de l'étape E50) avant d'incrémenter l'indice i (étape E52) et de boucler à l'étape E36 (ou E34 selon la variante mentionnée plus haut) afin de vérifier à nouveau l'intégrité du système d'exploitation modifiable FOS. Si le résultat de la comparaison est négatif, le système d'exploitation modifiable FOS (ou, de manière générale, la zone mémoire couverte par la vérification) a été modifié et l'auditeur tiers TP émet par exemple un message d'alerte à destination de l'émetteur ISS (étape E54). À réception de ce message d'alerte, l'émetteur ISS prend par exemple des mesures pour désactiver l'entité électronique sécurisée, telles que la révocation des certificats mémorisés dans l'entité électronique sécurisée (étape E56).
La figure 8 représente les étapes principales d'un troisième exemple de procédé mis en oeuvre dans le cadre de l'invention. Au cours d'une étape E100, l'émetteur ISS transmet une image mémoire IM à destination de l'entité électronique sécurisée E. Cette image mémoire IM contient l'ensemble des données et instructions à mémoriser dans la mémoire non-volatile NV de l'entité électronique sécurisée E pour permettre son fonctionnement. L'entité électronique sécurisée E reçoit l'image mémoire IM à l'étape E102 et la mémorise dans sa mémoire non-volatile NV. L'entité électronique sécurisée est alors prête à être utilisée pour la fonctionnalité pour laquelle elle est conçue, par exemple en tant que moyen de paiement, moyen d'accès à un réseau de téléphonie mobile, moyen d'identification, etc. Les étapes E100 et E102 peuvent être réalisées dans le contexte de la figure 1, auquel cas un mécanisme de sécurisation des échanges est au préalable mis en oeuvre entre l'émetteur ISS et l'entité électronique sécurisée E afin d'effectuer à distance la personnalisation de l'entité électronique sécurisée E. En variante, les étapes E100 et E102 peuvent être réalisées au sein d'un établissement dédié à la personnalisation d'entités électroniques sécurisées, auquel cas l'entité électronique sécurisée E communique (par une liaison filaire ou sans fil courte portée ou autre) avec une machine de personnalisation de l'émetteur ISS (la machine de personnalisation mettant alors en oeuvre l'étape E100). Au cours d'une étape E104, l'image mémoire IM est sécurisée par l'émetteur ISS, par exemple par chiffrement au moyen d'un algorithme cryptographique utilisant une clé cryptographique SECsT, ce qui permet d'obtenir une version sécurisée (ici chiffrée) IMsEc de l'image mémoire IM. L'émetteur ISS peut éventuellement générer en outre une signature ou un code d'authentification (ou MAC pour "Message Authentication Code") de l'image mémoire IM. L'image mémoire sécurisée IMsEc et la clé cryptographique SECsT (ainsi éventuellement que la signature ou le code d'authentification) sont émises par l'émetteur ISS à l'étape E106, à destination de l'auditeur tiers TP. La clé cryptographique SECsT étant un secret partagé entre l'émetteur ISS et l'auditeur tiers TP (ou, en variante, entre l'émetteur ISS et un module de sécurité matériel détenu par l'auditeur tiers TP), elle est transmise en utilisant un mécanisme empêchant sa divulgation, par exemple au moyen d'un canal sécurisé établi entre l'émetteur ISS et l'auditeur tiers TP. L'auditeur tiers TP reçoit et mémorise à l'étape E108 l'image mémoire sécurisée IMsEc et la clé cryptographique SECsT (ainsi éventuellement que la signature ou le code d'authentification). En pratique, la clé cryptographique SECsT est par exemple mémorisée dans un module de sécurité matériel (ou HSM pour "Hardware Security Module") de l'émetteur ISS, par exemple une carte à microcircuit ou un élément sécurisé intégré. Ensuite, au cours d'une étape E110, l'auditeur tiers génère un secret SECINT (par exemple par tirage aléatoire) et mémorise ce secret SECINT, par exemple au sein du module de sécurité matériel précité. Le secret SECINT généré à l'étape E110 est transmis à l'entité électronique sécurisée E, par exemple au moyen d'un canal de communication sécurisé établi entre l'auditeur tiers TP et l'entité électronique sécurisée E, puis mémorisé dans l'entité électronique sécurisée E (étape E112), par exemple dans une zone de la mémoire non-volatile NV non couverte par la vérification d'intégrité. Dans l'exemple qui vient d'être donné, le secret SECINT est généré par l'auditeur tiers TP. En variante, le secret SECINT pourrait être généré par l'émetteur ISS, transmis à l'auditeur tiers ISS (par exemple lors de l'étape E106 décrite ci- dessus) et mémorisé dans l'entité électronique sécurisée E lors de la phase de personnalisation (par exemple à l'étape E102 décrite ci-dessus). De manière périodique au cours de l'utilisation de l'entité électronique sécurisée E, l'auditeur tiers TP peut alors vérifier l'intégrité de parties de l'image mémoire IM mémorisée en mémoire non-volatile NV, comme décrit à présent.
L'auditeur tiers TP génère à l'étape E114 une liste (ordonnée) non- prévisible L de régions de la zone mémoire dont on souhaite vérifier l'intégrité, ici la mémoire non-volatile NV (qui contient en fonctionnement normal l'image mémoire IM reçue et mémorisée à l'étape E102). Chaque région de la liste L est ici définie par une adresse, qui désigne le début de la région concernée (autrement dit, qui vise par exemple le premier octet de la région concernée), et par une longueur (exprimée par exemple en nombre de mots de bits, ici en nombre d'octets). Pour chaque région de la liste L, l'adresse et la longueur définissant cette région sont par exemple déterminées par tirage aléatoire. On peut toutefois prévoir dans ce cas que certaines parties particulières de la mémoire concernée (ici la mémoire non-volatile NV), par exemple des parties contenant des instructions ou des données critiques ou sensibles, soient plus fréquemment visées par les régions de la liste. Pour ce faire, on prévoit par exemple que certaines adresses soient déterminées par tirage aléatoire parmi les adresses situées dans ces parties particulières de la mémoire concernée, tandis que d'autres adresses sont déterminées par tirage aléatoire parmi toutes les adresses envisageables pour la mémoire concernée. En variante, la liste des régions pourrait être prédéterminée (tout en restant de préférence imprévisible). L'auditeur tiers TP peut en effet en pratique utiliser un grand nombre de listes prédéterminées de telle sorte que l'entité électronique sécurisée E ne pourra pas mémoriser la réponse attendue (valeur d'intégrité VALINT mentionnée plus bas) à chacune de ces listes. Selon une autre possibilité de réalisation, l'auditeur tiers TP peut choisir la liste L par tirage aléatoire parmi un grand nombre de listes prédéterminées. Dans le cas décrit ici où la liste n'est pas prédéterminée, le nombre de régions listées dans la liste L peut être fixe ou variable, par exemple déterminé par tirage aléatoire entre une valeur minimale et une valeur maximale. On remarque par ailleurs que les différentes régions de la liste L peuvent 10 éventuellement se chevaucher (i.e. se recouper) sans que cela ne pose de difficultés dans la suite du processus. L'auditeur tiers TP émet alors à l'étape E116 la liste L (générée à l'étape E114) à destination de l'entité électronique sécurisée E. La liste non-prévisible L est reçue par l'entité électronique sécurisée E à 15 l'étape E118. L'entité électronique sécurisée E construit alors à l'étape E120 une structure d'octets par lecture des octets mémorisés dans les régions de mémoire (ici de la mémoire non-volatile NV) désignées dans la liste L reçue, par exemple par concaténation des octets lus dans les régions de la liste L. 20 L'entité électronique sécurisée E peut ainsi déterminer à l'étape E122 une valeur d'intégrité VALINT (ou valeur de vérification) par application d'une fonction f à la structure d'octets produite à l'étape E120, en utilisant ici en outre le secret SEC INT. La fonction f est par exemple une fonction cryptographique de signature 25 ou de génération de code d'authentification de message utilisant en tant que clé cryptographique le secret SECINT et en tant que message (à signer ou à authentifier) la structure d'octets précitée. La fonction f peut être de l'un des types proposés ci-dessus (dans le cadre des deux premiers exemples de réalisation) pour la fonction F. 30 Comme pour la fonction F, la fonction f est appliquée en considérant la forme brute des multiplets (ici des octets) de la structure, indépendamment de ce que représentent ces multiplets lors de l'utilisation de l'entité électronique sécurisée E On remarque que la fonction f peut éventuellement utiliser d'autres paramètres (par exemple une valeur aléatoire) qui sont dans ce cas transmis de l'auditeur tiers TP à l'entité électronique sécurisée E avec la liste L à l'étape E116, ou en variante de l'entité électronique sécurisée E à l'auditeur tiers TP avec la valeur d'intégrité VALINT à l'étape E124 (décrite ci-dessous). Ces autres paramètres comprennent par exemple un vecteur d'initialisation utilisé par la fonction f (notamment lorsque la fonction f est de type CBC-MAC). La valeur d'intégrité VALINT calculée par l'entité électronique sécurisée E à l'étape E122 est transmise à l'auditeur tiers TP lors de l'étape E124. L'auditeur tiers TP reçoit et mémorise cette valeur d'intégrité VALINT à l'étape E126. L'auditeur tiers TP procède alors à la lecture dans l'image mémoire sécurisée IMsEc des parties correspondant aux régions de la liste L et au déchiffrement de ces parties lues au moyen de la clé cryptographique SECsT (étape E128). En variante, le déchiffrement est réalisé par le module de sécurité matériel (à l'intérieur de celui-ci) de sorte que l'auditeur tiers TP n'a pas connaissance des versions déchiffrées. L'auditeur tiers TP (ou, le cas échéant, le module de sécurité matériel) peut éventuellement à cette occasion procéder à la vérification de la signature ou du code d'authentification associé, lorsqu'un tel élément a été transmis lors de l'étape E106 comme mentionné ci-dessus. L'auditeur tiers TP (ou, en variante, le module de sécurité matériel détenu par l'auditeur tiers TP) peut ainsi produire à l'étape E130 une structure d'octets à partir des octets contenus dans les parties déchiffrées, selon le processus utilisé par l'entité électronique sécurisée E à l'étape E120, ici par concaténation de ces octets. La structure de données obtenue à l'étape E130 est normalement (c'est-à-dire en cas de fonctionnement normal, sans modification de l'image mémoire IM) identique à celle obtenue à l'étape E120. L'auditeur tiers TP (ou, en variante, le module de sécurité matériel détenu par l'auditeur tiers TP) détermine à l'étape E132 une valeur d'intégrité VALINT* à partir de la structure d'octets obtenue à l'étape E130, selon le même processus que celui utilisé à l'étape E122, c'est-à-dire par application de la fonction f à cette structure d'octets produite à l'étape E130, en utilisant ici en outre le secret SECINT. L'auditeur tiers TP (ou, en variante, le module de sécurité matériel détenu par l'auditeur tiers TP) peut ainsi vérifier à l'étape E134 si la valeur d'intégrité VALINT calculée par l'entité électronique sécurisée E est bien égale à la valeur d'intégrité VALINT* calculée à l'étape E132. Lorsque les étapes qui viennent d'être décrites sont réalisées par le module de sécurité matériel détenu par l'auditeur tiers TP (afin que l'auditeur tiers TP lui-même ne puisse avoir connaissance du contenu de la mémoire vérifiée), un message indicatif du résultat de la comparaison est transmis du module de sécurité matériel à l'auditeur tiers TP. Si la vérification est positive, l'image mémoire IM mémorisée dans la mémoire non-volatile NV de l'entité électronique sécurisée E n'a pas été altérée et l'entité électronique sécurisée E peut donc continuer à être utilisée normalement. Le procédé se poursuit donc dans ce cas par une étape E136 de temporisation, avant la mise en oeuvre d'une nouvelle itération de la vérification de l'intégrité de l'image mémoire IM à partir de l'étape E114 comme décrit ci-dessus.
Si la vérification de l'étape E134 est négative, le procédé se poursuit au contraire à l'étape E138 au cours de laquelle une action est mise en place pour traiter le défaut d'intégrité de l'image mémoire ainsi détecté. Cette action est par exemple l'émission (non représentée en figure 8) d'un message indiquant ce défaut d'intégrité à destination de l'émetteur ISS, qui peut alors par exemple révoquer les droits associés à l'entité électronique sécurisée E ou, en variante, imposer une mise à jour à distance de l'image mémoire de la mémoire non-volatile NV. L'itération de vérification d'intégrité décrite ci-dessus ne permet de vérifier que l'intégrité des données contenues dans les régions de la liste L utilisée durant cette itération. Toutefois, au fur et à mesure des itérations, une partie plus importante de la mémoire concernée aura été vérifiée. On remarque en outre que l'entité électronique sécurisée E ne peut pas prévoir les régions utilisées lors d'une itération donnée et ne peut donc pas anticiper sur la valeur d'intégrité transmise en réponse à l'auditeur tiers TP.
La seule possibilité pour que l'entité électronique sécurisée E calcule la réponse attendue est donc qu'elle maintienne l'intégrité de la mémoire concernée. La figure 9 représente les étapes principales d'un quatrième exemple de procédé mis en oeuvre dans le cadre de l'invention. Dans cet exemple, l'auditeur tiers TP mémorise une image mémoire dérivée IMDER obtenue à partir de l'image mémoire IM (mémorisée quant à elle dans la mémoire non-volatile NV de l'entité électronique sécurisée E), par exemple au moyen d'un algorithme cryptographique de chiffrement (tel qu'un algorithme de type ECB comme mentionné plus haut). Cette situation est par exemple obtenue par un procédé du même type que celui des étapes E20 à E24 décrit ci-dessus en référence à la figure 4. L'entité électronique sécurisée E mémorise quant à elle la clé cryptographique de chiffrement utilisée pour obtenir l'image mémoire dérivée IMDER.
On décrit ci-dessous une itération d'un procédé de vérification de l'intégrité de l'image mémoire IM. Une telle itération est répétée périodiquement afin de couvrir au fur et à mesure une part de plus en plus importante de la mémoire concernée, comme décrit ci-dessus en référence à la figure 8 pour le troisième exemple de réalisation.
L'auditeur tiers TP génère à l'étape E200 une liste (ordonnée) non- prévisible L de régions de la zone mémoire dont on souhaite vérifier l'intégrité, ici la mémoire non-volatile NV. Comme dans le troisième exemple décrit ci-dessus en référence à la figure 8, chaque région de la liste L est ici définie par une adresse et par une longueur. La liste L des régions est générée selon l'une des possibilités envisagées ci-dessus dans le cadre du troisième exemple de réalisation. L'auditeur tiers TP émet la liste L à destination de l'entité électronique sécurisée E (étape E202) et la liste non-prévisible L est donc reçue par l'entité électronique sécurisée E à l'étape E204.
L'entité électronique sécurisée E lit alors les données mémorisées (sous forme de multiplets, ici d'octets) dans les régions désignées dans la liste L et génère à l'étape E206 des données dérivées correspondantes, en appliquant l'algorithme utilisé pour obtenir l'image dérivée IMDER mémorisée par l'auditeur tiers TP comme indiqué ci-dessus (ici un algorithme de chiffrement, par exemple de type EBC, utilisant la clé cryptographique de chiffrement mémorisée par l'entité électronique sécurisée E). L'entité électronique construit ensuite à l'étape E208 une structure de données à traiter (ou structure d'octets) en utilisant les données dérivées obtenues à l'étape E206, par exemple par concaténation de ces données dérivées. L'entité électronique sécurisée E peut ainsi déterminer à l'étape E210 une valeur d'intégrité VALINT (ou valeur de vérification) par application d'une fonction f à la structure de données produite à l'étape E208, en utilisant par exemple en outre un secret SECINT partagé entre l'entité électronique sécurisée E et l'auditeurs tiers TP, comme dans le troisième exemple décrit en référence à la figure 8. La fonction f peut être de l'un des types proposés ci-dessus (dans le cadre des trois premiers exemples de réalisation). La valeur d'intégrité VALINT calculée par l'entité électronique sécurisée E à l'étape E210 est transmise à l'auditeur tiers TP lors de l'étape E212 et reçue par celui-ci à l'étape E214, qui la mémorise. L'auditeur tiers TP procède alors à la lecture dans l'image mémoire dérivée IMDER des parties correspondant aux régions de la liste L et produit à l'étape E216 une structure de données à partir des données lues, selon le processus utilisé par l'entité électronique sécurisée E à l'étape E208, ici par concaténation des données lues. La structure de données obtenue à l'étape E216 est normalement (c'est-à-dire en cas de fonctionnement normal, sans modification de l'image mémoire IM) identique à celle obtenue à l'étape E208. L'auditeur tiers TP détermine à l'étape E218 une valeur d'intégrité VALINT* à partir de la structure de données obtenue à l'étape E216, selon le même processus que celui utilisé à l'étape E210, c'est-à-dire par application de la fonction f à cette structure de données produite à l'étape E216, en utilisant ici en outre le secret partagé SECINT. L'auditeur tiers TP peut ainsi vérifier à l'étape E220 si la valeur d'intégrité VALINT calculée par l'entité électronique sécurisée E est bien égale à la valeur d'intégrité VALINT* calculée à l'étape E218. Si la vérification est positive, l'image mémoire IM mémorisée dans la mémoire non-volatile NV de l'entité électronique sécurisée E n'a pas été altérée et l'entité électronique sécurisée E peut donc continuer à être utilisée normalement (étape E222). Si la vérification de l'étape E220 est négative, le procédé se poursuit au contraire à l'étape E224 au cours de laquelle une action est mise en place pour traiter le défaut d'intégrité de l'image mémoire IM ainsi détecté. Cette action est du même type que celle de l'étape E138 décrite plus haut en référence à la figure 8.

Claims (22)

  1. REVENDICATIONS1. Entité électronique sécurisée (E) comprenant : - une mémoire (NV) mémorisant des données sous forme de multiplets ; - un module de traitement (M) conçu pour recevoir des données (r1; L) en provenance d'un dispositif électronique (TP) ; caractérisée en ce que le module de traitement (M) est conçu pour déterminer un élément de preuve d'intégrité (M* ; VALINT) en fonction des données reçues (r1; L) et d'une partie au moins des multiplets mémorisés, et pour émettre l'élément de preuve d'intégrité (M* ; VALINT) à destination du dispositif électronique (TP).
  2. 2. Entité électronique sécurisée selon la revendication 1, dans laquelle les données reçues représentent une valeur aléatoire (r1).
  3. 3. Entité électronique sécurisée selon la revendication 1, dans laquelle les données reçues (L) désignent des régions de la mémoire (NV) et dans laquelle le module de traitement (M) est conçu pour déterminer l'élément de preuve d'intégrité (VALINT) en fonction des multiplets mémorisés dans les régions désignées par les données reçues (L).
  4. 4. Entité électronique sécurisée selon l'une des revendications 1 à 3, dans laquelle le module de traitement (M) est conçu pour déterminer l'élément de preuve d'intégrité (M* ; VALINT) en partie au moyen d'un chiffrement des multiplets mémorisés.
  5. 5. Entité électronique sécurisée selon la revendication 4, comprenant un module de mise en oeuvre du chiffrement en fonction d'une clé secrète (K1) mémorisée dans l'entité électronique sécurisée (E).
  6. 6. Entité électronique sécurisée selon l'une des revendications 1 à 5, dans laquelle le module de traitement (M) est conçu pour déterminer l'élément de preuve d'intégrité (M* ; VALINT) au moyen d'une fonction de signature ou d'une fonction de hachage ou d'une fonction de génération de code d'authentification de message.
  7. 7. Entité électronique sécurisée selon l'une des revendications 1 à 6, ladite entité électronique sécurisée étant une carte d'accès à un réseau de téléphonie mobile.
  8. 8. Téléphone cellulaire comprenant une entité électronique sécurisée selon l'une des revendications 1 à 7.
  9. 9. Téléphone cellulaire selon la revendication 8, dans lequel l'entité électronique sécurisée est soudée au téléphone cellulaire.
  10. 10. Compteur de fourniture d'énergie comprenant une entité électronique sécurisée selon l'une des revendications 1 à 7.
  11. 11. Compteur de fourniture d'énergie selon la revendication 10, dans lequel l'entité électronique sécurisée est soudée audit compteur.
  12. 12. Système électronique embarqué pour véhicule comprenant une entité électronique sécurisée selon l'une des revendications 1 à 7.
  13. 13. Système électronique embarqué selon la revendication 12, dans lequel l'entité électronique sécurisée est soudée au système électronique.
  14. 14. Appareil électronique comprenant un module de communication en champ proche et une entité électronique sécurisée selon l'une des revendications 1 à 7 reliée au module de communication en champ proche.
  15. 15. Procédé de vérification de l'intégrité de données mémorisées dans une entité électronique sécurisée (E), caractérisé en ce qu'il comprend les étapes suivantes : - émission, par un dispositif électronique (TP), de données (r1 ; L) à destination de l'entité électronique sécurisée (E) ; - réception des données (r1 ; L) par l'entité électronique sécurisée (E) ; - détermination d'un élément de preuve d'intégrité (M* ; VALINT) en fonction des données reçues (ri ; L) et d'une partie au moins des multiplets mémorisés dans une mémoire (NV) de l'entité électronique sécurisée (E) ; - émission, par l'entité électronique sécurisée (E), de l'élément de preuve d'intégrité (M* ; VALINT) à destination du dispositif électronique (TP).
  16. 16. Procédé de vérification selon la revendication 15, comprenant une étape de détermination (E26; E34; E114; E200) d'une partie au moins des données (r1 ; L) émises par tirage aléatoire.
  17. 17. Procédé de vérification selon la revendication 15 ou 16, dans lequel les données reçues représentent une valeur aléatoire (ri) utilisée en tant que paramètre lors de l'application d'une fonction (E6 ; E42).
  18. 18. Procédé de vérification selon la revendication 15 ou 16, dans lequel les données reçues (L) désignent des régions de la mémoire (NV) et dans lequel la détermination de l'élément de preuve d'intégrité (VALINT) est réalisée en fonction des multiplets mémorisés dans les régions désignées par les données reçues (L).
  19. 19. Procédé de vérification selon l'une des revendications 15 à 18, dans lequel la détermination de l'élément de preuve d'intégrité comprend un chiffrement (E42; E206) des multiplets mémorisés.
  20. 20. Procédé de vérification selon la revendication 19, dans lequel le chiffrement des multiplets mémorisés utilise une clé secrète (K1) mémorisée dans l'entité électronique sécurisée (E).
  21. 21. Procédé de vérification selon l'une des revendications 15 à 20, dans lequel l'élément de preuve d'intégrité (M* ; VALINT) est déterminé par application d'une fonction de signature ou d'une fonction de hachage ou d'une fonction de génération de code d'authentification de message.
  22. 22. Procédé de vérification selon l'une des revendications 15 à 21, dans lequel ledit dispositif électronique est un auditeur tiers (TPA).
FR1463256A 2014-12-23 2014-12-23 Entite electronique securisee, appareil electronique et procede de verification de l’integrite de donnees memorisees dans une telle entite electronique securisee Active FR3030831B1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
FR1463256A FR3030831B1 (fr) 2014-12-23 2014-12-23 Entite electronique securisee, appareil electronique et procede de verification de l’integrite de donnees memorisees dans une telle entite electronique securisee
KR1020177020623A KR20170097771A (ko) 2014-12-23 2015-12-17 보안 전자 엔티티, 전자 장치 및 이러한 보안 전자 엔티티에 저장된 데이터의 무결성을 검증하기 위한 방법
PCT/FR2015/053595 WO2016102833A1 (fr) 2014-12-23 2015-12-17 Entité électronique sécurisée, appareil électronique et procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée
EP15828654.2A EP3238200A1 (fr) 2014-12-23 2015-12-17 Entité électronique sécurisée, appareil électronique et procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée
US15/538,709 US20170353315A1 (en) 2014-12-23 2015-12-17 Secure electronic entity, electronic apparatus and method for verifying the integrity of data stored in such a secure electronic entity

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1463256 2014-12-23
FR1463256A FR3030831B1 (fr) 2014-12-23 2014-12-23 Entite electronique securisee, appareil electronique et procede de verification de l’integrite de donnees memorisees dans une telle entite electronique securisee

Publications (2)

Publication Number Publication Date
FR3030831A1 true FR3030831A1 (fr) 2016-06-24
FR3030831B1 FR3030831B1 (fr) 2018-03-02

Family

ID=53059209

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1463256A Active FR3030831B1 (fr) 2014-12-23 2014-12-23 Entite electronique securisee, appareil electronique et procede de verification de l’integrite de donnees memorisees dans une telle entite electronique securisee

Country Status (5)

Country Link
US (1) US20170353315A1 (fr)
EP (1) EP3238200A1 (fr)
KR (1) KR20170097771A (fr)
FR (1) FR3030831B1 (fr)
WO (1) WO2016102833A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3060806A1 (fr) * 2016-12-20 2018-06-22 Oberthur Technologies Procede de verification de l'integrite de donnees, entite electronique associee et appareil electronique comprenant une telle entite electronique
FR3060807A1 (fr) * 2016-12-20 2018-06-22 Oberthur Technologies Procede de verification de l'integrite d'un programme, entite electronique associee et appareil electronique comprenant une telle entite electronique
CN109314639A (zh) * 2016-08-09 2019-02-05 Kddi株式会社 管理系统、密钥生成装置、车载计算机、管理方法以及计算机程序

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2564878B (en) * 2017-07-25 2020-02-26 Advanced Risc Mach Ltd Parallel processing of fetch blocks of data
US20220321330A1 (en) * 2019-08-13 2022-10-06 Nokia Technologies Oy Data security for network slice management
US11416639B2 (en) * 2020-06-29 2022-08-16 Nuvoton Technology Corporation PQA unlock
CN114080016B (zh) * 2020-08-12 2023-06-27 大唐移动通信设备有限公司 用户设备上下文信息的同步方法、装置和网络侧设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5442645A (en) * 1989-06-06 1995-08-15 Bull Cp8 Method for checking the integrity of a program or data, and apparatus for implementing this method
US20100223656A1 (en) * 2009-02-27 2010-09-02 Microsoft Corporation Trusted entity based anti-cheating mechanism

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103202045B (zh) * 2010-11-05 2016-06-01 交互数字专利控股公司 设备检验、遇险指示和补救

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5442645A (en) * 1989-06-06 1995-08-15 Bull Cp8 Method for checking the integrity of a program or data, and apparatus for implementing this method
US20100223656A1 (en) * 2009-02-27 2010-09-02 Microsoft Corporation Trusted entity based anti-cheating mechanism

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BASILE C ET AL: "FPGA-Based Remote-Code Integrity Verification of Programs in Distributed Embedded Systems", IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS: PART C:APPLICATIONS AND REVIEWS, IEEE SERVICE CENTER, PISCATAWAY, NJ, US, vol. 42, no. 2, 1 March 2012 (2012-03-01), pages 187 - 200, XP011469391, ISSN: 1094-6977, DOI: 10.1109/TSMCC.2011.2106493 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109314639A (zh) * 2016-08-09 2019-02-05 Kddi株式会社 管理系统、密钥生成装置、车载计算机、管理方法以及计算机程序
EP3499790A4 (fr) * 2016-08-09 2020-03-11 KDDI Corporation Système de gestion, dispositif de gestion de clés, calculateur embarqué, procédé de gestion, et programme d'ordinateur
US11212087B2 (en) 2016-08-09 2021-12-28 Kddi Corporation Management system, key generation device, in-vehicle computer, management method, and computer program
CN109314639B (zh) * 2016-08-09 2022-02-01 Kddi株式会社 管理系统、密钥生成装置、车载计算机、管理方法以及记录介质
FR3060806A1 (fr) * 2016-12-20 2018-06-22 Oberthur Technologies Procede de verification de l'integrite de donnees, entite electronique associee et appareil electronique comprenant une telle entite electronique
FR3060807A1 (fr) * 2016-12-20 2018-06-22 Oberthur Technologies Procede de verification de l'integrite d'un programme, entite electronique associee et appareil electronique comprenant une telle entite electronique

Also Published As

Publication number Publication date
EP3238200A1 (fr) 2017-11-01
US20170353315A1 (en) 2017-12-07
WO2016102833A1 (fr) 2016-06-30
FR3030831B1 (fr) 2018-03-02
KR20170097771A (ko) 2017-08-28

Similar Documents

Publication Publication Date Title
EP3152860B1 (fr) Procédé d&#39;authentification d&#39;une première entité électronique par une seconde entité électronique et entité électronique mettant en oeuvre un tel procédé
EP1427231B1 (fr) Procédé d&#39;établissement et de gestion d&#39;un modèle de confiance entre une carte à puce et un terminal radio
FR3030831A1 (fr) Entite electronique securisee, appareil electronique et procede de verification de l’integrite de donnees memorisees dans une telle entite electronique securisee
EP2145448B1 (fr) Activation contrôlée de fonction
EP3010175B1 (fr) Rejeu d&#39;un batch de commandes sécurisees dans un canal sécurisé
FR3053203A1 (fr) Technique de telechargement d&#39;un profil d&#39;acces a un reseau
EP1784016A1 (fr) Méthode de sécurisation de données échangées entre un dispositif de traitement multimédia et un module de sécurité
FR3066666A1 (fr) Procede de securisation d&#39;une communication sans gestion d&#39;etats
EP3014849A1 (fr) Procédé de changement de clé d&#39;authentification
EP3185468B1 (fr) Procédé de transmission de données, procédé de réception de données, dispositifs et programmes correspondants
CN111901287A (zh) 一种为轻应用提供加密信息的方法、装置和智能设备
EP1514377A1 (fr) Procede et dispositif d&#39;interface pour echanger de maniere protegee des donnees de contenu en ligne
US20230025166A1 (en) Secure method for data exchange between a terminal and a server
EP1201057A1 (fr) Methode et dispositif pour garantir l&#39;integrite et l&#39;authenticite d&#39;un ensemble de donnees
WO2021074527A1 (fr) Procede de gestion d&#39;une base de donnees de cles publiques, procede d&#39;authentification de cles publiques, et dispositifs serveur et client mettant en oeuvre ces procedes
CN112350920A (zh) 基于区块链的即时通讯系统
EP3021515B1 (fr) Amélioration de l&#39;intégrité authentique de données à l&#39;aide du dernier bloc chiffrant ces données en mode cbc
EP3503500B1 (fr) Procédé pour créer une signature électronique à distance au moyen du protocole fido
WO2023041863A1 (fr) Procedes et dispositifs d&#39;authentification et de verification de non-revocation
FR2853785A1 (fr) Entite electronique securisee avec compteur modifiable d&#39;utilisations d&#39;une donnee secrete
EP4183098A1 (fr) Dispositif, méthode et programme pour une communication sécurisée entre boîtes blanches
CN114625387A (zh) 系统更新的方法、装置及介质
FR3116133A1 (fr) Procédé de délégation d’accès à une chaîne de blocs
FR3020909A1 (fr) Entite electronique et procede de generation de cle de session
FR2900776A1 (fr) Procede de securisation de donnees

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20160624

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

CD Change of name or company name

Owner name: IDEMIA FRANCE, FR

Effective date: 20180209

CJ Change in legal form

Effective date: 20180209

PLFP Fee payment

Year of fee payment: 6

CA Change of address

Effective date: 20200826

CJ Change in legal form

Effective date: 20200826

PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8

PLFP Fee payment

Year of fee payment: 9

PLFP Fee payment

Year of fee payment: 10