EP3149684A1 - Procédé pour sécuriser la revente d'un objet équipé d'une étiquette nfc - Google Patents

Procédé pour sécuriser la revente d'un objet équipé d'une étiquette nfc

Info

Publication number
EP3149684A1
EP3149684A1 EP15732811.3A EP15732811A EP3149684A1 EP 3149684 A1 EP3149684 A1 EP 3149684A1 EP 15732811 A EP15732811 A EP 15732811A EP 3149684 A1 EP3149684 A1 EP 3149684A1
Authority
EP
European Patent Office
Prior art keywords
server
owner
identifier
electronic tag
request
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.)
Withdrawn
Application number
EP15732811.3A
Other languages
German (de)
English (en)
Inventor
Mikaël DUBREUCQ
Saad JANATI IDRISSI
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.)
Wisekey Semiconductors SAS
Original Assignee
Vault-Ic France
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 Vault-Ic France filed Critical Vault-Ic France
Publication of EP3149684A1 publication Critical patent/EP3149684A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/018—Certifying business or products
    • G06Q30/0185—Product, service or business identity fraud
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
    • G06K7/10—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation
    • G06K7/10009—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves
    • G06K7/10297—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves arrangements for handling protocols designed for non-contact record carriers such as RFIDs NFCs, e.g. ISO/IEC 14443 and 18092
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication

