EP3387784A1 - Procede de personnalisation d'un document de securite - Google Patents

Procede de personnalisation d'un document de securite

Info

Publication number
EP3387784A1
EP3387784A1 EP16825821.8A EP16825821A EP3387784A1 EP 3387784 A1 EP3387784 A1 EP 3387784A1 EP 16825821 A EP16825821 A EP 16825821A EP 3387784 A1 EP3387784 A1 EP 3387784A1
Authority
EP
European Patent Office
Prior art keywords
data
personalization
security document
diversification
encryption
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
EP16825821.8A
Other languages
German (de)
English (en)
Other versions
EP3387784B1 (fr
Inventor
Cédric BARREAU
Alban Feraud
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
Publication of EP3387784A1 publication Critical patent/EP3387784A1/fr
Application granted granted Critical
Publication of EP3387784B1 publication Critical patent/EP3387784B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic 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/3234—Cryptographic 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 additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal

Definitions

  • the invention relates to the field of security documents, such as bank or identity cards, and e-passports, and relates more particularly to the personalization of such documents.
  • Security documents are documents with physical characteristics allowing reliable authentication of the holder of the document, and the document itself. In other words, these physical characteristics make it possible, from a predetermined authentication protocol, to ensure that an individual is the legitimate owner of the security document in question, and that the document itself is an authentic document. . These physical characteristics (prints, special materials, recorded digital data %) are generally difficult to counterfeit in order to protect the electronic document against any malicious act.
  • Security documents come in various more or less complex forms. Particularly noteworthy security documents called “electronic” in the sense that they comprise an electronic module equipped with at least one memory, unlike conventional security documents that are devoid of such memory. Identity cards, bank cards (usually smart cards) or e-passports are common examples of security documents.
  • these security documents are generally personalized.
  • This personalization step consists in affixing, on and / or in the security document, personal data specific to the future owner of the document.
  • This personal data is for example printed or embossed on the surface of the document.
  • personal data may also be stored in the memory of the electronic module.
  • the manufacturer affixes personal data of the bearer on the faces of the card (surname, first name, card number etc.) and records personal data in the chip of the card .
  • Figure 1 schematically shows a personalization method conventionally used to customize a security document.
  • a first entity 2 (present on a first site ST2) and a second entity 4 (present on a second site ST4) cooperate together to perform the customization of a security document 6.
  • the entity 2 collects personal data specific to the holder of a security document 6 to customize and then converts (E2) this personal data PR personalization data defining physical customizations (printing, embossing, data recording. ..) to bring to the security document 6.
  • the entity 2 later sends (E4) these personalization data PR to the entity 4 which then continues the process on the site ST4.
  • the entity 4 receives (E6) the personalization data PR and then customizes (E8) the security document 6 from the personalization data PR.
  • Security problems also exist in the case where several different entities 4 share the burden of customizing a set of security documents.
  • a risk exists because several entities 4 (present on different sites) have access to personalization data PR sent by entity 2.
  • personalization data PR is of a confidential nature, the dispersion of these data among various capable actors to process and use these data is problematic.
  • Entity 4 in charge of customization generally enjoys a relative flexibility in the choice of blank security documents that it uses when it realizes the E8 customization.
  • Entity 4 has the ability to choose from multiple sources of security document supply 6.
  • Entity 2 or a third party does not have the means today to ensure that the entity 4 does E8 customization on a security document 6 of a specific origin. The result is an economic risk, especially for some manufacturers who want to secure their security document manufacturing activity.
  • the present invention relates to a method of treatment, implemented by a processing device, for preparing the personalization of a security document, the method comprising:
  • the diversification data is associated (or linked) to the security document but not to an individual.
  • the diversification data is present in or on the security document.
  • the invention advantageously makes it possible to secure the process of customizing a security document.
  • an intrinsic link is created between the personalization data and the security document.
  • the diversification data for encrypting and decrypting the personalization data
  • the security document in any appropriate form (digital data stored in a memory, physical pattern present on the document etc.). ).
  • the manufacturer supervising the customization can obtain the DV diversification data only from the security document itself.
  • the diversification data and therefore the corresponding personalization data
  • an entity in charge of customizing a first security document can use the diversification data present on said first document only to personalize it, and possibly the security documents belonging to the same batch as said first security document (depending on whether this diversification data is uniquely or collectively attributed to one or more security documents).
  • the personalization data is encrypted from an encryption master key in combination with the diversification data.
  • the master encryption key is matched to a decryption master key distinct from the master key of encryption.
  • the processing device uses a secure container to perform said encryption, the master encryption key being stored in the secure container,
  • the present invention also relates to a personalization method of a security document, implemented by a personalization device, said method comprising:
  • At least part (or all) of the diversification data retrieved during said analysis is present in or on the security document.
  • At least part of the diversification data comprises a pattern formed on the surface of the security document.
  • the security document comprises a memory in which at least part of the diversification data item is recorded, the analysis comprising reading the memory to recover the said at least part of the diversification data item.
  • the encrypted data is decrypted from the diversification data combined with a decryption master key.
  • the decryption master key is matched to an encryption master key separate from the decryption master key.
  • the key encryption key is for example that used to obtain encryption encrypted data.
  • the personalization device cooperates with a secure container to cause said decryption
  • said secure container decrypts the encrypted data received by the personalization device to obtain said personalization data.
  • said secure container :
  • said secure container decrypts, from the derived key, the encrypted data received by the personalization device so as to obtain said personalization data.
  • said secure container :
  • the security document comprises an electronic module able to implement the secure container.
  • the electronic module is for example a subscriber identity module (also called eUICC module).
  • the decryption master key is stored in said secure container.
  • the present invention also relates to a personalization method of a security document, comprising:
  • the processing device transmitting the encrypted data to the personalization device so that the personalization device personalizes the security document from the encrypted data.
  • the different steps of the processing method and the personalization method are determined by computer program instructions.
  • the invention also relates to a computer program on an information carrier (or recording medium), this program being capable of being implemented in an electronic device, in a reading terminal, or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of at least one of the methods defined above.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the invention also provides a computer-readable information carrier (or recording medium), and including instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • the present invention also relates to a processing device for preparing the personalization of a security document, comprising:
  • a obtaining module able to obtain personalization data for personalizing the security document
  • an encryption module capable of encrypting the personalization data from a diversification data item associated with the security document or with an individual, so as to produce encrypted data
  • a transmission module capable of transmitting the encrypted data to a personalization device in order to enable the latter to personalize the security document from the encrypted data and the diversification data.
  • the invention also relates to a personalization device for personalizing a security document, comprising:
  • a reception module able to receive encrypted data
  • an analysis module adapted to analyze the security document so as to retrieve a diversification data item associated with said security document or capable of obtaining diversification data associated with an individual;
  • a decryption module adapted to decrypt the encrypted data from the diversification data to obtain personalization data
  • a personalization module adapted to customize the security document from the personalization data.
  • the invention further relates to a personalization system of a security document, said system comprising:
  • the processing device being configured to transmit the encrypted data to the personalization device so that the personalization device can customize the security document from the encrypted data.
  • the security document defined in the embodiments of the methods and devices above can be a smart card, for example in accordance with ISO / IEC 7816.
  • FIG. 2 diagrammatically represents the structure of a system comprising a processing device and a personalization device, according to a particular embodiment of the invention
  • - Figure 3 schematically shows modules implemented in the processing device of Figure 2, according to a particular embodiment of the invention
  • FIG. 4 schematically shows modules implemented in the personalization device of Figure 2, according to a particular embodiment of the invention
  • FIG. 5 represents, in the form of a flowchart, the main steps of a processing method and a personalization method implemented respectively by a processing device and a personalization device, according to an embodiment. particular of the invention
  • FIG. 6 schematically shows the structure of an electronic module of a security document, according to a particular embodiment of the invention.
  • the invention relates to the personalization of security documents, such as bank cards, or identity cards, and e-passports, for example.
  • the security document is a smart card (for example in accordance with ISO / IEC 7816) suitable, for example, for use as a bank card for banking purposes.
  • smart cards for example in accordance with ISO / IEC 7816
  • smart cards other than bank cards and security documents other than a smart card can be envisaged within the scope of the invention.
  • the invention proposes to secure the personalization of a security document.
  • the invention requires that the personalization data be transmitted in encrypted form to the entity in charge of personalization, the encryption of the personalization data being carried out on the basis of a given data.
  • the diversification document associated with the security document This personalization data is for example present in and / or on the security document to customize. This diversification data can be constitutive of the security document itself.
  • the entity in charge of the customization can then decipher the personalization data only if it has access to the security document itself in or on which is the diversification data.
  • the retrieval of the diversification data from the security document makes it possible to decrypt the personalization data and thus, to personalize the security document concerned.
  • FIG. 2 diagrammatically represents the structure of a processing device DA implemented under the supervision of an entity EA, as well as the structure of a personalization device DB implemented under the supervision of an entity EB, in accordance with to a particular embodiment.
  • the EA and EB devices are here able to cooperate together to form a SY system.
  • the processing device DA is able to prepare the customization of a security document C, namely a smart card in this example.
  • the personalization device DB (distinct from the security document C) is able to customize the smart card C from personalization data transmitted by the processing device DA.
  • the processing device DA here comprises a processor 10, a non-volatile memory 12 and a communication interface 14.
  • the device DA has for example the architecture of a computer.
  • the memory 12 is a rewritable non-volatile memory or a read only memory (ROM), this memory constituting a recording medium (or information carrier) according to a particular embodiment, readable by the processing device DA, and on which is recorded a computer program PG1 according to a particular embodiment.
  • This computer program PG1 includes instructions for executing the steps of a processing method according to a particular embodiment.
  • the communication interface 14 is able to communicate with a communication interface 24 of the personalization device DB, as explained hereinafter.
  • the processor 10 driven by the computer program PG1, and cooperating as the case may be with various hardware elements of the processing device DA (memories, etc.), implements here a certain number of modules, namely: a obtaining module M2, an encryption module M4 and a transmission module M6.
  • the obtaining module M2 is able to obtain personalization data DP to personalize the security document C.
  • the obtaining module M2 is configured to obtain personal data specific to the future. owner of the security document C, and to convert this personal data into personalization data DP.
  • the encryption module M4 is able to encrypt the personalization data DP so as to produce encrypted data DC, this encryption being made from a diversification data DV associated with the security document C that it is desired to customize. It is assumed here that the encryption module M4 is able to recover the diversification data DV in an appropriate manner. It will be noted that, in a particular example, this diversification data item DV is present in and / or on the security document C. In a particular example, the diversification data item DV may be constitutive of the security document C itself (as explained below). It is however not necessary for the encryption module M4 (and more generally the device DA) to have access to the security document C itself to obtain the diversification data item DV, the latter being able to be transmitted by a third party or accessible from a database for example.
  • the encryption module As indicated later, in a particular example, the encryption module
  • M4 is configured to perform encryption in a secure container such as HSM (Hardware Security Module HSM).
  • HSM Hard Security Module
  • the transmission module M6 is capable of transmitting the encrypted data DC to the personalization device DB so that it can customize the security document C from the encrypted data DC and the diversification data DV associated with the security document C.
  • the personalization device DB comprises a processor 20, a non-volatile memory 22 and the communication interface 24 already mentioned above.
  • This device DB is capable of causing the personalization of the security document C from the encrypted data DC transmitted by the processing device DA.
  • the memory 22 is a rewritable non-volatile memory or a read only memory (ROM), this memory constituting a recording medium (or information medium) according to a particular embodiment, readable by the personalization device DB, and on which is recorded a computer program PG2 according to a particular embodiment.
  • This computer program PG2 includes instructions for performing the steps of a personalization process according to a particular embodiment.
  • the communication interface 24 is able to communicate with the communication interface 14 of the personalization device DA, as already indicated above.
  • the reception module M20 is able to receive the encrypted data DC sent by the processing device DA.
  • the transmission of the encrypted data DC of the device DA to the device DB can be done via an appropriate communication link, for example through a communication network (Internet etc.) or with the aid of a suitable medium (USB key etc.).
  • the analysis module M22 is able to analyze the security document C so as to recover the diversification data DV associated with the security document C.
  • the diversification data DV can take various forms depending on the use case.
  • the diversification data item DV is present in and / or on said document C.
  • This diversification data item DV may for example comprise at least one pattern DV1 formed on the surface of the security document C. This reason may comprise by example at least one character, symbol and / or graphic code (bar code, 2D code etc.).
  • the diversification data DV may also include at least one DV2 data stored in a memory included - if any - in the security document C, as explained in more detail below with reference to FIG.
  • the DV diversification data is constitutive of the security document C itself.
  • the diversification data item DV may comprise at least one physical characteristic constituting the security document C.
  • the diversification data item DV is for example formed by at least one non-clonal physical characteristic of the PUF type (for "Physical Unclonable Function"). of the security document C.
  • the diversification data item DV may for example comprise at least one reason formed by the structure of all or part of the document of the security document C.
  • the diversification data item DV may for example be formed in whole or in part by a set of fibers constituting the security document C, these fibers having an arrangement or any other characteristic characterizing the security document C.
  • the analysis module M22 can for example use an optical reading unit (not shown) able to perform an optical detection of the diversification data DV1 appearing on the surface of the security document C.
  • the analysis module M22 can also include a reading unit of a memory included - if any - in the security document C, as indicated above.
  • the diversification data DV is not associated with the security document C but with an individual, for example the legitimate holder (the holder) of the security document C.
  • the diversification data DV comprises at least one physical characteristic of the carrier of the security document C, such as, for example, a fingerprint of the wearer, an impression of the wearer's iris, etc.
  • the decryption module M24 is able to decrypt the encrypted data DC received from the processing device DA so as to obtain the personalization data DP. This decryption is performed from the DV diversification data retrieved by the analysis module M22. As explained in more detail below, according to some embodiments, the decryption module M24 does not itself perform the decryption of the encrypted data but cooperates with an entity (a secure container for example) external to the personalization device DB for cause decryption of the encrypted data.
  • entity a secure container for example
  • the personalization module M26 is capable of causing the personalization of the security document C from the personalization data DP retrieved by the decryption module M24. To do this, the M26 personalization module interacts with all personalization units (printing, engraving, laser carbonization or embossing system, memory writing system, etc.) necessary for the desired personalization, these personalization units (not shown) that may or may not be fully or partially included in the DB personalization device. For example, the personalization module M26 may be configured to send a print command to an external printing system in order to customize the security document C by printing.
  • the security document C may be in various forms. It may be an electronic security document or not, for example in the form of a booklet or a card.
  • the document C is a smart card, for example of the bank card type, comprising an electronic module 30 illustrated in more detail in FIG. 6.
  • the smart card C can, for example, be in accordance with ISO / IEC 7816.
  • the electronic module 30 comprises in this example the processor 40, a nonvolatile memory 42 in which a diversification data item DV2 can be recorded, and a nonvolatile memory 43 in which a master key K1 whose nature and the use will be explained later.
  • the electronic module 30 may for example be an embedded subscriber identity module, otherwise referred to as eUICC for "embedded Universal Integrated Circuit Chip".
  • the electronic module 30 may contain, in the non-volatile memory 42 and / or 43, the resultant of the diversification of the master key K1 by the diversification data DV1 and / or DV2.
  • Nonvolatile memories 40 and 42 may be one and the same physical memory.
  • the pattern DV1 formed on the surface of the card C is a first example of DV diversification data.
  • the DV2 data stored in the memory 42 is a second example of DV diversification data.
  • the DV diversification data comprises DV1 and DV2.
  • FIG. 2 represents a customization 32a of the smart card C made by printing or embossing, for example.
  • Other types of customization of the smart card C are conceivable, such as electrical customization of the electronic module 30 in this case.
  • the customization performed by the DB entity may also include a particular configuration of the electronic module 30 or the recording of personalization data in the electronic module 30.
  • the processing device DA implements a processing method for preparing the personalization of the security document C, by executing the computer program PG1.
  • the personalization device DB implements a personalization method by executing the computer program PG2.
  • the obtaining module M2 of the processing device DA obtains the personalization data DP already mentioned above, these data defining a customization of the security document C to be carried out.
  • the obtaining module M2 obtains, for example, personal data associated with the future carrier of the security document C, and then converts this personal data into personalization data DP that can be used by the personalization device DB.
  • the encryption module M4 encrypts (or encrypts) the personalization data DP, from the diversification data DV, so as to produce the encrypted data DC.
  • the personalization data DP is thus associated (or linked) to the security document C to be personalized.
  • the processing device DA does not necessarily have to have access to the security document C itself.
  • the EA entity supervising the execution of the processing device DA does not have in its possession the security document C when carrying out the processing method to prepare the personalization of the security document C.
  • the diversification data DV may for example be transmitted by a third party to the processing device DA, or be accessible for example from a database external to the processing device DA, the medium used may for example be a secure container such as an HSM ( Hardware Security Module - Security Hardware Module).
  • HSM Hardware Security Module - Security Hardware Module
  • the DV2 data recorded in the electronic module 30 of the card C constitutes the DV diversification data.
  • the DV1 pattern could be used as a DV diversification data (or DV1 and DV2 in combination).
  • the personalization data DP is encrypted from an encryption master key K1 in combination with the diversification data DV.
  • the master key Kl (or "master key” in English) is for example stored in a non-volatile memory of the processing device DA.
  • the transmission module M6 then sends (A6) the encrypted data DC to the personalization device DB so that the latter can customize the security document C from these encrypted data DC and the diversification data DV associated with the security document.
  • the reception module M20 of the personalization device DP receives the encrypted data DC during a step B6.
  • the analysis module M22 further analyzes (B8) the security document C so as to recover the diversification data item DV present in or on the security document C, namely: the data item DV2 stored in the memory 42 in this example . To do this, the analysis module M22 reads the memory 42 of the module 30 in order to recover the data item DV2. It will be noted that the recovery by the personalization device DB of the diversification data DV is only possible here insofar as the electronic module 30 is accessible for reading by the analysis module M22.
  • the EB entity is in possession of the security document C itself so that the B8 analysis can be performed.
  • the analysis step B8 may, if necessary, be carried out before the reception step B6.
  • the decryption module M24 decrypts (or decrypts) the encrypted data DC to obtain the personalization data DP.
  • This decryption B10 is performed from the DV diversification data (ie the data DV2) retrieved in step B8.
  • the personalization data DP is encrypted, during the encryption A4, from an encryption master key K1 in combination with the diversification data DV.
  • the encrypted data DC can be decrypted from a decryption master key Kla in combination with the diversification data DV.
  • This master decryption key Kla is for example stored in the non-volatile memory 43 of the electronic module 30.
  • the master keys Kl and Kla used respectively for the encryption A4 and the decryption B10 are identical (in the case of symmetric encryption).
  • the master keys Kl and Kla are master keys paired different from each other (case of asymmetric encryption). In the latter case, the encryption master key Kl only makes it possible to perform the encryption, while the master decryption key Kla only makes it possible to perform the decryption.
  • the personalization module M26 then causes the personalization of the security document C from the personalization data DP retrieved at the decryption step B10.
  • the personalization may for example comprise a physical modification on the surface of the security document C or an electrical configuration of the electronic module 30.
  • the personalization B12 may for example comprise the formation (by printing, embossing, laser carbonization, etc.) on the surface of the security document C of patterns 32a (characters, symbols, serial number, photos etc.).
  • Personalization B12 may also include recording in memory of the electronic personalization data module DP (or any other suitable electrical configuration).
  • the personalization module M26 may include the printing, embossing, memory reading, etc. systems necessary for the desired personalization. Alternatively, the personalization module M26 can be configured to send at least one command necessary to trigger the appropriate personalization operation.
  • the invention advantageously makes it possible to secure the process of customizing a security document.
  • an intrinsic link is created between the personalization data and the security document. This is possible because the diversification data (for encrypting and decrypting the personalization data) is associated with the security document.
  • Such a link is possible in particular when the diversification data is present in or on the security document, in any appropriate form (digital data stored in a memory, physical pattern present on the document, PUF, etc.).
  • the EB manufacturer overseeing the customization can only obtain the DV diversification data from the security document itself.
  • the EB entity will only be able to retrieve the DV diversification data (and thus the corresponding personalization data) when it proceeds to personalize the security document concerned.
  • the EB entity is limited in the use it can make to retrieve personalization data.
  • the entity EB in charge of customizing a first security document can use the diversification data DV present on said first document to customize it, and possibly the security documents belonging to the same lot than said first security document.
  • a DV diversification data is uniquely assigned to a given security document C so that obtaining the DV diversification data from a security document does not provide personalization data for to other security documents.
  • the same diversification data is collectively attributed to a plurality (at least one batch for example) of security documents. The analysis of a security document then makes it possible to recover a valid diversification data for the personalization of a set of security documents.
  • the invention has the consequence that the EB entity in charge of performing the customization no longer has the possibility of choosing from several sources of supply to obtain the security document. Only the security document known to the EA entity (and whose diversification data are known to it) enables the EB entity to decipher the encrypted data needed to customize the security document in question.
  • the processing device DA can use a secure container H1 to perform the encryption A4.
  • the personalization device DB can use a secure container H2 to perform the decryption B10.
  • a secure container (or digital safe) is able to record cryptographic keys and, if necessary, to perform encryption or decryption operations using such keys.
  • a secure container may be HSM (for "Hardware Security Module") or be in the form of a smart card (or “batchcard” in English).
  • the secure container H1 is contained in memory in the processing device DA.
  • the device for DA processing is able to cooperate with the secure container Hl located this time outside the processing device DA, so as to perform the A4 encryption.
  • the secure container H2 is contained in memory in the personalization device DB.
  • the personalization device DB is able to cooperate with the secure container H2 located this time outside the personalization device DB, so as to perform the decryption B10.
  • the secure container H1 contains in memory the encryption master key K1 as mentioned above.
  • the processing device DA (more particularly the encryption module M4) sends (S2) to the secure container H1 the diversification data DV.
  • the secure container H1 determines (S4) a derived key K2 by performing a cryptographic function F2 taking DV and K1 input.
  • the processing device DA sends (S6) further the personalization data DP to the secure container H1.
  • the secure container H1 produces (S8) the encrypted data DC by performing a cryptographic function F4 taking K2 input and DP. Once produced, these encrypted data DC are delivered (S10) by H1 to the processing device DA.
  • the encryption master key K1 is not registered in the secure container H1, but the latter is able to receive this master key K1 from outside (since DA for example) in order to determine the derived key K2. from the master key K2 in combination with the diversification data DV.
  • the secure container H2 proceeds in a similar manner to the secure container H1 to perform the decryption B10.
  • the secure container H2 contains in memory the master key decryption Kla already mentioned above.
  • the personalization device DB (more particularly the decryption module M24) sends (S20) to the secure container H2 the DV diversification data retrieved during the analysis B8. From the diversification data DV and the decryption master key Kla contained in the memory, the secure container H2 determines (S22) the derived key K2a already mentioned above by performing the cryptographic function F2a taking input DV and Kla.
  • the master keys Kl and Kla are identical (asymmetric encryption).
  • the functions F2 and F2a executed respectively by the containers H1 and H2 are identical, and the derived keys K2 and K2a obtained by executing respectively the functions F2 and F2a are identical.
  • the master keys Kl and Kla are paired keys that are distinct from one another (asymmetric encryption).
  • the functions F2 and F2a executed respectively by the containers H1 and H2 are different, and the derived keys K2 and K2a obtained by executing respectively the functions F2 and F2a are different.
  • the decryption master key Kla is not registered in the secure container H2, but the latter is able to receive this master key Kla from the outside (from DB for example) in order to determine the derived key K2a from the master key Kla in combination with the diversification data DV.
  • the personalization device DB further sends (S24) the encrypted data DC to the secure container H2.
  • the secure container H2 produces (S26) the personalization data DP by performing a cryptographic function F6 taking K2a and DC input. Once produced, these personalization data DP are delivered (S28) by H2 to the personalization device DB.
  • secure containers makes it possible to secure the cryptographic means (the master keys Kl and K2 in particular) necessary for encrypting and decrypting the personalization data. Indeed, entrusting a Kl, Kla master key without protection to a third party entity may present a risk insofar as it is possible, from such a master key, to perform reverse engineering to recover sensitive information. .
  • secure containers Through the use of secure containers, an entity in charge of customizing a security document will not have direct access to the master key itself (the latter being contained securely in said container).
  • the use of secure containers makes it possible to securely encrypt or decrypt the personalization data.
  • a risk remains when an entity has in its possession a secure container containing such a master key. Indeed, in the event that sufficient resources are deployed in this sense, sensitive data are still likely to be obtained from such a secure container.
  • the EA (or a third party) may, for example, not have sufficient confidence in the EB entity to let it hold such a secure container for a long time.
  • the present invention proposes that the secure container for decrypting the encrypted data is itself contained in a memory of the security document that one wishes to customize.
  • the secure container H2 is included in the security document C, plus precisely in the electronic module 30 in the example envisaged here.
  • the personalization device DP is able to cooperate with the electronic module 30 of the security document C in order to allow the execution of the steps S20 to S28 already described.
  • the personalization device DB and more generally the EB entity that supervises it, have access to the secure container H2 - and thus indirectly to the master key K1 - only when they hold the document C security to customize.
  • the secure container H2 In the absence of the security document C, the secure container H2 is out of reach of the EB entity, thus reducing the security risks mentioned above.
  • the secure container H2 is able to implement the cryptographic function F6, the secure container H2 possibly being implemented in the security document C.
  • the secure container H2 which may optionally be implemented in the electronic module 30 of the security document C, contains the decryption master key Kla and is capable of executing the cryptographic function F2a in order to obtain the derived key K2a.
  • the cryptographic function F6 is executed outside the security document C, and thus outside the secure container H2.
  • the secure container H2 is for example configured to transmit (S23) the derived key K2a to a terminal T external to the security document C, and therefore external to the secure container H2.
  • the external terminal T may, for example, be the processing device DB.
  • the external terminal T can thus execute the function F6 from the derived key K2a and the encrypted data DC, in order to obtain (S27) the personalization data DP. If necessary, the external terminal T can transmit (S29) the personalization data DP to the processing device DB.
  • This embodiment is advantageous when the security document C to be customized does not have the resources necessary to perform the decryption operation.
  • the personalization device DB when the secure container H2 containing the encryption master key Kla is implemented in the document C, the personalization device DB, and more generally the EB entity that supervises it, do not have access to the key derivative K2a, and thus indirectly to the Kla decryption master key, only when they hold the security document C to customize. In the absence of the security document C, the decryption master key Kla and the derived key K2a are out of reach of the entity EB, thus reducing the security risks mentioned above.
  • the decryption master key Kla is not registered in the secure container H2, but the latter is able to receive this master key Kla (from DB for example ) to determine the derived key K2a from the master key Kla and the diversification data DV.
  • the container H 1 (respectively H 2) does not perform the function F 2 (respectively F 2a), nor does it contain Kl (respectively Kla). It contains only the key K2 (respectively K2a).
  • the containers H1 and H2 do not respectively perform the functions F2 and F2a, nor do they contain Kl and Kla respectively. They contain only keys K2 and K2a respectively.
  • the secure containers H1 and H2 are, for example, each able to receive respectively the bypass key K2 and K2a from the outside in order respectively to perform the functions F4 and F6.
  • the invention makes it possible to customize securely a security document. It will be noted, however, that other applications of the invention may be envisaged. It is indeed conceivable to use the invention for a purpose other than the customization of a security document.
  • the invention aims to securely transmit data associated with a security document from a first entity to a second entity.
  • the invention is implemented by means of software and / or hardware components.
  • module used in this presentation can correspond as well to a software component, a hardware component or a set of hardware and software components.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un procédé de traitement, réalisé par un dispositif de traitement (DA), pour préparer la personnalisation d'un document de sécurité (C), comprenant l'obtention de données de personnalisation (DP), le chiffrement des données de personnalisation à partir d'une donnée de diversification (DV) associée au document de sécurité (C), de sorte à produire des données chiffrées; et la transmission des données chiffrées à un dispositif de personnalisation (DB) pour permettre à ce dernier de personnaliser le document de sécurité (C) à partir des données chiffrées et de la donnée de diversification (DV). L'invention comprend également un procédé de personnalisation d'un document de sécurité (C) par un tel dispositif de personnalisation (DB).

Description

Procédé de personnalisation d'un document de sécurité
Arrière-plan technologique
L'invention se rapporte au domaine des documents de sécurité, tels que les cartes bancaires ou d'identité, et passeports électroniques, et porte plus particulièrement sur la personnalisation de tels documents.
Les documents de sécurité sont des documents comportant des caractéristiques physiques permettant une authentification fiable du porteur du document, et du document lui-même. Autrement dit, ces caractéristiques physiques permettent, à partir d'un protocole d'authentification prédéterminé, de s'assurer qu'un individu est bien le propriétaire légitime du document de sécurité en question, et que le document lui-même est un document authentique. Ces caractéristiques physiques (impressions, matériaux spéciaux, données numérique enregistrées...) sont généralement difficiles à contrefaire afin de protéger le document électronique contre tout acte de malveillance.
Les documents de sécurité se présentent sous diverses formes plus ou moins complexes. On notera en particulier les documents de sécurité dits « électroniques » dans le sens où ils comportent un module électronique équipé d'au moins une mémoire, au contraire des documents de sécurité classiques qui sont dépourvus d'une telle mémoire. Les cartes d'identité, cartes bancaires (généralement des cartes à puce) ou encore les passeports électroniques constituent des exemples courants de documents de sécurité.
Lors de leur fabrication, ces documents de sécurité sont généralement personnalisés. Cette étape de personnalisation consiste à apposer, sur et/ou dans le document de sécurité, des données personnelles propres au futur propriétaire du document. Ces données personnelles sont par exemple imprimées ou embossées à la surface du document. Dans le cas des documents de sécurité électroniques, de telles données personnelles peuvent également être enregistrées dans la mémoire du module électronique. Typiquement, lors d'une personnalisation d'une carte bancaire, le fabricant appose des données personnelles du porteur sur les faces de la carte (nom, prénom, N° de carte etc.) et enregistre des données personnelles dans la puce de la carte.
La figure 1 représente schématiquement un procédé de personnalisation utilisé conventionnellement pour personnaliser un document de sécurité. Dans cet exemple, une première entité 2 (présente sur un premier site ST2) et une deuxième entité 4 (présente sur un deuxième site ST4) coopèrent ensemble afin de réaliser la personnalisation d'un document de sécurité 6. Pour ce faire, l'entité 2 collecte des données personnelles propres au porteur d'un document de sécurité 6 à personnaliser puis convertit (E2) ces données personnelles en données de personnalisation PR définissant des personnalisations physiques (impressions, embossage, enregistrement de données...) à apporter au document de sécurité 6. L'entité 2 envoie (E4) ultérieurement ces données de personnalisation PR à l'entité 4 qui poursuit alors le processus sur le site ST4. Pour ce faire, l'entité 4 reçoit (E6) les données de personnalisation PR puis personnalise (E8) le document de sécurité 6 à partir des données de personnalisation PR.
Ce procédé connu présente cependant un risque en ce qu'un document de sécurité peut éventuellement être personnalisé avec des données personnelles qui ne lui étaient pas destinées. Une entité 4 peut en effet personnaliser par erreur (ou volontairement) le document de sécurité 6 avec les données de personnalisation associées à une personne autre que le propriétaire légitime du document de sécurité. Le processus de personnalisation est donc aujourd'hui confronté à des risques importants de fiabilité et de sécurité.
Des problèmes de sécurité existent par ailleurs dans le cas où plusieurs entités 4 différentes se partagent la charge de personnaliser un ensemble de documents de sécurité. Un risque existe dans la mesure où plusieurs entités 4 (présentes sur différents sites) ont accès aux données de personnalisation PR envoyées par l'entité 2. Lorsque les données de personnalisation PR présentent un caractère confidentiel, la dispersion de ces données parmi divers acteurs capables de traiter et utiliser ces données est problématique.
Par ailleurs, l'entité 4 en charge de la personnalisation jouit en général d'une relative flexibilité quant au choix des documents de sécurité vierges qu'il utilise lorsqu'il réalise la personnalisation E8. Dans certains cas, l'entité 4 a la possibilité de choisir parmi plusieurs sources d'approvisionnement en document de sécurité 6. L'entité 2 ou un tiers n'ont pas aujourd'hui les moyens de s'assurer que l'entité 4 réalise bien la personnalisation E8 sur un document de sécurité 6 d'une origine spécifique. Il en résulte un aléa économique, notamment pour certains fabricants qui souhaitent sécuriser leur activité de fabrication de documents de sécurité.
Il existe donc aujourd'hui un besoin pour d'avantage de sécurité et de fiabilité dans le processus de personnalisation d'un document de sécurité.
Objet et résumé
Un des buts de l'invention est de remédier aux insuffisances de l'état de la technique exposées ci-avant. A cet effet, la présente invention concerne un procédé de traitement, mis en œuvre par un dispositif de traitement, pour préparer la personnalisation d'un document de sécurité, le procédé comprenant :
obtention de données de personnalisation pour personnaliser le document de sécurité ;
chiffrement des données de personnalisation, à partir d'une donnée de diversification associée au document de sécurité et/ou à un individu, de sorte à produire des données chiffrées ; et
transmission des données chiffrées à un dispositif de personnalisation pour permettre à ce dernier de personnaliser le document de sécurité à partir des données chiffrées et de la donnée de diversification.
Dans un mode de réalisation particulier, la donnée de diversification est associée (ou liée) au document de sécurité mais pas à un individu.
Selon un mode de réalisation particulier, la donnée de diversification est présente dans ou sur le document de sécurité.
L'invention permet avantageusement de sécuriser le processus de personnalisation d'un document de sécurité. Pour ce faire, un lien intrinsèque est créé entre les données de personnalisation et le document de sécurité. Ceci est possible car la donnée de diversification (permettant de chiffrer et déchiffrer les données de personnalisation) est présente dans ou sur le document de sécurité, sous une quelconque forme appropriée (donnée numérique enregistrée dans une mémoire, motif physique présent sur le document etc.). Ainsi, seule l'analyse du document de sécurité permet de récupérer la donnée de diversification lors de la personnalisation. Autrement dit, le fabricant supervisant la personnalisation ne peut obtenir la donnée de diversification DV qu'à partir du document de sécurité lui-même. Typiquement, la donnée de diversification (et donc les données de personnalisation correspondantes) ne peuvent être récupérées que lorsque la personnalisation du document de sécurité débute, diminuant ainsi grandement les risques de sécurité mentionnés ci-avant.
Par ailleurs, même lorsqu'il est en possession de la donnée de diversification, l'entité en charge de la personnalisation est limitée dans l'usage qu'il peut en faire pour récupérer des données de personnalisation. Ainsi, grâce à l'invention, une entité en charge de personnaliser un premier document de sécurité ne pourra utiliser la donnée de diversification présente sur ledit premier document que pour personnaliser celui-ci, et éventuellement les documents de sécurité appartenant au même lot que ledit premier document de sécurité (selon que cette donnée de diversification est attribuée de façon unique ou collective à un ou plusieurs documents de sécurité). Selon un mode de réalisation particulier, lors du chiffrement, la donnée de personnalisation est chiffrée à partir d'une clé maîtresse de chiffrement en combinaison avec la donnée de diversification.
Selon un mode de réalisation particulier, la clé maîtresse de chiffrement est appariée à une clé maîtresse de déchiffrement distincte de la clé maîtresse de chiffrement.
Selon un mode de réalisation particulier, dans lequel le dispositif de traitement utilise un conteneur sécurisé pour réaliser ledit chiffrement, la clé maîtresse de chiffrement étant enregistrée dans le conteneur sécurisé,
dans lequel ledit conteneur sécurisé :
- détermine une clé dérivée à partir de la donnée de diversification et de la clé maîtresse de chiffrement, et
chiffre, à partir de la clé dérivée, les données de personnalisation pour produire les données chiffrées.
La présente invention concerne également un procédé de personnalisation d'un document de sécurité, mis en uvre par un dispositif de personnalisation, ledit procédé comprenant :
réception de données chiffrées ;
analyse du document de sécurité de sorte à récupérer une donnée de diversification associée audit document de sécurité ou obtention d'une donnée de diversification associée à un individu ;
déchiffrement des données chiffrées à partir de la donnée de diversification pour obtenir des données de personnalisation ; et
personnalisation du document de sécurité à partir des données de personnalisation.
Selon un mode de réalisation particulier, au moins une partie (ou la totalité) de la donnée de diversification récupérée lors de ladite analyse est présente dans ou sur le document de sécurité.
Selon un mode de réalisation particulier, au moins une partie de la donnée de diversification comprend un motif formé à la surface du document de sécurité.
Selon un mode de réalisation particulier, le document de sécurité comprend une mémoire dans laquelle est enregistrée au moins une partie de la donnée de diversification, l'analyse comprenant la lecture de la mémoire pour récupérer ladite au moins une partie de la donnée de diversification.
Selon un mode de réalisation particulier, lors du déchiffrement, les données chiffrées sont déchiffrées à partir de la donnée de diversification combinée avec une clé maîtresse de déchiffrement. Selon un mode de réalisation particulier, la clé maîtresse de déchiffrement est appariée à une clé maîtresse de chiffrement distincte de la clé maîtresse de déchiffrement. La clé maîtresse de chiffrement est par exemple celle ayant servi à obtenir par chiffrement les données chiffrées.
Selon un mode de réalisation particulier, le dispositif de personnalisation coopère avec un conteneur sécurisé pour causer ledit déchiffrement,
dans lequel ledit conteneur sécurisé déchiffre les données chiffrées reçues par le dispositif de personnalisation de sorte à obtenir lesdites données de personnalisation.
Selon un mode de réalisation particulier, ledit conteneur sécurisé :
- détermine une clé dérivée à partir de la clé maîtresse de déchiffrement et à partir de la donnée de diversification récupérée par le dispositif de personnalisation lors de ladite analyse ; et
déchiffre, à partir de la clé dérivée, les données chiffrées reçues par le dispositif de personnalisation de sorte à obtenir lesdites données de personnalisation. Selon un mode de réalisation particulier, ledit conteneur sécurisé :
- détermine une clé dérivée à partir de la clé maîtresse de déchiffrement et à partir de la donnée de diversification récupérée par le dispositif de personnalisation lors de ladite analyse ; et
- transmet la clé dérivée à un terminal externe pour que ce dernier déchiffre les données chiffrées de sorte à obtenir lesdites données de personnalisation.
Selon un mode de réalisation particulier, le document de sécurité comprend un module électronique apte à mettre en œuvre le conteneur sécurisé. Le module électronique est par exemple un module d'identité de souscripteur (aussi appelé module eUICC).
Selon un mode de réalisation particulier, la clé maîtresse de déchiffrement est enregistrée dans ledit conteneur sécurisé.
La présente invention concerne également un procédé de personnalisation d'un document de sécurité, comprenant :
un procédé de traitement mis en œuvre par un dispositif de traitement, comme défini ci-avant; et
un procédé de personnalisation mis en œuvre par un dispositif de personnalisation, comme défini ci-avant ;
le dispositif de traitement transmettant les données chiffrées au dispositif de personnalisation afin que ce dernier personnalise le document de sécurité à partir des données chiffrées. Dans un mode particulier de réalisation, les différentes étapes du procédé de traitement et du procédé de personnalisation sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations (ou support d'enregistrement), ce programme étant susceptible d'être mis en œuvre dans un dispositif électronique, dans un terminal de lecture, ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'au moins l'un des procédés définis ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations (ou support d'enregistrement) lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
La présente invention concerne par ailleurs un dispositif de traitement pour préparer la personnalisation d'un document de sécurité, comprenant :
- un module d'obtention apte à obtenir des données de personnalisation pour personnaliser le document de sécurité ;
un module de chiffrement apte à chiffrer les données de personnalisation à partir d'une donnée de diversification associée au document de sécurité ou à un individu, de sorte à produire des données chiffrées ; et
- un module de transmission apte à transmettre les données chiffrées à un dispositif de personnalisation pour permettre à ce dernier de personnaliser le document de sécurité à partir des données chiffrées et de la donnée de diversification.
L'invention concerne également un dispositif de personnalisation pour personnaliser un document de sécurité, comprenant :
- un module de réception apte à recevoir des données chiffrées ;
un module d'analyse apte à analyser le document de sécurité de sorte à récupérer une donnée de diversification associée audit document de sécurité ou apte à obtenir une donnée de diversification associée à un individu ;
un module de déchiffrement apte à déchiffrer les données chiffrées à partir de la donnée de diversification pour obtenir des données de personnalisation ; et un module de personnalisation apte à personnaliser le document de sécurité à partir des données de personnalisation.
À noter que les différents modes de réalisation définis ci-avant en relation avec le procédé de traitement, d'une part, et avec le procédé de personnalisation, d'autre part, ainsi que les avantages associés à ces procédés, s'appliquent par analogie aux dispositifs respectifs définis ci-avant. En particulier, la donnée de diversification peut être présente dans ou sur le document de sécurité.
L'invention concerne en outre un système de personnalisation d'un document de sécurité, ledit système comprenant :
- un dispositif de traitement tel que défini ci-avant ;
un dispositif de personnalisation tel que défini ci-avant ;
le dispositif de traitement étant configuré pour transmettre les données chiffrées au dispositif de personnalisation afin que ce dernier puisse personnaliser le document de sécurité à partir des données chiffrées.
Le document de sécurité défini dans les modes de réalisation des procédés et dispositifs ci-avant peut être une carte à puce, par exemple conforme à la norme ISO/IEC 7816.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures:
- la figure 1 déjà décrite représente, de manière schématique, un procédé conventionnel de personnalisation d'un document de sécurité ;
- la figure 2 représente schématiquement la structure d'u système comprenant un dispositif de traitement et un dispositif de personnalisation, selon un mode de réalisation particulier de l'invention ; - la figure 3 représente schématiquement des modules mis en œuvre dans le dispositif de traitement de la figure 2, conformément à un mode de réalisation particulier de l'invention ;
- la figure 4 représente schématiquement des modules mis en oeuvre dans le dispositif de personnalisation de la figure 2, conformément à un mode de réalisation particulier de l'invention ;
- la figure 5 représente, sous forme d'un organigramme, les principales étapes d'un procédé de traitement et d'un procédé de personnalisation mis en œuvre respectivement par un dispositif de traitement et un dispositif de personnalisation, conformément à un mode de réalisation particulier de l'invention ;
- la figure 6 représente schématiquement la structure d'un module électronique d'un document de sécurité, conformément à un mode de réalisation particulier de l'invention ;
- les figures 7 et 8 représentent schématiquement une variante de réalisation de l'invention ; et
- la figure 9 représente schématiquement une variante de réalisation de l'invention. Description détaillée de plusieurs modes de réalisation
Comme indiqué précédemment, l'invention porte sur la personnalisation de documents de sécurité, tels que cartes bancaires, ou d'identité, et passeports électroniques par exemple.
Dans les exemples de réalisation qui suivent, le document de sécurité est une carte à puce (par exemple conforme à la norme ISO/IEC 7816) apte, par exemple, à être utilisée comme carte bancaire pour réaliser des opérations bancaires. On comprendra toutefois que des cartes à puces autre que cartes bancaires et des documents de sécurité autres qu'une carte à puce peuvent être envisagés dans le cadre de l'invention.
L'invention propose de sécuriser la personnalisation d'un document de sécurité. Pour ce faire, l'invention, selon ses différents modes de réalisation, requière que les données de personnalisation soient transmises sous forme chiffrée à l'entité en charge de la personnalisation, le chiffrement des données de personnalisation étant réalisé à partir d'une donnée dite de diversification associée au document de sécurité. Cette donnée de personnalisation est par exemple présente dans et/ou sur le document de sécurité à personnaliser. Cette donnée de diversification peut être constitutive du document de sécurité lui-même. L'entité en charge de la personnalisation ne peut alors déchiffrer les données de personnalisation que si elle a accès au document de sécurité lui-même dans ou sur lequel se trouve la donnée de diversification. La récupération de la donnée de diversification depuis le document de sécurité permet de déchiffrer les données de personnalisation et donc, de personnaliser le document de sécurité concerné.
Sauf indications contraires, les éléments communs (ou analogues) à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques (ou analogues), de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité.
La figure 2 représente schématiquement la structure d'un dispositif de traitement DA mis en œuvre sous la supervision d'une entité EA, ainsi que la structure d'un dispositif de personnalisation DB mis en œuvre sous la supervision d'une entité EB, conformément à un mode de réalisation particulier. Les dispositifs EA et EB sont ici aptes à coopérer ensemble pour former un système SY.
Dans l'exemple envisagé ici, le dispositif de traitement DA est apte à préparer la personnalisation d'un document de sécurité C, à savoir une carte à puce dans cet exemple. Le dispositif de personnalisation DB (distinct du document de sécurité C) est apte à personnaliser la carte à puce C à partir de données de personnalisation transmises par le dispositif de traitement DA.
Plus spécifiquement, le dispositif de traitement DA comprend ici un processeur 10, une mémoire non volatile 12 et une interface de communication 14. Le dispositif DA présente par exemple l'architecture d'un ordinateur.
La mémoire 12 est une mémoire non volatile réinscriptible ou une mémoire morte (ROM), cette mémoire constituant un support d'enregistrement (ou support d'informations) conforme à un mode de réalisation particulier, lisible par le dispositif de traitement DA, et sur lequel est enregistré un programme d'ordinateur PGl conforme à un mode de réalisation particulier. Ce programme d'ordinateur PGl comporte des instructions pour l'exécution des étapes d'un procédé de traitement selon un mode de réalisation particulier.
L'interface de communication 14 est apte à communiquer avec une interface de communication 24 du dispositif de personnalisation DB, comme expliqué ci-après.
Comme représenté en figure 3, le processeur 10, piloté par le programme d'ordinateur PGl, et coopérant le cas échéant avec divers éléments matériels du dispositif de traitement DA (mémoires etc.), met ici en œuvre un certain nombre de modules, à savoir : un module d'obtention M2, un module de chiffrement M4 et un module de transmission M6.
Le module d'obtention M2 est apte à obtenir des données de personnalisation DP pour personnaliser le document de sécurité C. Dans l'exemple envisagé ici, le module d'obtention M2 est configuré pour obtenir des données personnelles propres au futur propriétaire du document de sécurité C, et à convertir ces données personnelles en données de personnalisation DP.
Le module de chiffrement M4 est apte à chiffrer les données de personnalisation DP de sorte à produire des données chiffrées DC, ce chiffrement étant réalisé à partir d'une donnée de diversification DV associée au document de sécurité C que l'on souhaite personnaliser. On suppose ici que le module de chiffrement M4 est apte à récupérer la donnée de diversification DV d'une façon appropriée. On notera que, dans un exemple particulier, cette donnée de diversification DV est présente dans et/ou sur le document de sécurité C. Dans un exemple particulier, la donnée de diversification DV peut être constitutive du document de sécurité C lui-même (comme expliqué ci-après). Il n'est toutefois pas nécessaire que le module de chiffrement M4 (et plus généralement le dispositif DA) ait accès au document de sécurité C lui-même pour obtenir la donnée de diversification DV, cette dernière pouvant être transmise par un tiers ou accessible depuis une base de données par exemple.
Comme indiqué par la suite, dans un exemple particulier, le module de chiffrement
M4 est configuré pour réaliser le chiffrement dans un conteneur sécurisé tel un HSM (Hardware Security Module HSM - Module Matériel de Sécurité).
Le module de transmission M6 est apte à transmettre les données chiffrées DC au dispositif de personnalisation DB pour permettre à ce dernier de personnaliser le document de sécurité C à partir des données chiffrées DC et de la donnée de diversification DV associée au document de sécurité C.
Comme représenté en figure 2, le dispositif de personnalisation DB comprend un processeur 20, une mémoire non volatile 22 et l'interface de communication 24 déjà mentionnée ci-avant. Ce dispositif DB est apte à causer la personnalisation du document de sécurité C à partir des données chiffrées DC transmises par le dispositif de traitement DA.
La mémoire 22 est une mémoire non volatile réinscriptible ou une mémoire morte (ROM), cette mémoire constituant un support d'enregistrement (ou support d'informations) conforme à un mode de réalisation particulier, lisible par le dispositif de personnalisation DB, et sur lequel est enregistré un programme d'ordinateur PG2 conforme à un mode de réalisation particulier. Ce programme d'ordinateur PG2 comporte des instructions pour l'exécution des étapes d'un procédé personnalisation selon un mode de réalisation particulier.
L'interface de communication 24 est apte à communiquer avec l'interface de communication 14 du dispositif de personnalisation DA, comme déjà indiqué ci-avant.
Comme représenté en figure 4, le processeur 20, piloté par le programme d'ordinateur PG2, et coopérant le cas échéant avec divers éléments matériels du dispositif de personnalisation DB (mémoires etc.), met ici en œuvre un certain nombre de modules, à savoir : un module de réception M20, un module d'analyse M22, un module de déchiffrement M24 et un module de personnalisation M26.
Le module de réception M20 est apte à recevoir les données chiffrées DC envoyées par le dispositif de traitement DA. La transmission des données chiffrées DC du dispositif DA au dispositif DB peut se faire via une liaison de communication appropriée, au travers par exemple d'un réseau de communication (Internet etc.) ou à l'aide d'un support adapté (clé USB etc.).
Le module d'analyse M22 est apte à analyser le document de sécurité C de sorte à récupérer la donnée de diversification DV associée au document de sécurité C. La donnée de diversification DV peut prendre divers formes selon le cas d'usage.
Dans un exemple particulier, la donnée de diversification DV est présente dans et/ou sur ledit document C. Cette donnée de diversification DV peut par exemple comprendre au moins un motif DV1 formé à la surface du document de sécurité C. Ce motif peut comprendre par exemple au moins un caractère, symbole et/ou code graphique (code barre, code 2D etc.). La donnée de diversification DV peut également comprendre au moins une donnée DV2 enregistrée dans une mémoire incluse - le cas échéant - dans le document de sécurité C, comme expliqué plus en détail ci-après en référence à la figure 6.
Dans un exemple particulier, la donnée de diversification DV est constitutive du document de sécurité C lui-même. Autrement dit, la donnée de diversification DV peut comprendre au moins une caractéristique physique constitutive du document de sécurité C. La donnée de diversification DV est par exemple formée par au moins une caractéristique physique non clonale de type PUF (pour « Physical Unclonable Function ») du document de sécurité C. La donnée de diversification DV peut par exemple comprendre au moins un motif formée par la structure de tout ou partie du document du document de sécurité C. La donnée de diversification DV peut par exemple être formée en tout ou partie par un ensemble de fibres constitutives du document de sécurité C, ces fibres présentant un agencement ou tout autre caractéristique caractérisant le document de sécurité C.
Aussi, la nature et la mise en œuvre de l'analyse du document C par le module d'analyse M22 peut varier selon le cas d'espèce. Le module d'analyse M22 peut par exemple utiliser une unité de lecture optique (non représentée) apte à réaliser une détection optique de la donnée de diversification DV1 figurant à la surface du document de sécurité C. Le module d'analyse M22 peut également comprendre une unité de lecture d'une mémoire incluse - le cas échéant - dans le document de sécurité C, comme indiqué ci-avant. Dans un exemple particulier, la donnée de diversification DV n'est pas associée au document de sécurité C mais à un individu, par exemple le porteur légitime (le titulaire) du document de sécurité C. Dans un exemple particulier, la donnée de diversification DV comprend au moins une caractéristique physique du porteur du document de sécurité C, comme par exemple une empreinte digitale du porteur, une empreinte de l'iris du porteur...
Le module de déchiffrement M24 est apte à déchiffrer les données chiffrées DC reçues du dispositif de traitement DA de sorte à obtenir les données de personnalisation DP. Ce déchiffrement est réalisé à partir de la donnée de diversification DV récupérée par le module d'analyse M22. Comme expliqué plus en détail par la suite, selon certains modes de réalisation, le module de déchiffrement M24 ne réalise pas lui-même le déchiffrement des données chiffrées mais coopère avec une entité (un conteneur sécurisé par exemple) externe au dispositif de personnalisation DB pour causer le déchiffrement des données chiffrées.
Le module de personnalisation M26 est apte à causer la personnalisation du document de sécurité C à partir des données de personnalisation DP récupérées par le module de déchiffrement M24. Pour ce faire, le module de personnalisation M26 interagit avec toutes unités de personnalisation (système d'impression, de gravure, de carbonisation laser ou d'embossage, système d'écriture d'une mémoire etc.) nécessaires à la personnalisation souhaitée, ces unités de personnalisation (non représentées) pouvant être, ou non, incluses totalement ou partiellement dans le dispositif de personnalisation DB. Le module de personnalisation M26 peut par exemple être configuré pour envoyer une commande d'impression à un système d'impression externe afin de réaliser une personnalisation du document de sécurité C par impression.
Comme déjà indiqué, le document de sécurité C peut se présenter selon diverses formes. Il peut s'agir d'un document de sécurité électronique ou non, se présentant par exemple sous la forme d'un livret ou d'une carte.
Comme représenté en figure 2, on suppose ici que le document C est une carte à puce, par exemple de type carte bancaire, comprenant un module électronique 30 illustré plus en détail en figure 6. La carte à puce C peut, par exemple, être conforme à la norme ISO/IEC 7816.
Plus spécifiquement, le module électronique 30 comprend dans cet exemple le processeur 40, une mémoire non volatile 42 dans laquelle peut être enregistrée une donnée de diversification DV2, et une mémoire non volatile 43 dans laquelle peut être enregistrée une clé maîtresse Kl dont la nature et l'usage seront expliqués par la suite. Le module électronique 30 peut par exemple être un module d'identité de souscripteur embarqué, autrement désigné sous l'appellation eUICC pour « embedded Universal Integrated Circuit Chip ».
Dans un mode de réalisation, le module électronique 30 peut contenir, dans la mémoire non volatile 42 et/ou 43, la résultante de la diversification de la clef maîtresse Kl par la donnée de diversification DV1 et/ou DV2.
Les mémoires non volatiles 40 et 42 peuvent être une seule et même mémoire physique.
Comme déjà indiqué, le motif DV1 formé à la surface de la carte C constitue un premier exemple de donnée de diversification DV. La donnée DV2 enregistrée dans la mémoire 42 constitue un deuxième exemple de donnée de diversification DV. Selon un mode particulier, la donnée de diversification DV comprend DV1 et DV2.
Par ailleurs, la figure 2 représente ici une personnalisation 32a de la carte à puce C réalisée par impression ou embossage par exemple. D'autres types de personnalisation de la carte à puce C sont envisageables, telle qu'une personnalisation électrique du module électronique 30 dans le cas présent. La personnalisation réalisée par l'entité DB peut également comprendre une configuration particulière du module électronique 30 ou l'enregistrement de données de personnalisation dans le module électronique 30.
Un mode de réalisation particulier est à présent décrit en référence à la figure 5. Plus précisément, le dispositif de traitement DA met en œuvre un procédé de traitement pour préparer la personnalisation du document de sécurité C, en exécutant le programme d'ordinateur PG1. De même, le dispositif de personnalisation DB met en œuvre un procédé de personnalisation en exécutant le programme d'ordinateur PG2.
Au cours d'une étape A2, le module d'obtention M2 du dispositif de traitement DA obtient les données de personnalisation DP déjà mentionnées ci-avant, ces données définissant une personnalisation du document de sécurité C à réaliser. Pour ce faire, le module d'obtention M2 obtient par exemple des données personnelles associées au futur porteur du document de sécurité C, puis convertit ces données personnelles en données de personnalisation DP exploitables par le dispositif de personnalisation DB.
Au cours d'une étape A4, le module de chiffrement M4 chiffre (ou encrypte) les données de personnalisation DP, à partir de la donnée de diversification DV, de sorte à produire les données chiffrées DC. Les données de personnalisation DP sont ainsi associées (ou liées) au document de sécurité C à personnaliser.
Pour récupérer la donnée de diversification DV, le dispositif de traitement DA ne doit pas nécessairement avoir accès au document de sécurité C lui-même. Typiquement, l'entité EA supervisant l'exécution du dispositif de traitement DA n'a pas en sa possession le document de sécurité C lors de la réalisation du procédé de traitement pour préparer la personnalisation du document de sécurité C.
La donnée de diversification DV peut par exemple être transmise par un tiers au dispositif de traitement DA, ou être accessible par exemple depuis une base de données externe au dispositif de traitement DA, le support utilisé pouvant par exemple être un conteneur sécurisé tel un HSM (Hardware Security Module -Module Matériel de Sécurité).
Dans cet exemple, on suppose que la donnée DV2 enregistrée dans le module électronique 30 de la carte C constitue la donnée de diversification DV. Alternativement, le motif DV1 pourrait être utilisé en tant que donnée de diversification DV (ou DV1 et DV2 en combinaison).
Dans un mode de réalisation particulier, lors du chiffrement A4, les données de personnalisation DP sont chiffrées à partir d'une clé maîtresse de chiffrement Kl en combinaison avec la donnée de diversification DV. La clé maîtresse Kl (ou « master key » en anglais) est par exemple enregistrée dans une mémoire non volatile du dispositif de traitement DA.
Le module de transmission M6 envoie (A6) ensuite les données chiffrées DC au dispositif de personnalisation DB afin que ce dernier puisse personnaliser le document de sécurité C à partir de ces données chiffrées DC et de la donnée de diversification DV associé au document de sécurité.
Le module de réception M20 du dispositif de personnalisation DP reçoit la donnée chiffrée DC au cours d'une étape B6.
Le module d'analyse M22 analyse (B8) par ailleurs le document de sécurité C de sorte à récupérer la donnée de diversification DV présente dans ou sur le document de sécurité C, à savoir : la donnée DV2 enregistrée dans la mémoire 42 dans cet exemple. Pour ce faire, le module d'analyse M22 effectue une lecture de la mémoire 42 du module 30 afin de récupérer la donnée DV2. On notera que la récupération, par le dispositif de personnalisation DB, de la donnée de diversification DV n'est ici possible que dans la mesure où le module électronique 30 est accessible en lecture par le module d'analyse M22.
De manière plus générale, il est généralement nécessaire que l'entité EB soit en possession du document de sécurité C lui-même pour que l'analyse B8 puisse être réalisée.
L'étape d'analyse B8 peut le cas échéant être réalisée avant l'étape de réception B6. Au cours d'une étape B10, le module de déchiffrement M24 déchiffre (ou décrypte) les données chiffrées DC pour obtenir les données de personnalisation DP. Ce déchiffrement B10 est réalisé à partir de la donnée de diversification DV (i.e. la donnée DV2) récupérée à l'étape B8. Comme décrit précédemment, dans un mode de réalisation particulier, les données de personnalisation DP sont chiffrées, lors du chiffrement A4, à partir d'une clé maîtresse de chiffrement Kl en combinaison avec la donnée de diversification DV. Toujours dans ce mode de réalisation, lors du déchiffrement B10, les données chiffrées DC peuvent être déchiffrées à partir d'une clé maîtresse de déchiffrement Kla en combinaison avec la donnée de diversification DV. Cette clé maîtresse de déchiffrement Kla est par exemple enregistrée dans la mémoire non volatile 43 du module électronique 30.
Selon un premier mode de réalisation, les clés maîtresses Kl et Kla utilisées respectivement pour le chiffrement A4 et le déchiffrement B10 sont identiques (cas d'un chiffrement symétrique). Selon un deuxième mode de réalisation, les clés maîtresses Kl et Kla sont des clés maîtresses appariées différentes l'une de l'autre (cas d'un chiffrement asymétrique). Dans ce dernier cas, la clé maîtresse de chiffrement Kl permet uniquement de réaliser le chiffrement, tandis que la clé maîtresse de déchiffrement Kla permet uniquement de réaliser le déchiffrement.
Au cours d'une étape B12, le module de personnalisation M26 cause ensuite la personnalisation du document de sécurité C à partir des données de personnalisation DP récupérées à l'étape de déchiffrement B10. La personnalisation peut par exemple comprendre une modification physique en surface du document de sécurité C ou encore une configuration électrique du module électronique 30. La personnalisation B12 peut par exemple comprendre la formation (par impression, embossage, carbonisation laser, etc.) en surface du document de sécurité C de motifs 32a (caractères, symboles, numéro de série, photos etc.). La personnalisation B12 peut également comprendre l'enregistrement dans une mémoire du module électronique 30 de données de personnalisation DP (ou tout autre configuration électrique appropriée).
On notera que le module de personnalisation M26 peut inclure les systèmes d'impression, d'embossage, de lecture de mémoire etc., nécessaires à la personnalisation souhaitée. Alternativement, le module de personnalisation M26 peut être configuré pour envoyer au moins une commande nécessaire pour déclencher l'opération de personnalisation appropriée.
L'invention permet avantageusement de sécuriser le processus de personnalisation d'un document de sécurité. Pour ce faire, un lien intrinsèque est créé entre les données de personnalisation et le document de sécurité. Ceci est possible car la donnée de diversification (permettant de chiffrer et déchiffrer les données de personnalisation) est associée au document de sécurité. Un tel lien est notamment possible lorsque la donnée de diversification est présente dans ou sur le document de sécurité, sous une quelconque forme appropriée (donnée numérique enregistrée dans une mémoire, motif physique présent sur le document, PUF, etc.). Ainsi, seule l'analyse du document de sécurité permet de récupérer la donnée de diversification lors de la personnalisation. Autrement dit, le fabricant EB supervisant la personnalisation ne peut obtenir la donnée de diversification DV qu'à partir du document de sécurité lui-même. Typiquement, l'entité EB sera seulement en mesure de récupérer la donnée de diversification DV (et donc les données de personnalisation correspondantes) lorsqu'il procédera à la personnalisation du document de sécurité concerné.
Par ailleurs, même lorsqu'il est en possession de la donnée de diversification DV, l'entité EB est limitée dans l'usage qu'il peut en faire pour récupérer des données de personnalisation. Ainsi, grâce à l'invention, l'entité EB en charge de personnaliser un premier document de sécurité ne pourra utiliser la donnée de diversification DV présente sur ledit premier document que pour personnaliser celui-ci, et éventuellement les documents de sécurité appartenant au même lot que ledit premier document de sécurité.
Dans un exemple particulier, une donnée de diversification DV est attribuée de façon unique à un document de sécurité C donné de sorte que l'obtention de la donnée de diversification DV depuis un document de sécurité ne permette pas d'obtenir des données de personnalisation destinées à d'autres documents de sécurité. Alternativement, une même donnée de diversification est attribuée collectivement à une pluralité (au moins un lot par exemple) de documents de sécurité. L'analyse d'un document de sécurité permet alors de récupérer une donnée de diversification valide pour la personnalisation d'un ensemble de documents de sécurité.
Par ailleurs, l'invention a pour conséquence que l'entité EB en charge de réaliser la personnalisation n'a plus la possibilité de choisir parmi plusieurs sources d'approvisionnement pour obtenir le document de sécurité. Seul le document de sécurité connu de l'entité EA (et dont les données de diversification lui sont connus) met l'entité EB en capacité de déchiffrer des données chiffrées nécessaires pour personnaliser le document de sécurité en question.
Selon un mode de réalisation décrit en référence aux figures 7 et 8, le dispositif de traitement DA peut utiliser un conteneur sécurisé Hl pour réaliser le chiffrage A4. De même, le dispositif de personnalisation DB peut utiliser un conteneur sécurisé H2 pour réaliser le déchiffrage B10.
Un conteneur sécurisé (ou coffre-fort numérique) est apte à enregistrer des clés cryptographiques et, le cas échéant, à réaliser des opérations de chiffrage ou de déchiffrage à l'aide de de telles clés. Un conteneur sécurisé peut être de type HSM (pour « Hardware Security Module ») ou encore se présenter sous la forme d'une carte à puce (ou « batchcard» en anglais).
Selon un exemple particulier, le conteneur sécurisé Hl est contenu en mémoire dans le dispositif de traitement DA. Selon un autre exemple de réalisation, le dispositif de traitement DA est apte à coopérer avec le conteneur sécurisé Hl situé cette fois hors du dispositif de traitement DA, de façon à réaliser le chiffrage A4.
De même, selon un exemple particulier, le conteneur sécurisé H2 est contenu en mémoire dans le dispositif de personnalisation DB. Selon un autre exemple de réalisation, le dispositif de personnalisation DB est apte à coopérer avec le conteneur sécurisé H2 situé cette fois hors du dispositif de personnalisation DB, de façon à réaliser le déchiffrage B10.
Comme représenté en figure 7, le conteneur sécurisé Hl contient en mémoire la clé maîtresse de chiffrement Kl comme mentionnée précédemment. Au cours du chiffrement A4, le dispositif de traitement DA (plus particulièrement le module de chiffrement M4) envoie (S2) au conteneur sécurisé Hl la donnée de diversification DV. A partir de la donnée de diversification DV et de la clé maîtresse de chiffrement Kl contenue en mémoire, le conteneur sécurisé Hl détermine (S4) une clé dérivée K2 en réalisant une fonction cryptographique F2 prenant en entrée DV et Kl. Le dispositif de traitement DA envoie (S6) en outre les données de personnalisation DP au conteneur sécurisé Hl. A partir de la clé dérivée K2 et des données de personnalisation DP, le conteneur sécurisé Hl produit (S8) les données chiffrées DC en réalisant une fonction cryptographique F4 prenant en entrée K2 et DP. Une fois produites, ces données chiffrées DC sont délivrées (S10) par Hl au dispositif de traitement DA.
Selon une variante de réalisation, la clé maîtresse de chiffrement Kl n'est pas enregistrée dans le conteneur sécurisé Hl mais ce dernier est apte à recevoir cette clé maîtresse Kl depuis l'extérieur (depuis DA par exemple) afin de déterminer la clé dérivée K2 à partir de la clé maîtresse K2 en combinaison avec la donnée de diversification DV.
Comme représenté en figure 8, le conteneur sécurisé H2 procède de façon analogue au conteneur sécurisé Hl pour réaliser le déchiffrage B10.
Plus spécifiquement, le conteneur sécurisé H2 contient en mémoire la clé maîtresse de déchiffrement Kla déjà mentionnée ci-avant. Au cours du déchiffrement B10, le dispositif de personnalisation DB (plus particulièrement le module de déchiffrement M24) envoie (S20) au conteneur sécurisé H2 la donnée de diversification DV récupérée lors de l'analyse B8. A partir de la donnée de diversification DV et de la clé maîtresse de déchiffrement Kla contenue en mémoire, le conteneur sécurisé H2 détermine (S22) la clé dérivée K2a déjà mentionnée ci-avant en réalisant la fonction cryptographique F2a prenant en entrée DV et Kla.
Selon un premier exemple, les clés maîtresses Kl et Kla sont identiques (chiffrement asymétrique). Dans ce cas, les fonctions F2 et F2a exécutées respectivement par les conteneurs Hl et H2 sont identiques, et les clés dérivées K2 et K2a obtenues en exécutant respectivement les fonctions F2 et F2a sont identiques. Selon un deuxième exemple, les clés maîtresses Kl et Kla sont des clés appariées distinctes l'une de l'autre (chiffrement asymétrique). Dans ce cas, les fonctions F2 et F2a exécutées respectivement par les conteneurs Hl et H2 sont différentes, et les clés dérivées K2 et K2a obtenues en exécutant respectivement les fonctions F2 et F2a sont différentes.
Selon une variante de réalisation, la clé maîtresse de déchiffrement Kla n'est pas enregistrée dans le conteneur sécurisé H2 mais ce dernier est apte à recevoir cette clé maîtresse Kla depuis l'extérieur (depuis DB par exemple) afin de déterminer la clé dérivée K2a à partir de la clé maîtresse Kla en combinaison avec la donnée de diversification DV.
Comme illustré en figure 8, le dispositif de personnalisation DB envoie (S24) en outre les données chiffrées DC au conteneur sécurisé H2. A partir de la clé dérivée K2a et des données chiffrées DC, le conteneur sécurisé H2 produit (S26) les données de personnalisation DP en réalisant une fonction cryptographique F6 prenant en entrée K2a et DC. Une fois produites, ces données de personnalisation DP sont délivrées (S28) par H2 au dispositif de personnalisation DB.
L'usage de conteneurs sécurisés permet de sécuriser les moyens cryptographiques (les clés maîtresses Kl et K2 notamment) nécessaires pour chiffrer et déchiffrer les données de personnalisation. En effet, confier une clé maîtresse Kl, Kla sans protection à une entité tierce peut présenter un risque dans la mesure où il est possible, à partir d'une telle clé maîtresse, de réaliser de l'ingénierie inverse afin de récupérer des informations sensibles. Grâce à l'usage de conteneurs sécurisés, une entité en charge de personnaliser un document de sécurité n'aura pas d'accès direct à la clé maîtresse elle-même (celle-ci étant contenue de façon sécurisée dans ledit conteneur). L'usage des conteneurs sécurisés permet de chiffrer ou déchiffrer de façon sécurisée les données de personnalisation.
Toutefois, dans certains cas, un risque subsiste lorsqu'une entité a en sa possession un conteneur sécurisé contenant un telle clé maîtresse. En effet, dans l'hypothèse où suffisamment de ressources sont déployées en ce sens, des données sensibles sont toujours susceptibles d'être obtenues à partir d'un tel conteneur sécurisé. L'entité EA (ou un tiers) peut par exemple ne pas avoir suffisant confiance dans l'entité EB pour lui laisser de façon prolongée un tel conteneur sécurisé.
Pour pallier ce problème, selon un mode de réalisation particulier, la présente invention propose, que le conteneur sécurisé permettant le déchiffrage des données chiffrées soit lui-même contenu dans une mémoire du document de sécurité que l'on souhaite personnaliser.
Plus précisément, selon un mode de réalisation particulier, le conteneur sécurisé H2, décrit ci-avant en référence à la figure 8, est inclus dans le document de sécurité C, plus précisément dans le module électronique 30 dans l'exemple envisagé ici. Le dispositif de personnalisation DP est apte à coopérer avec le module électronique 30 du document de sécurité C afin de permettre l'exécution des étapes S20 à S28 déjà décrites.
Dans ce mode de réalisation particulier, le dispositif de personnalisation DB, et plus généralement l'entité EB qui le supervise, n'ont accès au conteneur sécurisé H2 - et donc indirectement à la clé maîtresse Kl - que lorsque qu'ils détiennent le document de sécurité C à personnaliser. En l'absence du document de sécurité C, le conteneur sécurisé H2 est hors de portée de l'entité EB, diminuant ainsi les risques de sécurité mentionnés ci- avant.
Dans les exemples décrits en référence à la figure 8, le conteneur sécurisé H2 est apte à mettre en œuvre la fonction cryptographique F6, le conteneur sécurisé H2 pouvant le cas échéant être mis en œuvre dans le document de sécurité C. Selon une variante de réalisation illustrée en figure 9, le conteneur sécurisé H2, pouvant le cas échéant être mis en œuvre dans le module électronique 30 du document de sécurité C, contient la clé maîtresse de déchiffrement Kla et est apte à exécuter la fonction cryptographique F2a afin d'obtenir la clé dérivée K2a. En revanche, la fonction cryptographique F6 est exécutée hors du document de sécurité C, et donc hors du conteneur sécurisé H2. Dans ce cas, le conteneur sécurisé H2 est par exemple configuré pour transmettre (S23) la clé dérivée K2a à un terminal T externe au document de sécurité C, et donc externe au conteneur sécurisé H2. Le terminal externe T peut, par exemple, être le dispositif de traitement DB. Le terminal externe T peut ainsi exécuter la fonction F6 à partir de la clé dérivée K2a et des données chiffrées DC, afin d'obtenir (S27) les données de personnalisation DP. Le cas échéant, le terminal externe T peut transmettre (S29) les données de personnalisation DP au dispositif de traitement DB. Ce mode de réalisation est avantageux lorsque le document de sécurité C à personnaliser ne dispose pas des ressources nécessaires pour réaliser l'opération de déchiffrement.
Dans un exemple particulier, lorsque le conteneur sécurisé H2 contenant la clé maîtresse de chiffrement Kla est mis en œuvre dans le document C, le dispositif de personnalisation DB, et plus généralement l'entité EB qui le supervise, n'ont accès à la clé dérivée K2a, et donc indirectement à la clé maîtresse de déchiffrement Kla, que lorsque qu'ils détiennent le document de sécurité C à personnaliser. En l'absence du document de sécurité C, la clé maîtresse de déchiffrement Kla et la clé dérivée K2a sont hors de portée de l'entité EB, diminuant ainsi les risques de sécurité mentionnés ci-avant.
Selon une variante du mode de réalisation décrit ci-dessus en référence à la figure 9, la clé maîtresse de déchiffrement Kla n'est pas enregistrée dans le conteneur sécurisé H2 mais ce dernier être apte à recevoir cette clé maîtresse Kla (depuis DB par exemple) afin de déterminer la clé dérivée K2a à partir de la clé maîtresse Kla et de la donnée de diversification DV.
Selon un mode de réalisation particulier, le conteneur Hl (respectivement H2) ne réalise pas la fonction F2 (respectivement F2a), ni ne contient Kl (respectivement Kla). Il contient uniquement la clef K2 (respectivement K2a).
Selon un mode de réalisation particulier, les conteneurs Hl et H2 ne réalisent pas respectivement les fonctions F2 et F2a, ni ne contiennent respectivement Kl et Kla. Ils contiennent uniquement respectivement les clefs K2 et K2a.
Les conteneurs sécurisés Hl et H2 sont par exemple chacun aptes à recevoir respectivement la clé de dérivation K2 et K2a depuis l'extérieur afin de réaliser respectivement les fonctions F4 et F6.
Comme décrit ci-avant, l'invention permet de réaliser une personnalisation de façon sécurisée d'un document de sécurité. On notera toutefois que d'autres applications de l'invention peuvent être envisagées. Il est en effet envisageable d'utiliser l'invention dans un but autre que la personnalisation d'un document de sécurité.
Plus généralement, l'invention vise à transmettre de façon sécurisée des données associées à un document de sécurité depuis une première entité vers une deuxième entité.
Un homme du métier comprendra que les modes de réalisation et variantes décrits ci- avant ne constituent que des exemples non limitatifs de mise en œuvre de l'invention. En particulier, l'homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant afin de répondre à un besoin bien particulier.
Selon un mode de réalisation, l'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme « module » employé dans le présent exposé peut correspondre aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.

Claims

REVENDICATIONS
1. Procédé de traitement, mis en œuvre par un dispositif de traitement (DA), pour préparer la personnalisation d'un document de sécurité (C), ledit procédé comprenant : obtention (A2) de données de personnalisation (DP) pour personnaliser le document de sécurité ;
- chiffrement (A4) des données de personnalisation, à partir d'une donnée de diversification (DV) associée au document de sécurité et/ou à un individu, de sorte à produire des données chiffrées (DC) ; et
transmission (A6) des données chiffrées à un dispositif de personnalisation (DB) pour permettre à ce dernier de personnaliser le document de sécurité à partir des données chiffrées et de la donnée de diversification,
dans lequel, lors du chiffrement, la donnée de personnalisation (DP) est chiffrée à partir d'une clé maîtresse de chiffrement (Kl) en combinaison avec la donnée de diversification.
2. Procédé selon la revendication 1, dans lequel la donnée de diversification (DV) est présente dans ou sur le document de sécurité (C).
3. Procédé selon la revendication 1 ou 2, dans lequel, la clé maîtresse de chiffrement (Kl) est appariée à une clé maîtresse de déchiffrement (Kla) distincte de la clé maîtresse de chiffrement (Kl).
4. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel le dispositif de traitement utilise un conteneur sécurisé (Hl) pour réaliser ledit chiffrement, la clé maîtresse de chiffrement (Kl) étant enregistrée dans le conteneur sécurisé,
dans lequel ledit conteneur sécurisé :
détermine une clé dérivée (K2) à partir de la donnée de diversification et de la clé maîtresse de chiffrement (Kl), et
chiffre, à partir de la clé dérivée (K2), les données de personnalisation (DP) pour produire les données chiffrées (DC).
5. Procédé de personnalisation d'un document de sécurité (C), mis en œuvre par un dispositif de personnalisation (DB), ledit procédé comprenant : réception (B6) de données chiffrées (DC) ;
analyse (B8) du document de sécurité de sorte à récupérer une donnée de diversification (DV) associée audit document de sécurité ou obtention d'une donnée de diversification associée à un individu ;
- déchiffrement (B10) des données chiffrées à partir de la donnée de diversification pour obtenir des données de personnalisation (DP) ; et
personnalisation (B12) du document de sécurité à partir des données de personnalisation,
dans lequel au moins une partie de la donnée de diversification récupérée lors de ladite analyse comprend un motif (DV1) formé à la surface du document de sécurité.
6. Procédé selon la revendication 5, dans lequel le document de sécurité comprend une mémoire (42) dans laquelle est enregistrée au moins une partie (DV2) de la donnée de diversification, l'analyse comprenant la lecture de la mémoire pour récupérer ladite au moins une partie de la donnée de diversification.
7. Procédé selon la revendication 5 ou 6, dans lequel, lors du déchiffrement, les données chiffrées (DC) sont déchiffrées à partir de la donnée de diversification (DV) combinée avec une clé maîtresse de déchiffrement (Kla).
8. Procédé selon la revendication 7, dans lequel la clé maîtresse de déchiffrement (Kla) est appariée à une clef maîtresse de chiffrement (Kl) distincte de la clé maîtresse de déchiffrement (Kla).
9. Procédé selon la revendication 7 ou 8, dans lequel le dispositif de personnalisation (DB) coopère avec un conteneur sécurisé (H2) pour causer ledit déchiffrement,
dans lequel ledit conteneur sécurisé déchiffre (S26) les données chiffrées (DC) reçues par le dispositif de personnalisation de sorte à obtenir lesdites données de personnalisation (DP).
10. Procédé selon la revendication 9, dans lequel le conteneur sécurisé (H2) :
détermine (S22) une clé dérivée (K2a) à partir de la clé maîtresse de déchiffrement (Kla) et à partir de la donnée de diversification (DV) récupérée par le dispositif de personnalisation (DB) lors de ladite analyse ; et déchiffre (S26), à partir de la clé dérivée (K2a), les données chiffrées (DC) reçues par le dispositif de personnalisation de sorte à obtenir lesdites données de personnalisation (DP).
11. Procédé selon la revendication 7 ou 8, le dispositif de personnalisation (DB) coopérant avec le conteneur sécurisé (H2) pour causer ledit déchiffrement,
dans lequel ledit conteneur sécurisé :
- détermine (S22) une clé dérivée (K2a) à partir de la clé maîtresse de déchiffrement (Kla) et à partir de la donnée de diversification (DV) récupérée par le dispositif de personnalisation (DB) lors de ladite analyse ; et
- transmet la clé dérivée (K2a) à un terminal externe pour que ce dernier déchiffre (S27) les données chiffrées (DC) de sorte à obtenir lesdites données de personnalisation (DP).
12. Procédé selon l'une quelconque des revendications 9 à 11, dans lequel le document de sécurité (C) comprend un module électronique (30) apte à mettre en œuvre le conteneur sécurisé (H2).
13. Procédé selon l'une quelconque des revendications 9 ou 12, la clé maîtresse de déchiffrement (Kla) étant enregistrée dans le conteneur sécurisé (H2).
14. Procédé de personnalisation d'un document de sécurité (C), comprenant :
un procédé de traitement mis en œuvre par un dispositif de traitement (DA) selon l'une quelconque des revendications 1 à 4; et
- un procédé de personnalisation mis en œuvre par un dispositif de personnalisation (DB) selon l'une quelconque des revendications 5 à 13;
le dispositif de traitement transmettant les données chiffrées (DC) au dispositif de personnalisation afin que ce dernier personnalise le document de sécurité à partir des données chiffrées.
15. Programme d'ordinateur (PG1 ; PG2) comportant des instructions pour l'exécution des étapes d'un procédé selon l'une quelconque des revendications 1 à 14 lorsque ledit programme est exécuté par un ordinateur.
16. Dispositif de traitement (DA) pour préparer la personnalisation d'un document de sécurité (C), comprenant : un module d'obtention (M2) apte à obtenir des données de personnalisation pour personnaliser le document de sécurité ;
un module de chiffrement (M4) apte à chiffrer les données de personnalisation à partir d'une donnée de diversification (DV) associée au document de sécurité ou à un individu, de sorte à produire des données chiffrées ; et
un module de transmission (M6) apte à transmettre les données chiffrées à un dispositif de personnalisation pour permettre à ce dernier de personnaliser le document de sécurité à partir des données chiffrées et de la donnée de diversification,
dans lequel le module de chiffrement (M4) est configuré pour chiffrer la donnée de personnalisation (DP) à partir d'une clé maîtresse de chiffrement (Kl) en combinaison avec la donnée de diversification.
17. Dispositif de personnalisation (DB) pour personnaliser un document de sécurité (C), comprenant :
un module de réception (M20) apte à recevoir des données chiffrées ;
un module d'analyse (M22) apte à analyser le document de sécurité de sorte à récupérer une donnée de diversification associée audit document de sécurité ou apte à obtenir une donnée de diversification associée à un individu ;
un module de déchiffrement (M24) apte à déchiffrer les données chiffrées à partir de la donnée de diversification pour obtenir des données de personnalisation ; et
un module de personnalisation (M26) apte à personnaliser le document de sécurité à partir des données de personnalisation,
dans lequel au moins une partie de la donnée de diversification récupérée par ledit module d'analyse (MD22) comprend un motif (DVl) formé à la surface du document de sécurité.
18. Système (SY) de personnalisation d'un document de sécurité (C), ledit système comprenant :
un dispositif de traitement (DA) selon la revendication 16 ; et
un dispositif de personnalisation (DB) selon la revendication 17 ;
le dispositif de traitement étant configuré pour transmettre les données chiffrées au dispositif de personnalisation afin que ce dernier puisse personnaliser le document de sécurité à partir des données chiffrées.
EP16825821.8A 2015-12-10 2016-12-09 Procede de personnalisation d'un document de securite Active EP3387784B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1562108A FR3045252B1 (fr) 2015-12-10 2015-12-10 Procede de personnalisation d'un document de securite
PCT/FR2016/053318 WO2017098189A1 (fr) 2015-12-10 2016-12-09 Procede de personnalisation d'un document de securite

Publications (2)

Publication Number Publication Date
EP3387784A1 true EP3387784A1 (fr) 2018-10-17
EP3387784B1 EP3387784B1 (fr) 2019-09-25

Family

ID=55862884

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16825821.8A Active EP3387784B1 (fr) 2015-12-10 2016-12-09 Procede de personnalisation d'un document de securite

Country Status (5)

Country Link
US (1) US11082227B2 (fr)
EP (1) EP3387784B1 (fr)
ES (1) ES2763102T3 (fr)
FR (1) FR3045252B1 (fr)
WO (1) WO2017098189A1 (fr)

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE468068C (sv) * 1991-09-30 1994-04-11 Comvik Gsm Ab Förfarande för personifiering av ett aktivt kort, för användning i ett mobiltelefonsystem
DE69824437T2 (de) * 1997-10-14 2005-06-23 Visa International Service Association, Foster City Personalisieren von chipkarten
US6729549B2 (en) * 2000-12-19 2004-05-04 International Business Machines Corporation System and method for personalization of smart cards
US7762457B2 (en) * 2001-07-10 2010-07-27 American Express Travel Related Services Company, Inc. System and method for dynamic fob synchronization and personalization
EP1544706A1 (fr) * 2003-12-18 2005-06-22 Axalto S.A. Procédé permettant de protéger et d'utiliser des fichiers de données adaptés à la personalisation de carte à puce
US7963438B2 (en) * 2005-11-10 2011-06-21 Magtek, Inc. System and method for personalizing a card
US20080005567A1 (en) * 2006-01-24 2008-01-03 Stepnexus, Inc. Method and system for personalizing smart cards using asymmetric key cryptography
US8752770B2 (en) * 2008-08-19 2014-06-17 Mastercard International Incorporated Methods and systems to remotely issue proximity payment devices
US9172539B2 (en) * 2011-09-14 2015-10-27 Mastercard International Incorporated In-market personalization of payment devices
WO2014075162A1 (fr) * 2012-11-15 2014-05-22 Behzad Malek Système et procédé permettant une authentification de transactions financières sur la base d'un emplacement

Also Published As

Publication number Publication date
WO2017098189A1 (fr) 2017-06-15
ES2763102T3 (es) 2020-05-27
FR3045252B1 (fr) 2019-05-03
EP3387784B1 (fr) 2019-09-25
FR3045252A1 (fr) 2017-06-16
US11082227B2 (en) 2021-08-03
US20180367312A1 (en) 2018-12-20

Similar Documents

Publication Publication Date Title
EP3078155B1 (fr) Procédé de mise a jour d'une arborescence de fichiers mémorisée sur un serveur de stockage
EP1909431B1 (fr) Procédé d'authentification mutuelle entre une interface de communication et un processeur hôte d'un chipset NFC
KR20210061426A (ko) 이중 암호화된 시크릿 부분의 서브세트를 사용하여 시크릿의 어셈블리를 허용하는 이중 암호화된 시크릿 부분
EP3590223A1 (fr) Procede et dispositif pour memoriser et partager des donnees integres
CA3142763C (fr) Procede de chiffrement et de stockage de fichiers informatiques et dispositif de chiffrement et de stockage associe.
FR2960328A1 (fr) Procede de gestion de circuits integres avec generation interne d'une cle personnelle d'authentification
WO2009050368A2 (fr) Communication securisee entre une etiquette electronique et un lecteur
CA2888662A1 (fr) Systeme et procede de securisation des echanges de donnees, objet portable utilisateur et dispositif distant de telechargement de donnees
EP2388948A1 (fr) Procédé et système d'accès à un circuit intégré comprenant une clé personnelle d'authentification
EP3387784B1 (fr) Procede de personnalisation d'un document de securite
EP3789898B1 (fr) Procédé de génération d'une clé
FR2892876A1 (fr) Procede de depot securise de donnees numeriques, procede associe de recuperation de donnees numeriques, dispositifs associes pour la mise en oeuvre des procedes, et systeme comprenant les dits dispositifs
EP4068679A1 (fr) Authentification d'un dispositif par un traitement cryptographique
FR3073111A1 (fr) Procede et dispositif pour memoriser et partager des donnees integres
EP2285042A1 (fr) Module logiciel de sécurisation utilisant le chiffrement du haché d'un mot de passe concaténé avec une graine
EP3166252B1 (fr) Procédé d'enregistrement sécurisé de données, dispositif et programme correspondants
FR2925730A1 (fr) Procede et systeme pour authentifier des individus a partir de donnees biometriques
FR3042626A1 (fr) Procede et systeme d'acces securise et discrimine a des services d'un circuit integre, par diversification d'une unique cle racine
FR2875977A1 (fr) Systeme et procede cryptographique a cle publique et serveur de certification, memoires adaptees pour ce systeme
EP1262860B1 (fr) Système et procédé d'authentification d'un utilisateur
WO2003105096A2 (fr) Procede de mise a jour de donnees sur une puce, notamment d'une c arte a puce
EP2876611A1 (fr) Procédé de transmission sécurisée d'une image d'un document d'identité électronique vers un terminal
FR3157621A3 (fr) Portefeuille matériel biométrique, et procédés correspondants
EP4338078A1 (fr) Procédé pour l'exécution d'un programme charge dans la mémoire non volatile d'un microcontrôleur en circuit intégré
WO2021249854A1 (fr) Procédé d'acquisition et de traitement sécurisé d'une information secrète acquise

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20180618

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20190405

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 1184889

Country of ref document: AT

Kind code of ref document: T

Effective date: 20191015

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: FRENCH

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602016021436

Country of ref document: DE

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20190925

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191226

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1184889

Country of ref document: AT

Kind code of ref document: T

Effective date: 20190925

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200127

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Ref document number: 2763102

Country of ref document: ES

Kind code of ref document: T3

Effective date: 20200527

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200224

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602016021436

Country of ref document: DE

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 602016021436

Country of ref document: DE

PG2D Information on lapse in contracting state deleted

Ref country code: IS

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200126

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20191231

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

26N No opposition filed

Effective date: 20200626

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200701

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20191209

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20191209

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20191231

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20191231

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20191231

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20161209

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190925

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230428

REG Reference to a national code

Ref country code: ES

Ref legal event code: PC2A

Owner name: IDEMIA FRANCE

Effective date: 20241008

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20251120

Year of fee payment: 10

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: IT

Payment date: 20251119

Year of fee payment: 10

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20251120

Year of fee payment: 10

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: ES

Payment date: 20260102

Year of fee payment: 10