Definitions

  • the present invention relates to the sale and resale of objects having a high market value, including luxury goods or art works.
  • the present invention applies in particular to the online sale of such objects.
  • Some objects can benefit from a certificate of authenticity in the form of a print.
  • a certificate of authenticity is not directly accessible by the site, and therefore the authenticity of such a certificate can hardly be established. Potential buyers are therefore not encouraged to buy an object whose value is essentially related to its authenticity.
  • Some online resale sites offer to provide a service of control of the authenticity of the objects put on sale. However, a generally relatively high commission is required in return, and the confidence likely to be attributed to such a service may be limited. Potential sellers therefore have little incentive to use such a service.
  • RFID Radio Frequency IDentification
  • NFC Near Field Communication
  • Embodiments are directed to a method for securing the sale of an object, comprising the steps of: storing an object identifier and an object owner identifier, by a server and in a secure memory of an object an electronic tag linked to the object, transmitting the identifier of the object, from the electronic tag to a terminal via a contactless or near-field link, providing the server with information relating to the object in response to a request; request designating the object, transmit to the server an update request of the owner identifier, containing information relating to a new owner of the object, memorize by the server the information relating to the new owner in relation to the identifier of the object, generate by the server a write request containing an identifier of the new owner transmit the write request to the electronic tag by the contactless or near-field link, and store in the electronic tag the identifier of the new owner received in the write request.
  • the method comprises the steps of: providing the server with an access code in response to a request containing the identifier of the object, and providing the information relating to the object by the server in question. response to a request containing the access code.
  • the method comprises a step of providing by the server in response to the request containing the access code, information relating to the owner of the object.
  • the method comprises a step of supplying the electronic tag in response to a read request, information relating to the object, and possibly information relating to the owner of the object.
  • the write request generated by the server securely indicates the server as the originator of the request, the identifier of the new owner, received in the write request, being stored, and secure manner, in the electronic tag, only if the sender of the request is the server.
  • the method comprises the steps of: selecting by the server an encryption key according to the received object identifier, generating by the server using the encryption key cryptographic data containing in encrypted form the identifier of the owner, received from the terminal, transmitting the cryptographic data to the electronic tag, decrypting the cryptographic data by the electronic tag using a decryption key corresponding to the encryption key, for obtain the identifier of the owner, and memorize securely in the electronic tag the identifier of the owner.
  • the encryption and decryption keys are identical and correspond to a secret key, the identifier of the owner being encrypted using a symmetric encryption algorithm, or the encryption key is a key public, and the decryption key is a private key corresponding to the public key, the identifier of the owner being encrypted using an asymmetric encryption algorithm, the cryptographic data comprising an electronic signature issued by the server, the method comprising a step of verification by the electronic tag that the signature has been issued by the server.
  • the storage by the server information about the owner and the issue by the server of the write request are made only if the owner is identified as such by the server.
  • the owner is identified as such by the server through the provision to the server by the owner of a code secret generated by the server and delivered to the owner by a seller of the object, or during a period during which the server authorizes the update of the owner identifier in the electronic tag.
  • Embodiments also relate to a transaction system for the sale of an object, comprising: a server accessible by a data transmission network, an electronic tag linked to an object, and a terminal including communication interfaces for establishing an object. contactless or near-field communication with the electronic tag and to establish a communication with the server, the electronic tag being configured to: store an identifier of the object in a secure memory of the electronic tag, issue the identifier of the object, receiving a write request containing an identifier of the owner of the object, and storing in the secure memory the identifier of the owner received in the write request, the server being configured to: receive and store information relating to the owner of the object, in relation to information relating to the object, provide information information relating to the object in response to a request designating the object, and generating and issuing the write request containing an identifier of the owner, the terminal being configured to: read information relating to the object and the owner of the object object stored in the electronic tag, transmit to the server a request for updating the identification information of the
  • the server is configured to: provide an access code in response to a request containing the identifier of the object, and provide in response to a request containing the access code, the information relating to the object, and possibly the information about the owner of the object.
  • the electronic tag is configured to provide in response to a read request, information stored by the electronic tag relating to the object, and possibly relating to the owner of the object.
  • the server is configured to store information relating to the owner and to issue the identifier of the owner to the electronic tag only if the owner is identified as such by the server.
  • the server is configured to generate a secret code to deliver to a seller of the object, and to identify as the owner of the object a person providing the secret code.
  • the server is configured to identify as the owner of the object a person providing him with identifying information during a period during which the server authorizes the updating of the owner identifier in the electronic tag .
  • Figure 1 schematically represents steps of a procedure for recording information relating to the owner of an object equipped with an electronic tag, according to an embodiment
  • FIG. 2 diagrammatically represents an electronic tag and a terminal equipped with a communication interface with the electronic tag
  • FIG. 3 schematically represents steps of a procedure for putting on sale and selling an object equipped with an electronic tag, according to one embodiment
  • FIG. 4 represents steps of a procedure for recording information relating to the owner of an object equipped with an electronic tag, according to another embodiment
  • FIG. 5 diagrammatically represents steps of a procedure for putting on sale and selling an object equipped with an electronic tag, according to another embodiment
  • FIG. 6 represents steps of a procedure for recording information relating to the owner of an object equipped with an electronic tag, according to another embodiment
  • FIG. 7 schematically represents steps of a procedure for putting on sale and selling an object equipped with an electronic tag, according to another embodiment.
  • FIG. 1 represents steps S1 to S7 of a procedure P1 executed according to one embodiment, following the acquisition of an object OB associated with a TG identification electronic tag, comprising a contactless RFID or NFC chip.
  • the procedure P1 can be executed from a communication terminal SP1 configured to communicate with the electronic tag TG of the RFID or NFC type and with a remote server BSRV in relation with a manufacturer of the object OB.
  • FIG. 2 shows an example of terminal SP1 and electronic tag TG.
  • the terminal SP1 comprises a processor BBP and a memory LM, for executing applications, a communication interface NFCT without contact or near field NFC connected to an antenna circuit AC1 and a communication interface RCT for exchanging information by the intermediary networks, such as mobile phone networks, wireless networks, and the Internet.
  • the PRC processor is connected to the LM memory and the NFCT and RCT circuits.
  • the terminal SP1 may also comprise a secure circuit SE such as a SIM card (Subscriber Identity Module) connected to the processor BBP.
  • SIM card Subscriber Identity Module
  • the terminal SP1 can be for example a mobile phone called "smart" (smartphone).
  • the tag TG comprises a PRC processor, a secure memory SM and an antenna circuit AC2.
  • the terminal SP1 can communicate with the server BSRV for example via the Internet and for example by means of a dedicated application installed in the terminal SP1.
  • the terminal SP1 may be an NFC reader connected to the BSRV server.
  • the tag TG is linked to the object OB in such a way that the tag TG can to be easily detached from the object without damaging it.
  • a PCA identifier of the tag TG and / or of the object OB is registered in a database PDB accessible to the server BSRV, in association with information relating to the object OB such as a description of the object, its date and place of manufacture, a photograph of the object, etc.
  • a certificate of authenticity of the object OB can also be written in a secure memory of the tag TG and can also be stored in the database UDB.
  • step S1 the terminal SP1 establishes a communication with the tag TG and sends it a request for identifier CARQ making it possible to obtain a PCA identifier of the object OB.
  • the PCA identifier may be the certificate of authenticity of the object or an excerpt from this certificate.
  • the tag TG transmits the required PCA identifier.
  • step S3 the terminal SP1 establishes a communication with the server BSRV.
  • the dedicated application installed in the terminal SP1 may have a URL address to access the BSRV server.
  • the terminal SP1 transmits to the BSRV server the PCA identifier, and UID identification information relating to the owner of the OB object, and which may have been previously introduced in the terminal SP1.
  • the credentials may include the name, surname, address, and phone number of the owner.
  • step S4 the BSRV server receives this information and generates cryptographic data EID based on the PCA identifier and UID identification information, and transmits the EID data to the terminal SP1.
  • the cryptographic data EID is for example generated by encrypting the identification information UID of the owner of the object OB and possibly the identifier PCA using a symmetric encryption algorithm and a secret key known only to the server. BSRV and TG label.
  • the cryptographic data EID can also be generated, for example, by encrypting the identification information UID and possibly the identifier PCA, using a public key of the label TG and a symmetric encryption algorithm.
  • the cryptographic data EID may also comprise an electronic signature generated for example with a private key known only to the server BSRV, the corresponding public key being stored by the tag TG.
  • the BSRV server can also store in the PDB database the UID identification information of the owner of the object in association with the PCA identifier of the OB object.
  • the BSRV server transmits the cryptographic data EID to the terminal SP1.
  • the terminal SP1 receives the cryptographic data EID and transmits it to the tag TG.
  • the tag TG receives the cryptographic data EID, and decrypts the cryptographic data EID using the secret key or a private key corresponding to the public key used by the server BSRV.
  • the tag TG also verifies, if necessary, the electronic signature using the public key of the server BSRV read in its memory. If the EID data can be decrypted, and if applicable, if the signature is authentic, the TG label stores the UID credentials resulting from the decryption in its secure memory. Information identifying the owner of the object OB is thus stored securely in the tag TG.
  • the purpose of generating the cryptographic data is to allow the recording of information in the secure memory of the tag TG only if the information comes from an authorized entity, namely the BSRV server.
  • This measure to secure the registration of the UID of the owner in the TG tag may not be necessary, knowing that the correspondence between the owner data stored in the TG tag and those stored by the BSRV server in the PDB database can be verified.
  • the PDB database also stores the information relating to the owner of the object.
  • the decrypted data can be systematically recorded in the secure memory, knowing that if the encryption key used is incorrect, the result of the decryption will not provide the UID credentials.
  • the steps S4 to S7 can also be executed during a first sale of the OB object, for example in the store where the object is purchased, or before the shipment of the object at a distance sale. or by the buyer using his mobile phone in which the dedicated application is installed.
  • FIG. 3 represents steps S10 to S21 of a procedure P2 executed during the resale of the object OB.
  • the terminal SP1 transmits to the BSRV server at the request of the user of the terminal, an RSRQ request for identification for resale of the object.
  • the RSRQ request contains the PCA identifier of the OB object that can be extracted from the certificate of authenticity of the OB object, stored in the TG tag, or the certificate.
  • the PCA identifier can be obtained by executing steps S1 and S2.
  • the BSRV server receives the RSRQ request and generates a PC access code to the relative information of the object, and possibly DLF cryptographic data for erasing the UID identification information of the owner of the device.
  • the cryptographic data DLF may consist of so as to contain no information relating to the owner of the object OB and to be able to be registered in the secure memory of the tag TG instead of the identification information UID.
  • the cryptographic data DLF can be generated in the same way as the data EID, but without containing UID identification information.
  • the BSRV server responds to the RSRQ request by transmitting to the terminal SP1 the access code PC to the information relating to the object OB, and the cryptographic data DLF.
  • the PC access code may be a URL (Uniform Resource Locator) for accessing information about the object OB, stored in the database PDB.
  • the steps S10 to S12 may be preceded by a step of connecting the terminal SP1 to the server BSRV requiring the introduction of a valid identifier and a password. In this way, only the owner of the object, previously registered with the BSRV server can obtain the PC access code, and thus, engage the sale of the OB object.
  • step S13 the owner of the OB object decides to resell the OB object, for example by publishing a small advertisement on a website hosted by an RP server.
  • the PC access code may be included in the sales announcement to allow anyone who knows this code to query the BSRV server for information about the OB object.
  • the PC access code can also be included in the advertisement in the form of a hypertext link allowing access to the BSRV server and obtaining the information relating to the OB object stored in the PDB database.
  • step S14 a person consults the advertisement on the RP server using an SP2 terminal, and obtains the PC access code.
  • the terminal SP2 can be for example a smart mobile phone or a personal computer connected to the Internet network.
  • step S15 the terminal SP2 accesses the server BSRV to transmit a verification request authenticity VFRQ containing the access code PC.
  • step S16 the BSRV server tests the PC access code and executes step S17 only if this code is valid.
  • step S17 the BSRV server responds to the terminal SP2 by providing PINF information relating to the object, stored in the PDB database, and corresponding to the PC access code. On the basis of this information, the user of the terminal SP2 can appreciate the authenticity of the object OB and if the information indicated in the advertisement agrees with the PINF information obtained in step S17.
  • step S18 the user of the terminal SP2 decides to acquire the object OB and conducts a purchase transaction TRA with the server RP or directly with the owner of the object OB.
  • step S19 the owner of the OB object is informed of the conclusion of a valid purchase transaction.
  • the terminal SP1 can receive TINF information relating to the purchase transaction.
  • step S20 the terminal SP1 proceeds on request of the owner of the object OB to erase the identification information UID in the memory of the label TG.
  • the terminal SP1 transmits to the tag TG the cryptographic data DLF which has been stored by the terminal SP1 in the step S12.
  • step S21 the tag TG receives the DLF and processes it in the same manner as the cryptographic data EID, which has the effect of erasing the UID information in the secure memory of the tag TG.
  • the owner can then return the OB object to the buyer.
  • the buyer can then record identification information concerning him in the tag TG of the object OB by installing the dedicated application in his terminal SP2 and activating it to execute the steps S1 to S7.
  • the BSRV server can register the buyer's UID identification information, in association with the PCA identifier of the OB object.
  • the identifier UID can be read on request as the PCA identifier in steps S1, S2.
  • the authenticity of the object OB, as well as the identity of the owner of the object OB can thus be verified directly, without accessing the database PDB via the server BSRV.
  • steps S20, S21 can be omitted, if step S7 has the effect of overwriting any UID identification data of the owner, previously stored in the secure memory of the label TG.
  • the acquisition transaction can be performed without going through a server such as the server RP, directly between the owner of the object and the buyer.
  • the execution of steps S13 and S14 to S19 can be omitted.
  • the buyer can, however, verify the authenticity of the OB object by reading the TG label directly, and possibly by transmitting the PCA identifier of the object, thus obtained to the BSRV server using the dedicated application. Thanks to these provisions, the seller of the OB object can make recognize the authenticity of the object OB and thus recognize the value of the latter. The buyer of the object OB can be assured of the authenticity of the object before deciding to buy the object.
  • the buyer of the object OB can also be referenced with the server BSRV and thus can benefit from any services reserved for owners of objects referenced in the database PDB.
  • the manufacturer of the object can offer its customers the ability to easily sell their object at a fair price.
  • the maker of the object can also track changes in the owner of the object, and thus offer the seller to buy new items, and include the buyer in a list of customers.
  • the owner of the object OB can signal to the BSRV server the theft of the object, and the server BSRV can detect the appearance of a stolen object using the requests received in steps S3, S10 and S15.
  • the RP server of the classifieds site remains completely independent of the manufacturer of the OB object, and has no adaptation to perform in its classifieds service, while enjoying the opportunity to offer classified ads for the sale of objects whose value is related to the authenticity of objects.
  • the TG label verifies the authenticity of the OB object and that it is in the hands of the owner or a person authorized by the latter, without access to the BSRV server.
  • This possibility is offered to any person and in particular a control body (customs police), equipped with a telephone or a reader having a contactless or near-field interface.
  • the tag TG can memorize other information relating to the owner of the OB object, such as information enabling the identity of the owner to be established (civil status information, biometric data, etc.). Additional information may also be obtained from the BSRV server from the PCA identifier of the TG tag.
  • FIG. 4 represents steps of a procedure P3 executed according to another embodiment, following the acquisition of the object OB associated with the identification electronic tag TG, comprising an NFC chip or RFID chip.
  • the procedure P3 differs from the procedure P1 in that it comprises additional steps S31, S41.
  • Step S31 is executed by the BSRV server between steps S3 and S4.
  • the step S31 executed consists in verifying that the label TG is in an update state in the database PDB, the server BSRV having been informed by the owner of the object of the continuation of the sale of this last.
  • the following steps S4, S41 and S5 to S7 are executed only if the BSRV server is informed of the sale of the object.
  • Step S41 is executed by the BSRV server between steps S4 and S5.
  • step S41 the server BSRV can update the database PDB so as to delete the update state of the tag TG.
  • the tag TG can receive a new owner identifier in step S7, only if the owner of the object has informed the BSRV server of the sale of the object.
  • the updating of the tag TG performed in step S7 can be performed only once, as long as the owner of the object has not informed the BSRV server of a new setting. sale of the OB object.
  • FIG. 5 represents steps of a procedure P4 executed during the sale and resale of the object OB, according to another embodiment.
  • the procedure P4 differs from the procedure P2 in that it comprises an additional step S51 executed between the steps S1 1 and S12.
  • Step S51 consists for the server BSRV to record in the PDB database that the label TG is in update mode, following the sale of the object OB as declared by the transmission of the RSRQ request at step S10. Activation of this mode is tested in step S31.
  • the OB object can thus be associated in the PDB database to a state that can take the following values: unassigned owner, owner assigned, for sale, stolen.
  • FIG. 6 represents steps of a procedure P5 executed according to another embodiment, following the acquisition of the object OB associated with the electronic identification tag TG, comprising an NFC or RFID chip.
  • the procedure P3 differs from the procedure P1 in that it comprises additional steps S32 and S33 and in that the step S3 is modified.
  • Step S32 is executed before step S1 or S3 to condition the execution of step S7 to a prior identification of the owner of the OB object.
  • the owner In step S32, the owner must enter on his terminal SP1 during the execution of the dedicated application a user ID and a password UC or a secret code SC.
  • the secret code SC may have been transmitted by the seller of the object OB when the latter is acquired by the owner of the object OB.
  • Step S33 is executed between steps S3 and S4.
  • step S3 the terminal SP1 also transmits to the BSRV server the UC or SC data.
  • step S33 the BSRV server verifies the PCA identifier, the identifier and the password UC, and that the object corresponding to the identifier PCA is associated in the database PDB with the identifier and the password UC or secret code SC.
  • the execution of steps S4 to S7 is performed only if the owner identified by the UC or SC data corresponds to the identifier of the OB object.
  • the updating of the UID of the owner of the object OB in the tag TG and in the database PDB is only possible if the owner has been identified as such by the server BSRV. Therefore, this update is not possible without the knowledge of the owner of the object, especially if the object was stolen.
  • FIG. 7 represents steps of a procedure P6 executed during the sale and resale of the object OB, according to another embodiment.
  • the procedure P6 differs from the procedure P2 in that the steps S1 1, S12 and S17 are modified.
  • the server BSRV generates the secret code SC used in the procedure P5 and updates the database PBD to store this secret code in association with the data relating to the object OB.
  • the secret code SC is also transmitted to the terminal SP1 and displayed on the latter to inform the owner of the object OB.
  • the BSRV server transmits to the potential buyer's terminal SP2 UID identification information of the owner of the object with the PIN information relating to the object OB. This information is displayed on the SP2 terminal.
  • the potential buyer can thus verify that the UID identification information received corresponds to the person who published the small advertisement for the sale of the OB object published by the server RP and is indeed the owner of the object OB. In this way, it is avoided that the PC access code can be used fraudulently by another person, and therefore the sales transaction is conducted in step S18 with someone other than the owner of the object.
  • the procedure P6 may also comprise an additional step S22 executed following the step S19, when the owner of the object OB is informed of the transaction.
  • the terminal SP1 transmits to the terminal SP2 the secret code SC authorizing the updating of the label TG to introduce the identification information of the buyer of the OB object.
  • the buyer of the object OB can thus be registered as the owner of the object OB in the label TG and in the database PDB, by executing the procedure P5 on its terminal SP2 after installation in the latter of the application dedicated.
  • the secret code SC can be transmitted between the two terminals SP1, SP2 for example by SMS (Short Message Service) after introduction into the terminal SP1 of the telephone number of the terminal SP2, or by electronic message after introduction into the terminal SP1 of an email address of the buyer.
  • SMS Short Message Service
  • the acquisition transaction can be performed without going through a server such as the server RP, but directly between the owner of the object and the buyer.
  • the buyer can verify the authenticity of the OB object and the seller is the owner of the object by reading the TG label directly. Additional information can then be obtained by accessing the BSRV server and using the PCA identifier of the OB object.
  • the present invention is capable of various alternative embodiments and various applications.
  • the invention is not limited to the embodiments described above, but also covers any combination of these embodiments.
  • the BSRV server it is not necessary for the BSRV server to generate the PC code to access the object information stored by the server.
  • this code can be replaced by the PCA identifier read in the tag TG, and which is also stored in the database PDB by the server.
  • the owner of the object can therefore sell the object without informing the BSRV server.
  • the owner of the object informs the server of the sale of the object (by executing steps S10 to S12).
  • the update mode of the label can be activated (S51) and / or the secret code SC can be generated (S1 1 - procedure P6) only when the server is informed of the sale of the object .

Abstract

L'invention concerne un procédé pour sécuriser la vente d'un objet, comprenant des étapes consistant à : mémoriser un identifiant (PCA) d'un objet (OB) et un identifiant (UID) de propriétaire de l'objet, par un serveur (BSRV) et dans une mémoire sécurisée d'une étiquette électronique (TG) liée à l'objet, transmettre l'identifiant de l'objet, depuis l'étiquette électronique vers un terminal (SP1), fournir par le serveur des informations (PINF) relatives à l'objet (OB) en réponse à une requête désignant l'objet, transmettre au serveur une requête de mise à jour de l'identifiant de propriétaire, contenant des informations relatives à un nouveau propriétaire de l'objet, mémoriser par le serveur les informations relatives au nouveau propriétaire en relation avec l'identifiant de l'objet, générer par le serveur une requête d'écriture (EID) contenant un identifiant (UID) du nouveau propriétaire, transmettre la requête d'écriture à l'étiquette électronique, et mémoriser dans l'étiquette électronique l'identifiant du nouveau propriétaire reçu dans la requête d'écriture. Fig.1

Description

PROCEDE POUR SECURISER LA REVENTE D'UN OBJET EQUIPE
D'UNE ETIQUETTE NFC
La présente invention concerne la vente et la revente d'objets ayant une valeur marchande élevée, notamment des objets de luxe ou des œuvres art. La présente invention s'applique notamment à la vente en ligne de tels objets.
De nombreux sites Internet proposent des services de petites annonces permettant aux utilisateurs d'offrir des objets à la revente. Cependant, lors de la consultation de telles annonces, il n'est généralement pas possible de s'assurer de l'authenticité d'un objet ainsi mis en vente, ni que la personne ayant publié l'annonce de mise en vente est bien propriétaire de l'objet ou même dispose réellement de l'objet.
Certains objets peuvent bénéficier d'un certificat d'authenticité sous forme d'un imprimé. Cependant, un tel certificat d'authenticité n'est pas directement accessible par le site, et donc l'authenticité d'un tel certificat peut difficilement être établie. Les acheteurs potentiels ne sont donc pas incités à acheter un objet dont la valeur est essentiellement liée à son authenticité.
Certains sites de revente en ligne proposent d'assurer un service de contrôle de l'authenticité des objets mis en vente. Cependant, une commission généralement relativement élevée est exigée en contrepartie, et la confiance susceptible d'être attribuée à un tel service peut être limitée. Les vendeurs potentiels ne sont donc guère incités à utiliser un tel service.
En outre, de nombreux objets volés transitent notamment d'un pays à l'autre. Il peut être souhaitable de permettre la vérification qu'un objet se trouve bien sous la garde de son propriétaire ou d'une personne autorisée par le propriétaire. Seuls les objets volés de grande valeur sont répertoriés dans des listes et peuvent ainsi faire l'objet d'une vérification. Cependant, pour s'assurer qu'un objet particulier n'est pas répertorié en tant qu'objet volé, il est nécessaire de disposer d'un accès à des listes d'objets volés. Or un tel accès n'est pas toujours possible, et il peut ne pas être aisé de faire le lien entre un objet et sa description dans une liste d'objets volés.
Par ailleurs, il est connu d'associer à un objet une étiquette électronique telle qu'une étiquette RFID (Radio Frequency IDentification) ou NFC (Near Field Communication), permettant d'identifier l'objet et éventuellement de mémoriser d'autres informations sur l'objet telles que son origine, et sa date de fabrication.
Il peut être donc souhaitable de permettre à un acheteur potentiel de s'assurer de l'authenticité d'un objet offert à la vente, et de s'assurer que la personne à l'origine de l'offre en vente soit réellement le propriétaire de l'objet. Il peut être également souhaitable que le propriétaire d'un objet puisse donner à une autre personne la possibilité de s'assurer elle-même à distance de l'authenticité de l'objet. Il peut être également souhaitable de pouvoir contrôler immédiatement, et sans avoir à se connecter à un serveur distant, qu'un objet se trouve bien sous la garde de son propriétaire ou d'une personne habilitée par le propriétaire.
Des modes de réalisation concernent un procédé pour sécuriser la vente d'un objet, comprenant des étapes consistant à : mémoriser un identifiant d'un objet et un identifiant de propriétaire de l'objet, par un serveur et dans une mémoire sécurisée d'une étiquette électronique liée à l'objet, transmettre l'identifiant de l'objet, depuis l'étiquette électronique vers un terminal par une liaison sans contact ou à champ proche, fournir par le serveur des informations relatives à l'objet en réponse à une requête désignant l'objet, transmettre au serveur une requête de mise à jour de l'identifiant de propriétaire, contenant des informations relatives à un nouveau propriétaire de l'objet, mémoriser par le serveur les informations relatives au nouveau propriétaire en relation avec l'identifiant de l'objet, générer par le serveur une requête d'écriture contenant un identifiant du nouveau propriétaire transmettre la requête d'écriture à l'étiquette électronique par la liaison sans contact ou à champ proche, et mémoriser dans l'étiquette électronique l'identifiant du nouveau propriétaire reçu dans la requête d'écriture.
Selon un mode de réalisation, le procédé comprend des étapes consistant à : fournir par le serveur un code d'accès en réponse à une requête contenant l'identifiant de l'objet, et fournir les informations relatives à l'objet par le serveur en réponse à une requête contenant le code d'accès.
Selon un mode de réalisation, le procédé comprend une étape de fourniture par le serveur en réponse à la requête contenant le code d'accès, d'informations relatives au propriétaire de l'objet. Selon un mode de réalisation, le procédé comprend une étape de fourniture par l'étiquette électronique en réponse à une requête de lecture, des informations relatives à l'objet, et éventuellement, des informations relatives au propriétaire de l'objet.
Selon un mode de réalisation, la requête d'écriture générée par le serveur indique de manière sécurisée le serveur en tant qu'émetteur de la requête, l'identifiant du nouveau propriétaire, reçu dans la requête d'écriture, étant mémorisé, et de manière sécurisée, dans l'étiquette électronique, seulement si l'émetteur de la requête est le serveur.
Selon un mode de réalisation, le procédé comprend des étapes consistant à : sélectionner par le serveur une clé de chiffrement en fonction de l'identifiant d'objet reçu, générer par le serveur à l'aide de la clé de chiffrement une donnée cryptographique contenant sous forme chiffrée l'identifiant du propriétaire, reçu du terminal, transmettre la donnée cryptographique à l'étiquette électronique, déchiffrer la donnée cryptographique par l'étiquette électronique à l'aide d'une clé de déchiffrement correspondant à la clé de chiffrement, pour obtenir l'identifiant du propriétaire, et mémoriser de manière sécurisée dans l'étiquette électronique l'identifiant du propriétaire.
Selon un mode de réalisation, les clés de chiffrement et de déchiffrement sont identiques et correspondent à une clé secrète, l'identifiant du propriétaire étant chiffré à l'aide d'un algorithme de chiffrement symétrique, ou bien la clé de chiffrement est une clé publique, et la clé de déchiffrement est une clé privée correspondant à la clé publique, l'identifiant du propriétaire étant chiffré à l'aide d'un algorithme de chiffrement asymétrique, la donnée cryptographique comprenant une signature électronique émise par le serveur, le procédé comprenant une étape de vérification par l'étiquette électronique que la signature a été émise par le serveur.
Selon un mode de réalisation, la mémorisation par le serveur des informations relatives au propriétaire et l'émission par le serveur de la requête d'écriture sont effectuées seulement si le propriétaire est identifié comme tel par le serveur.
Selon un mode de réalisation, le propriétaire est identifié comme tel par le serveur grâce à la fourniture au serveur par le propriétaire d'un code secret généré par le serveur et remis au propriétaire par un vendeur de l'objet, ou durant une période pendant laquelle le serveur autorise la mise à jour de l'identifiant de propriétaire dans l'étiquette électronique.
Des modes de réalisation concernent également un système de transaction pour la vente d'un objet, comprenant : un serveur accessible par un réseau de transmission de données, une étiquette électronique liée à un objet, et un terminal comprenant des interfaces de communication pour établir une communication sans contact ou à champ proche avec l'étiquette électronique et pour établir une communication avec le serveur, l'étiquette électronique étant configurée pour : mémoriser un identifiant de l'objet dans une mémoire sécurisée de l'étiquette électronique, émettre l'identifiant de l'objet, recevoir une requête d'écriture contenant un identifiant du propriétaire de l'objet, et mémoriser dans la mémoire sécurisée l'identifiant du propriétaire reçu dans la requête d'écriture, le serveur étant configuré pour : recevoir et mémoriser des informations relatives au propriétaire de l'objet, en relation avec des informations relatives à l'objet, fournir des informations relatives à l'objet en réponse à une requête désignant l'objet, et générer et émettre la requête d'écriture contenant un identifiant du propriétaire, le terminal étant configuré pour : lire les informations relatives à l'objet et au propriétaire de l'objet mémorisés dans l'étiquette électronique, transmettre au serveur une requête de mise à jour des informations d'identification du propriétaire dans l'étiquette électronique, et transmettre à l'étiquette électronique la requête d'écriture émise par le serveur.
Selon un mode de réalisation, le serveur est configuré pour : fournir un code d'accès en réponse à une requête contenant l'identifiant de l'objet, et fournir en réponse à une requête contenant le code d'accès, les informations relatives à l'objet, et éventuellement, les informations relatives au propriétaire de l'objet.
Selon un mode de réalisation, l'étiquette électronique est configurée pour fournir en réponse à une requête de lecture, des informations mémorisées par l'étiquette électronique relatives à l'objet, et éventuellement, relatives au propriétaire de l'objet.
Selon un mode de réalisation, le serveur est configuré pour mémoriser des informations relatives au propriétaire et émettre l'identifiant du propriétaire à destination de l'étiquette électronique seulement si le propriétaire est identifié comme tel par le serveur.
Selon un mode de réalisation, le serveur est configuré pour générer un code secret à remettre à un vendeur de l'objet, et pour identifier comme propriétaire de l'objet une personne lui fournissant le code secret.
Selon un mode de réalisation, le serveur est configuré pour identifier comme propriétaire de l'objet une personne lui fournissant des informations d'identification durant une période pendant laquelle le serveur autorise la mise à jour de l'identifiant de propriétaire dans l'étiquette électronique.
Des exemples de réalisation de l'invention seront décrits dans ce qui suit, à titre non limitatif en relation avec les figures jointes parmi lesquelles : la figure 1 représente schématiquement des étapes d'une procédure d'enregistrement d'informations relatives au propriétaire d'un objet équipé d'une étiquette électronique, selon un mode de réalisation,
la figure 2 représente schématiquement une étiquette électronique et un terminal équipé d'une interface de communication avec l'étiquette électronique,
la figure 3 représente schématiquement des étapes d'une procédure de mise en vente et de vente d'un objet équipé d'une étiquette électronique, selon un mode de réalisation,
la figure 4 représente des étapes d'une procédure d'enregistrement d'informations relatives au propriétaire d'un objet équipé d'une étiquette électronique, selon un autre mode de réalisation,
la figure 5 représente schématiquement des étapes d'une procédure de mise en vente et de vente d'un objet équipé d'une étiquette électronique, selon un autre mode de réalisation,
la figure 6 représente des étapes d'une procédure d'enregistrement d'informations relatives au propriétaire d'un objet équipé d'une étiquette électronique, selon un autre mode de réalisation,
la figure 7 représente schématiquement des étapes d'une procédure de mise en vente et de vente d'un objet équipé d'une étiquette électronique, selon un autre mode de réalisation.
La figure 1 représente des étapes S1 à S7 d'une procédure P1 exécutée selon un mode de réalisation, à la suite de l'acquisition d'un objet OB associé à une étiquette électronique d'identification TG, comportant une puce sans contact RFID ou à champ proche NFC. La procédure P1 peut être exécutée à partir d'un terminal de communication SP1 configuré pour communiquer avec l'étiquette électronique TG de type RFID ou NFC et avec un serveur distant BSRV en relation avec un fabricant de l'objet OB.
La figure 2 représente un exemple de terminal SP1 et d'étiquette électronique TG. Le terminal SP1 comprend un processeur BBP et une mémoire LM, pour exécuter des applications, une interface de communication NFCT sans contact ou à champ proche NFC connectée à un circuit d'antenne AC1 et une interface de communication RCT pour échanger des informations par l'intermédiaire de réseaux, tels que des réseaux de téléphonie mobile, des réseaux sans fil, et le réseau Internet. Le processeur PRC est connecté à la mémoire LM et aux circuits NFCT et RCT. Le terminal SP1 peut également comprendre un circuit sécurisé SE tel qu'une carte SIM (Subscriber Identity Module) relié au processeur BBP. Le terminal SP1 peut être par exemple un téléphone mobile dit "intelligent" (smartphone). L'étiquette TG comprend un processeur PRC, une mémoire sécurisée SM et un circuit d'antenne AC2.
Le terminal SP1 peut communiquer avec le serveur BSRV par exemple par l'intermédiaire du réseau Internet et par exemple au moyen d'une application dédiée, installée dans le terminal SP1 . Alternativement, le terminal SP1 peut être un lecteur NFC relié au serveur BSRV. A la suite ou durant la fabrication de l'objet OB, ou bien à la suite d'une authentification de l'objet OB, l'étiquette TG est liée à l'objet OB d'une manière telle que l'étiquette TG puisse être difficilement détachée de l'objet sans endommager ce dernier. Un identifiant PCA de l'étiquette TG et/ou de l'objet OB est inscrit dans une base de données PDB accessible au serveur BSRV, en association avec des informations relatives à l'objet OB telles qu'une description de l'objet, sa date et son lieu de fabrication, une photographie de l'objet, etc. Un certificat d'authenticité de l'objet OB peut également être inscrit dans une mémoire sécurisée de l'étiquette TG et peut être mémorisé également dans la base de données UDB.
A l'étape S1 , le terminal SP1 établit une communication avec l'étiquette TG et lui transmet une requête d'identifiant CARQ permettant d'obtenir un identifiant PCA de l'objet OB. L'identifiant PCA peut être le certificat d'authenticité de l'objet ou un extrait de ce certificat. A l'étape S2, l'étiquette TG transmet l'identifiant PCA requis. A l'étape S3, le terminal SP1 établit une communication avec le serveur BSRV. A cet effet, l'application dédiée installée dans le terminal SP1 peut disposer d'une adresse URL permettant d'accéder au serveur BSRV. Le terminal SP1 transmet ensuite au serveur BSRV l'identifiant PCA, et des informations d'identification UID relatives au propriétaire de l'objet OB, et qui ont pu être préalablement introduites dans le terminal SP1 . Les informations d'identification peuvent comprendre le nom, le prénom, l'adresse et le numéro de téléphone du propriétaire.
A l'étape S4, le serveur BSRV reçoit ces informations et génère une donnée cryptographique EID sur la base de l'identifiant PCA et des informations d'identification UID, et transmet la donnée EID au terminal SP1 . La donnée cryptographique EID est par exemple générée en chiffrant les informations d'identification UID du propriétaire de l'objet OB et éventuellement l'identifiant PCA à l'aide d'un algorithme de chiffrement symétrique et d'une clé secrète connue seulement du serveur BSRV et de l'étiquette TG. La donnée cryptographique EID peut être aussi par exemple générée en chiffrant les informations d'identification UID et éventuellement l'identifiant PCA, à l'aide d'une clé publique de l'étiquette TG et d'un algorithme de chiffrement symétrique. La donnée cryptographique EID peut également comprendre une signature électronique générée par exemple avec une clé privée connue seulement du serveur BSRV, la clé publique correspondante étant mémorisée par l'étiquette TG. A l'étape S4, le serveur BSRV peut également mémoriser dans la base de données PDB les informations d'identification UID du propriétaire de l'objet en association avec l'identifiant PCA de l'objet OB. A l'étape S5, le serveur BSRV transmet la donnée cryptographique EID au terminal SP1 . A l'étape S6, le terminal SP1 reçoit la donnée cryptographique EID et la transmet à l'étiquette TG. A l'étape S7, l'étiquette TG reçoit la donnée cryptographique EID, et déchiffre la donnée cryptographique EID à l'aide de la clé secrète ou d'une clé privée correspondant à la clé publique utilisée par le serveur BSRV. L'étiquette TG vérifie également, le cas échéant, la signature électronique à l'aide de la clé publique du serveur BSRV lue dans sa mémoire. Si la donnée EID peut être déchiffrée, et le cas échéant, si la signature est authentique, l'étiquette TG mémorise les informations d'identification UID résultant du déchiffrement dans sa mémoire sécurisée. Des informations identifiant le propriétaire de l'objet OB sont ainsi mémorisées de manière sécurisée dans l'étiquette TG.
A noter que la génération de la donnée cryptographique a pour but de permettre de n'autoriser l'enregistrement d'informations dans la mémoire sécurisée de l'étiquette TG seulement si les informations proviennent d'une entité habilitée, à savoir le serveur BSRV. Cette mesure pour sécuriser l'enregistrement de l'identifiant UID du propriétaire dans l'étiquette TG peut ne pas être nécessaire, sachant que la concordance entre les données relatives au propriétaire mémorisées dans l'étiquette TG et celles mémorisées par le serveur BSRV dans la base de données PDB peut être vérifiée. En effet, la base de données PDB mémorise également les informations relatives au propriétaire de l'objet..
A noter également que dans le cas de l'utilisation d'un algorithme de chiffrement symétrique, la donnée déchiffrée peut être systématiquement inscrite dans la mémoire sécurisée, sachant que si la clé de chiffrement utilisée est incorrecte, le résultat du déchiffrement ne fournira pas les informations d'identification UID.
Les étapes S4 à S7 peuvent être exécutées également lors d'une première vente de l'objet OB, par exemple dans le magasin où l'objet est acheté, ou bien avant l'expédition de l'objet lors d'une vente à distance, ou bien par l'acheteur à l'aide de son téléphone mobile dans lequel est installé l'application dédiée.
La figure 3 représente des étapes S10 à S21 d'une procédure P2 exécutée lors de la revente de l'objet OB. A l'étape S10, le terminal SP1 transmet au serveur BSRV sur demande de l'utilisateur du terminal, une requête RSRQ d'identification en vue de la revente de l'objet. La requête RSRQ contient l'identifiant PCA de l'objet OB qui peut être extrait du certificat d'authenticité de l'objet OB, mémorisé dans l'étiquette TG, ou le certificat. L'identifiant PCA peut être obtenu en exécutant les étapes S1 et S2. A l'étape S1 1 , le serveur BSRV reçoit la requête RSRQ et génère un code d'accès PC aux informations relatives de l'objet, et éventuellement une donnée cryptographique DLF permettant d'effacer les informations d'identification UID du propriétaire de l'objet OB dans la mémoire sécurisée de l'étiquette TG. La donnée cryptographique DLF peut être constituée de manière à ne contenir aucune information relative au propriétaire de l'objet OB et à pouvoir être inscrite dans la mémoire sécurisée de l'étiquette TG à la place des informations d'identification UID. A cet effet, la donnée cryptographique DLF peut être générée de la même façon que la donnée EID, mais sans contenir d'informations d'identification UID. A l'étape S12, le serveur BSRV répond à la requête RSRQ en transmettant au terminal SP1 le code d'accès PC aux informations relatives à l'objet OB, et la donnée cryptographique DLF. A noter que le code d'accès PC peut être une adresse URL (Uniform Resource Locator) permettant d'accéder à des informations concernant l'objet OB, mémorisées dans la base de données PDB. Les étapes S10 à S12 peuvent être précédées d'une étape de connexion du terminal SP1 au serveur BSRV nécessitant l'introduction d'un identifiant et d'un mot de passe valides. De cette manière, seul le propriétaire de l'objet, préalablement enregistré auprès du serveur BSRV peut obtenir le code d'accès PC, et ainsi, engager la mise en vente de l'objet OB.
A l'étape S13, le propriétaire de l'objet OB décide de revendre l'objet OB, par exemple en publiant une petite annonce sur un site Internet hébergé par un serveur RP. Le code d'accès PC peut figurer dans l'annonce de vente pour permettre à toute personne connaissant ce code d'interroger le serveur BSRV pour obtenir des informations concernant l'objet OB. Le code d'accès PC peut également figurer dans l'annonce sous la forme d'un lien hypertexte permettant d'accéder au serveur BSRV et obtenir les informations relatives à l'objet OB mémorisées dans la base de données PDB. A l'étape S14, une personne consulte l'annonce sur le serveur RP à l'aide d'un terminal SP2, et obtient le code d'accès PC. Le terminal SP2 peut être par exemple un téléphone mobile intelligent ou un ordinateur personnel connecté au réseau Internet. A l'étape S15, le terminal SP2 accède au serveur BSRV pour lui transmettre une requête de vérification d'authenticité VFRQ contenant le code d'accès PC. A l'étape S16, le serveur BSRV teste le code d'accès PC et exécute l'étape S17 seulement si ce code est valide. A l'étape S17, le serveur BSRV répond au terminal SP2 en lui fournissant les informations PINF relatives à l'objet, mémorisées dans la base de données PDB, et correspondant au code d'accès PC. Sur la base de ces informations, l'utilisateur du terminal SP2 peut apprécier l'authenticité de l'objet OB et si les informations indiquées dans la petite annonce concordent avec les informations PINF obtenues à l'étape S17. A l'étape S18, l'utilisateur du terminal SP2 décide d'acquérir l'objet OB et conduit une transaction d'achat TRA avec le serveur RP ou directement avec le propriétaire de l'objet OB. A l'étape S19, le propriétaire de l'objet OB est informé de la conclusion d'une transaction d'achat valide. A cet effet, le terminal SP1 peut recevoir des informations TINF relatives à la transaction d'achat. A l'étape S20, le terminal SP1 procède sur demande du propriétaire de l'objet OB à l'effacement des informations d'identification UID dans la mémoire de l'étiquette TG. A cet effet, le terminal SP1 transmet à l'étiquette TG la donnée cryptographique DLF qui a été mémorisée par le terminal SP1 à l'étape S12. A l'étape S21 , l'étiquette TG reçoit la donnée DLF et la traite de la même manière que la donnée cryptographique EID, ce qui a pour effet d'effacer les informations UID dans la mémoire sécurisée de l'étiquette TG. Le propriétaire peut ensuite remettre l'objet OB à l'acheteur. L'acheteur peut alors enregistrer des informations d'identification le concernant dans l'étiquette TG de l'objet OB en installant l'application dédiée dans son terminal SP2 et en l'activant pour exécuter les étapes S1 à S7. A l'étape S4, le serveur BSRV peut enregistrer les informations d'identification UID de l'acheteur, en association avec l'identifiant PCA de l'objet OB. L'identifiant UID peut être lu sur requête comme l'identifiant PCA aux étapes S1 , S2. L'authenticité de l'objet OB, ainsi que l'identité du propriétaire de l'objet OB peuvent ainsi être vérifiées directement, sans accéder à la base de données PDB par l'intermédiaire du serveur BSRV.
Il est à noter que les étapes S20, S21 peuvent être omises, si l'étape S7 a pour effet d'écraser les éventuelles données d'identification UID du propriétaire, précédemment mémorisées dans la mémoire sécurisée de l'étiquette TG.
Bien entendu, la transaction d'acquisition peut être effectuée sans passer par un serveur tel que le serveur RP, directement entre le propriétaire de l'objet et l'acheteur. Dans ce cas, l'exécution des étapes S13 et S14 à S19 peut être omise. L'acheteur peut toutefois vérifier l'authenticité de l'objet OB en lisant directement l'étiquette TG, et éventuellement en transmettant l'identifiant PCA de l'objet, ainsi obtenu au serveur BSRV à l'aide de l'application dédiée. Grâce à ces dispositions, le vendeur de l'objet OB peut faire reconnaître l'authenticité de l'objet OB et ainsi faire reconnaître la valeur de ce dernier. L'acheteur de l'objet OB peut être assuré de l'authenticité de l'objet avant de décider d'acheter l'objet. L'acheteur de l'objet OB peut également être référencé auprès du serveur BSRV et ainsi peut bénéficier d'éventuels services réservés aux propriétaires d'objets référencés dans la base de données PDB. A l'aide du simple serveur BSRV et d'une application dédiée, adaptée aux téléphones équipés d'une interface NFC, le fabricant de l'objet peut offrir à ses clients la possibilité de vendre facilement leur objet à un juste prix. Le fabricant de l'objet peut également suivre les changements de propriétaire de l'objet, et ainsi proposer au vendeur d'acheter de nouveaux objets, et inclure l'acheteur dans une liste de clients. Le propriétaire de l'objet OB peut signaler au serveur BSRV le vol de l'objet, et le serveur BSRV peut détecter l'apparition d'un objet volé à l'aide des requêtes reçues aux étapes S3, S10 et S15. Le serveur RP du site de petites annonces reste complètement indépendant du fabricant de l'objet OB, et n'a aucune adaptation à effectuer dans son service de petites annonces, tout en bénéficiant de la possibilité de proposer des petites annonces pour la vente d'objets dont la valeur est liée à l'authenticité des objets.
Par ailleurs, l'étiquette TG permet de vérifier l'authenticité de l'objet OB et que celui-ci est entre les mains du propriétaire ou d'une personne habilitée par ce dernier, sans avoir accès au serveur BSRV. Cette possibilité est offerte à toute personne et notamment un organisme de contrôle (douane police), équipé d'un téléphone ou d'un lecteur ayant une interface sans contact ou à champ proche. A cet effet, l'étiquette TG peut mémoriser d'autres informations relatives au propriétaire de l'objet OB, comme des informations permettant d'établir l'identité du propriétaire (informations d'état civil, biométriques, etc.). Des informations complémentaires peuvent être également obtenues auprès du serveur BSRV à partir de l'identifiant PCA de l'étiquette TG.
La figure 4 représente des étapes d'une procédure P3 exécutée selon un autre mode de réalisation, à la suite de l'acquisition de l'objet OB associé à l'étiquette électronique d'identification TG, comportant une puce NFC ou RFID. La procédure P3 diffère de la procédure P1 en ce qu'elle comprend des étapes supplémentaires S31 , S41 . L'étape S31 est exécutée par le serveur BSRV entre les étapes S3 et S4. L'étape S31 exécutée consiste à vérifier que l'étiquette TG est dans un état de mise à jour dans la base de données PDB, le serveur BSRV ayant été informé par le propriétaire de l'objet de la suite de la mise en vente de ce dernier. Les étapes suivantes S4, S41 et S5 à S7 ne sont exécutées que si le serveur BSRV est informé de la mise en vente de l'objet. L'étape S41 est exécutée par le serveur BSRV entre les étapes S4 et S5. A l'étape S41 , le serveur BSRV peut mettre à jour la base de données PDB de manière à supprimer l'état de mise à jour de l'étiquette TG. De cette manière, l'étiquette TG peut recevoir un nouvel identifiant de propriétaire à l'étape S7, que si le propriétaire de l'objet a informé le serveur BSRV de la mise en vente de l'objet. En outre, la mise à jour de l'étiquette TG effectuée à l'étape S7 ne peut être effectuée qu'une seule fois, tant que le propriétaire de l'objet n'a pas informé le serveur BSRV d'une nouvelle mise en vente de l'objet OB.
La figure 5 représente des étapes d'une procédure P4 exécutée lors de la mise en vente et revente de l'objet OB, selon un autre mode de réalisation. La procédure P4 diffère de la procédure P2 en ce qu'elle comprend une étape supplémentaire S51 exécutée entre les étapes S1 1 et S12. L'étape S51 consiste pour le serveur BSRV à enregistrer dans la base de données PDB que l'étiquette TG est en mode de mise à jour, à la suite de la mise en vente de l'objet OB telle que déclarée par la transmission de la requête RSRQ à l'étape S10. L'activation de ce mode est testée à l'étape S31 . L'objet OB peut ainsi être associé dans la base de données PDB à un état pouvant prendre les valeurs suivantes : propriétaire non attribué, propriétaire attribué, en vente, volé.
La figure 6 représente des étapes d'une procédure P5 exécutée selon un autre mode de réalisation, à la suite de l'acquisition de l'objet OB associé à l'étiquette électronique d'identification TG, comportant une puce NFC ou RFID. La procédure P3 diffère de la procédure P1 en ce qu'elle comprend des étapes supplémentaires S32 et S33 et en ce que l'étape S3 est modifiée. L'étape S32 est exécutée avant l'étape S1 ou S3 pour conditionner l'exécution de l'étape S7 à une identification préalable du propriétaire de l'objet OB. A l'étape S32, le propriétaire doit introduire sur son terminal SP1 lors de l'exécution de l'application dédiée un identifiant et un mot de passe UC ou bien un code secret SC. Le code secret SC peut avoir été transmis par le vendeur de l'objet OB lors de l'acquisition de ce dernier par le propriétaire de l'objet OB. L'étape S33 est exécutée entre les étapes S3 et S4. A l'étape S3, le terminal SP1 transmet également au serveur BSRV les données UC ou SC. A l'étape S33, le serveur BSRV vérifie l'identifiant PCA, l'identifiant et le mot de passe UC, et que l'objet correspondant à l'identifiant PCA est associé dans la base de données PDB à l'identifiant et au mot de passe UC ou au code secret SC. L'exécution des étapes S4 à S7 n'est effectuée que si le propriétaire identifié par les données UC ou SC correspond bien à l'identifiant de l'objet OB. Ainsi, la mise à jour de l'identifiant UID du propriétaire de l'objet OB dans l'étiquette TG et dans la base de données PDB n'est possible que si le propriétaire a été identifié comme tel par le serveur BSRV. Par conséquent, cette mise à jour n'est pas possible à l'insu du propriétaire de l'objet, notamment si l'objet a été volé.
La figure 7 représente des étapes d'une procédure P6 exécutée lors de la mise en vente et revente de l'objet OB, selon un autre mode de réalisation. La procédure P6 diffère de la procédure P2 en ce que les étapes S1 1 , S12 et S17 sont modifiées. A l'étape S1 1 , le serveur BSRV génère le code secret SC utilisé dans la procédure P5 et met à jour la base de données PBD pour y mémoriser ce code secret en association avec les données relatives à l'objet OB. A l'étape S12, le code secret SC est également transmis au terminal SP1 et affiché sur ce dernier pour en informer le propriétaire de l'objet OB. A l'étape S17, le serveur BSRV transmet au terminal SP2 de l'acheteur potentiel des informations d'identification UID du propriétaire de l'objet avec les informations PINF relatives à l'objet OB. Ces informations sont affichées sur le terminal SP2. L'acheteur potentiel peut ainsi vérifier que les informations d'identification UID reçues correspondent à la personne à l'origine de la publication de la petite annonce de vente de l'objet OB publiée par le serveur RP et est bien propriétaire de l'objet OB. De cette manière, on évite que le code d'accès PC puisse être utilisé frauduleusement par une autre personne, et donc que la transaction de vente soit conduite à l'étape S18 avec une autre personne que le propriétaire de l'objet.
La procédure P6 peut comprendre également une étape supplémentaire S22 exécutée à la suite de l'étape S19, lorsque le propriétaire de l'objet OB est informé de la transaction. A l'étape S22, le terminal SP1 transmet au terminal SP2 le code secret SC autorisant la mise à jour de l'étiquette TG pour y introduire les informations d'identification de l'acheteur de l'objet OB. L'acheteur de l'objet OB peut ainsi être enregistré comme propriétaire de l'objet OB dans l'étiquette TG et dans la base de données PDB, en exécutant la procédure P5 sur son terminal SP2 après installation dans ce dernier de l'application dédiée. Le code secret SC peut être transmis entre les deux terminaux SP1 , SP2 par exemple par SMS (Short Message Service) après introduction dans le terminal SP1 du numéro de téléphone du terminal SP2, ou encore par message électronique après introduction dans le terminal SP1 d'une adresse de messagerie électronique de l'acheteur.
Comme précédemment, la transaction d'acquisition peut être effectuée sans passer par un serveur tel que le serveur RP, mais directement entre le propriétaire de l'objet et l'acheteur. L'acheteur peut vérifier l'authenticité de l'objet OB et que le vendeur est bien le propriétaire de l'objet en lisant directement l'étiquette TG. Des informations complémentaires peuvent ensuite être obtenues en accédant au serveur BSRV et en utilisant l'identifiant PCA de l'objet OB.
Il apparaîtra clairement à l'homme de l'art que la présente invention est susceptible de diverses variantes de réalisation et diverses applications. En particulier, l'invention n'est pas limitée aux modes de réalisation précédemment décrits, mais couvre également toute combinaison de ces modes de réalisation. Par ailleurs, il n'est pas nécessaire que le serveur BSRV génère le code PC pour accéder aux informations concernant l'objet mémorisées par le serveur. En effet, ce code peut être remplacé par l'identifiant PCA lu dans l'étiquette TG, et qui est également mémorisé dans la base de données PDB par le serveur. Le propriétaire de l'objet peut donc mettre en vente l'objet sans en informer le serveur BSRV. Pour la sécurité de la mise à jour de l'étiquette TG avec un nouvel identifiant de propriétaire, il importe simplement que le propriétaire de l'objet informe le serveur de la vente de l'objet (en exécutant les étapes S10 à S12). Il en résulte que le mode de mise à jour de l'étiquette peut être activé (S51 ) et/ou le code secret SC peut être généré (S1 1 - procédure P6) seulement lorsque le serveur est informé de la vente de l'objet.

Claims

REVENDICATIONS
1 . Procédé pour sécuriser la vente d'un objet, comprenant des étapes consistant à :
mémoriser un identifiant (PCA) d'un objet (OB) et un identifiant (UID) de propriétaire de l'objet, par un serveur (BSRV) et dans une mémoire sécurisée d'une étiquette électronique (TG) liée à l'objet,
transmettre l'identifiant de l'objet, depuis l'étiquette électronique vers un terminal (SP1 ) par une liaison sans contact ou à champ proche,
fournir par le serveur des informations (PINF) relatives à l'objet (OB) en réponse à une requête (VFRQ) désignant l'objet,
transmettre au serveur une requête de mise à jour de l'identifiant de propriétaire, contenant des informations relatives à un nouveau propriétaire de l'objet,
mémoriser par le serveur les informations relatives au nouveau propriétaire en relation avec l'identifiant de l'objet,
générer par le serveur une requête d'écriture (EID) contenant un identifiant (UID) du nouveau propriétaire
transmettre la requête d'écriture à l'étiquette électronique par la liaison sans contact ou à champ proche, et
mémoriser dans l'étiquette électronique l'identifiant du nouveau propriétaire reçu dans la requête d'écriture.
2. Procédé selon la revendication 1 , comprenant des étapes consistant à :
fournir par le serveur (BSRV) un code d'accès (PC) en réponse à une requête (RSRQ) contenant l'identifiant de l'objet (PCA), et
fournir les informations (PINF) relatives à l'objet (OB) par le serveur en réponse à une requête (VFRQ) contenant le code d'accès.
3. Procédé selon la revendication 2, comprenant une étape de fourniture par le serveur (BSRV) en réponse à la requête (VFRQ) contenant le code d'accès (PC), d'informations (UID) relatives au propriétaire de l'objet (OB).
4. Procédé selon l'une des revendications 1 à 3, comprenant une étape de fourniture par l'étiquette électronique (TG) en réponse à une requête de lecture (CARQ), des informations (PCA) relatives à l'objet (OB), et éventuellement, des informations (UID) relatives au propriétaire de l'objet.
5. Procédé selon l'une des revendications 1 à 4, dans lequel la requête d'écriture (EID) générée par le serveur (BSRV) indique de manière sécurisée le serveur en tant qu'émetteur de la requête, l'identifiant (UID) du nouveau propriétaire, reçu dans la requête d'écriture, étant mémorisé, et de manière sécurisée, dans l'étiquette électronique (TG), seulement si l'émetteur de la requête est le serveur.
6. Procédé selon l'une des revendications 1 à 5, comprenant des étapes consistant à :
sélectionner par le serveur (BSRV) une clé de chiffrement en fonction de l'identifiant d'objet (PCA) reçu,
générer par le serveur à l'aide de la clé de chiffrement une donnée cryptographique (EID) contenant sous forme chiffrée l'identifiant du propriétaire (UID), reçu du terminal (PS1 ),
transmettre la donnée cryptographique à l'étiquette électronique (TG), déchiffrer la donnée cryptographique par l'étiquette électronique à l'aide d'une clé de déchiffrement correspondant à la clé de chiffrement, pour obtenir l'identifiant du propriétaire, et
mémoriser de manière sécurisée dans l'étiquette électronique l'identifiant du propriétaire.
7. Procédé selon la revendication 6, dans lequel :
les clés de chiffrement et de déchiffrement sont identiques et correspondent à une clé secrète, l'identifiant du propriétaire (UID) étant chiffré à l'aide d'un algorithme de chiffrement symétrique, ou
la clé de chiffrement est une clé publique, et la clé de déchiffrement est une clé privée correspondant à la clé publique, l'identifiant du propriétaire étant chiffré à l'aide d'un algorithme de chiffrement asymétrique, la donnée cryptographique (EID) comprenant une signature électronique émise par le serveur (BSRV), le procédé comprenant une étape de vérification par l'étiquette électronique que la signature a été émise par le serveur.
8. Procédé selon l'une des revendications 1 à 7, dans lequel la mémorisation par le serveur (BSRV) des informations (UID) relatives au propriétaire et l'émission par le serveur de la requête d'écriture (EID) sont effectuées seulement si le propriétaire est identifié comme tel par le serveur.
9. Procédé selon la revendication 8, dans lequel le propriétaire est identifié comme tel par le serveur (BSRV) grâce à la fourniture au serveur par le propriétaire d'un code secret (SC) généré par le serveur et remis au propriétaire par un vendeur de l'objet, ou durant une période pendant laquelle le serveur autorise la mise à jour de l'identifiant (UID) de propriétaire dans l'étiquette électronique (TG).
10. Système de transaction pour la vente d'un objet, comprenant : un serveur (BSRV) accessible par un réseau de transmission de données,
une étiquette électronique (TG) liée à un objet (OB), et
un terminal (PS1 ) comprenant des interfaces de communication pour établir une communication sans contact ou à champ proche avec l'étiquette électronique et pour établir une communication avec le serveur, l'étiquette électronique étant configurée pour :
mémoriser un identifiant (PCA) de l'objet dans une mémoire sécurisée de l'étiquette électronique,
émettre l'identifiant de l'objet,
recevoir une requête d'écriture (EID) contenant un identifiant (UID) du propriétaire de l'objet, et
mémoriser dans la mémoire sécurisée l'identifiant du propriétaire reçu dans la requête d'écriture, le serveur étant configuré pour :
recevoir et mémoriser des informations relatives au propriétaire de l'objet, en relation avec des informations relatives à l'objet,
fournir des informations (PINF) relatives à l'objet (OB) en réponse à une requête (VFRQ) désignant l'objet, et générer et émettre la requête d'écriture contenant un identifiant du propriétaire, le terminal étant configuré pour :
lire les informations relatives à l'objet et au propriétaire de l'objet mémorisés dans l'étiquette électronique,
transmettre au serveur une requête de mise à jour des informations d'identification du propriétaire dans l'étiquette électronique, et
transmettre à l'étiquette électronique la requête d'écriture émise par le serveur.
1 1 . Système selon la revendication 10, dans lequel le serveur est configuré pour :
fournir un code d'accès (PC) en réponse à une requête contenant l'identifiant (PCA) de l'objet (OB), et
fournir en réponse à une requête (VFRQ) contenant le code d'accès, les informations (PINF) relatives à l'objet, et éventuellement, les informations (UID) relatives au propriétaire de l'objet.
12. Système selon la revendication 10 ou 1 1 , dans lequel l'étiquette électronique (TG) est configurée pour fournir en réponse à une requête de lecture (CARQ), des informations (PCA, UID) mémorisées par l'étiquette électronique relatives à l'objet (OB), et éventuellement, relatives au propriétaire de l'objet.
13. Système selon l'une des revendications 10 à 12, dans lequel le serveur (BSRV) est configuré pour mémoriser des informations relatives au propriétaire et émettre l'identifiant (UID) du propriétaire à destination de l'étiquette électronique (TG) seulement si le propriétaire est identifié comme tel par le serveur.
14. Système selon l'une des revendications 10 à 13, dans lequel le serveur (BSRV) est configuré pour générer un code secret (SC) à remettre à un vendeur de l'objet (OB), et pour identifier comme propriétaire de l'objet une personne lui fournissant le code secret.
15. Système selon l'une des revendications 10 à 14, dans lequel le serveur (BSRV) est configuré pour identifier comme propriétaire de l'objet (OB) une personne lui fournissant des informations d'identification (UID) durant une période pendant laquelle le serveur autorise la mise à jour de l'identifiant (UID) de propriétaire dans l'étiquette électronique (TG).
EP15732811.3A 2014-06-02 2015-05-27 Procédé pour sécuriser la revente d'un objet équipé d'une étiquette nfc Withdrawn EP3149684A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1454962A FR3021785B1 (fr) 2014-06-02 2014-06-02 Procede pour securiser la revente d’un objet equipe d’une etiquette nfc
PCT/FR2015/051398 WO2015185825A1 (fr) 2014-06-02 2015-05-27 Procédé pour sécuriser la revente d'un objet équipé d'une étiquette nfc

Publications (1)

Publication Number Publication Date
EP3149684A1 true EP3149684A1 (fr) 2017-04-05

Family

ID=51610233

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15732811.3A Withdrawn EP3149684A1 (fr) 2014-06-02 2015-05-27 Procédé pour sécuriser la revente d'un objet équipé d'une étiquette nfc

Country Status (4)

Country Link
US (1) US20170200154A1 (fr)
EP (1) EP3149684A1 (fr)
FR (1) FR3021785B1 (fr)
WO (1) WO2015185825A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10204347B2 (en) * 2015-08-11 2019-02-12 Mehmet Ertugrul Authenticity control system
US10356154B2 (en) * 2016-01-04 2019-07-16 Google Llc Systems and methods for allocating communication resources via information technology infrastructure
FR3113749A1 (fr) * 2020-08-31 2022-03-04 Pivicar Système pour l’identification et le suivi du propriétaire d’un produit de luxe.
WO2024072611A1 (fr) * 2022-09-26 2024-04-04 Brandon Cook Plateforme de provenance instantanée

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110191590A1 (en) * 2008-07-28 2011-08-04 Wisekey S.A. Method and apparatus for digital authentication of valuable goods

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010034663A1 (en) * 2000-02-23 2001-10-25 Eugene Teveler Electronic contract broker and contract market maker infrastructure
US7225167B2 (en) * 2003-11-21 2007-05-29 International Business Machines Corporation Merchandise-integral transaction receipt and auditable product ownership trail
GB0404155D0 (en) * 2004-02-25 2004-03-31 Scott Track Ltd Turnout/crossover section for railway track
US7366806B2 (en) * 2004-07-27 2008-04-29 Intel Corporation Method and apparatus for RFID tag wherein memory of RFID tag is partitioned into two sections for reading using wireless interface and writing using bus
US20060117011A1 (en) * 2004-12-01 2006-06-01 Swiftifind Ltd. Database for ownership and authenticity validation, systems including same and methods of use thereof
US8242911B2 (en) * 2006-12-11 2012-08-14 Tego Inc. Composite multiple RFID tag facility
US20150074397A1 (en) * 2012-03-13 2015-03-12 Cognilore Inc. Method of distributing digital publications incorporating user generated and encrypted content with unique fingerprints
WO2015012417A1 (fr) * 2013-07-25 2015-01-29 Gruppo Potente Ltd Dispositif et procédé de surveillance de véhicules
WO2015070055A2 (fr) * 2013-11-08 2015-05-14 Vattaca, LLC Authentification et gestion de propriété et d'authenticité d'article

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110191590A1 (en) * 2008-07-28 2011-08-04 Wisekey S.A. Method and apparatus for digital authentication of valuable goods

Non-Patent Citations (10)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS ET AL: "Découvrez Selinko on Vimeo", 3 July 2013 (2013-07-03), XP055665551, Retrieved from the Internet <URL:https://vimeo.com/69617572> [retrieved on 20200205] *
ANONYMOUS: "One-time password - Wikipedia", 23 July 2012 (2012-07-23), XP055472625, Retrieved from the Internet <URL:https://en.wikipedia.org/w/index.php?title=One-time_password&oldid=503836787> [retrieved on 20180504] *
CLAIRE SWEDBERG: "Château Le Pin Uses NFC to Ensure Its Wine's Authenticity", RFID JOURNAL, 17 July 2013 (2013-07-17), pages 1 - 3, XP055593412, Retrieved from the Internet <URL:https://www.rfidjournal.com/articles/pdf?10834> [retrieved on 20190603] *
FESTRAETS GWEN: "Appli mobile Selinko pour l'identification de produits de luxe on Vimeo", 25 June 2013 (2013-06-25), pages 1 - 2, XP055665598, Retrieved from the Internet <URL:https://vimeo.com/69072216> [retrieved on 20200205] *
GWEN FESTRAETS ET AL: "Selinko mobile app to identify Wines & Spirits on Vimeo", 21 June 2013 (2013-06-21), pages 1 - 3, XP055593466, Retrieved from the Internet <URL:https://vimeo.com/68844177> [retrieved on 20190603] *
GWEN FESTRAETS: "Transcript of the video: "Découvrez Selinko"", 3 July 2013 (2013-07-03), pages 1, XP055665652, Retrieved from the Internet <URL:https://vimeo.com/69617572> [retrieved on 20200206] *
GWEN FESTRAETS: "Transcript of the video: "Selinko mobile app to identify Wines & Spirits"", 21 June 2013 (2013-06-21), pages 1, XP055665656, Retrieved from the Internet <URL:https://vimeo.com/68844177> [retrieved on 20200206] *
HERVÉ: "CapSeal scelle les bouchons des bouteilles des grands crus en NFC", 28 May 2014 (2014-05-28), pages 1 - 22, XP055665802, Retrieved from the Internet <URL:https://www.abavala.com/capseal-scelle-les-bouchons-bouteilles-grands-crus-en-nfc/#> [retrieved on 20200206] *
NAI-WEI LO ET AL: "Ownership transfer protocol for RFID objects using lightweight computing operators", INTERNET TECHNOLOGY AND SECURED TRANSACTIONS (ICITST), 2011 INTERNATIONAL CONFERENCE FOR, IEEE, 11 December 2011 (2011-12-11), pages 484 - 489, XP032113205, ISBN: 978-1-4577-0884-8 *
See also references of WO2015185825A1 *

Also Published As

Publication number Publication date
FR3021785A1 (fr) 2015-12-04
FR3021785B1 (fr) 2016-06-24
WO2015185825A1 (fr) 2015-12-10
US20170200154A1 (en) 2017-07-13

Similar Documents

Publication Publication Date Title
CA2745595C (fr) Procede d&#39;execution d&#39;une application securisee dans un dispositif nfc
CN108713307B (zh) 使用机载系统认证交易中用户的方法、设备和系统
US7548889B2 (en) Payment information security for multi-merchant purchasing environment for downloadable products
US8099365B2 (en) Extended data collection for multi-merchant purchasing environment for downloadable products
US20170206532A1 (en) System and method for streamlined registration and management of products over a communication network related thereto
US20090307778A1 (en) Mobile User Identify And Risk/Fraud Model Service
EP2801052B1 (fr) Procédé d&#39;éxecution d&#39;une application dans un dispositif nfc
US20140258110A1 (en) Methods and arrangements for smartphone payments and transactions
RU2546549C2 (ru) Способы, сервер, устройство-получатель платежей, компьютерные программы и компьютерные программные продукты для установления связи
US20060167812A1 (en) Communication mechanisms for multi-merchant purchasing environment for downloadable products
EP2453398A1 (fr) Système d&#39;authentification de produit
US20060167809A1 (en) Software assistant for multi-merchant purchasing environment for downloadable products
EP3149684A1 (fr) Procédé pour sécuriser la revente d&#39;un objet équipé d&#39;une étiquette nfc
US20210295280A1 (en) Technique for providing optimized digital information
EP1393272B1 (fr) Proc d et dispositif de certification d&#39;une transaction
US20190188730A1 (en) Authentication of goods
EP2369780B1 (fr) Procédé et système de validation d&#39;une transaction, terminal transactionnel et programme correspondants.
US20070168295A1 (en) Verification method for personal credit purchases
EP2927857A1 (fr) Méthode de vérification d&#39;authenticité d&#39;un terminal, dispositif et programme correspondant
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d&#39;ordinateur correspondant
WO2017005644A1 (fr) Procédé et système de contrôle d&#39;accès à un service via un média mobile sans intermediaire de confiance
BE1019350A3 (fr) Usage d&#39;une carte d&#39;identite electronique en tant que carte d&#39;affiliation.
CN117455506A (zh) 一种基于rfid技术的珠宝管理方法及系统
WO2023126498A1 (fr) Système et procédé de suivi d&#39;actifs
FR3101991A1 (fr) Système et méthode d&#39;authentification et d&#39;assurance d’objets

Legal Events

Date Code Title Description
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

17P Request for examination filed

Effective date: 20161207

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)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: WISEKEY SEMICONDUCTORS

17Q First examination report despatched

Effective date: 20180523

RIN1 Information on inventor provided before grant (corrected)

Inventor name: JANATI IDRISSI, SAAD

Inventor name: DUBREUCQ, MIKAEL

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

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20200720