[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

EP1908215A1 - Procédé de contrôle de transactions sécurisées mettant en oeuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système et programme d'ordinateur correspondants - Google Patents

Procédé de contrôle de transactions sécurisées mettant en oeuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système et programme d'ordinateur correspondants

Info

Publication number
EP1908215A1
EP1908215A1 EP06777839A EP06777839A EP1908215A1 EP 1908215 A1 EP1908215 A1 EP 1908215A1 EP 06777839 A EP06777839 A EP 06777839A EP 06777839 A EP06777839 A EP 06777839A EP 1908215 A1 EP1908215 A1 EP 1908215A1
Authority
EP
European Patent Office
Prior art keywords
key
certificate
physical device
public
certification
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
EP06777839A
Other languages
German (de)
English (en)
Inventor
David Arditti
Sidonie Caron
Laurent Frisch
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.)
Orange SA
Original Assignee
France Telecom 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 France Telecom SA filed Critical France Telecom SA
Publication of EP1908215A1 publication Critical patent/EP1908215A1/fr
Withdrawn legal-status Critical Current

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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the field of the invention is that of securing electronic transactions, in particular implementing authentication, electronic signature and payment operations, carried out through communication networks such as the Internet for example.
  • the invention relates to a technique for controlling secure transactions involving a physical device owned by a user, and which can be used to carry out transactions with several providers or suppliers of distinct goods or services.
  • a certificate makes it possible in particular to verify the validity of a public cryptographic key used on a computer network, and is a message comprising, at a minimum, a public key, an identifier of its holder, a period of validity, an identification of a certification authority, as well as a cryptographic signature of these various data, produced by means of the secret key of this certification authority issuing the certificate.
  • Reading the certificate makes it possible to authenticate with certainty the sender of a message received in the case of the signature and the identifier of the one who authenticates in the case of authentication.
  • X.509 standard and more particularly X.509v3 defined in RFC3280 (Request For Comment No. 3280) published by the IETF (Internet Engineering Task Force).
  • the certificates Ci issued by a certification authority then link the different public keys Pi to the identifiers Idi, as well as to any other information.
  • n triples Pi, Si, Ci
  • Idi a public key
  • Ci a private key
  • the client When he then wants to carry out a secure transaction with the i th provider, the client signs a hazard sent by the provider (we then speak of authentication) or a message (we then speak of electronic signature) using his secret key If and by associating with it the corresponding certificate Ci provided by the certification authority (which can, if necessary, be the service provider itself), according to standardized protocols.
  • a disadvantage of the prior art technique cited above is that it does not allow a certification authority or a service provider to simply and remotely ensure that the certificate Ci which it issues or that it uses certifies a public key Pi corresponding to a private key Si stored in a given physical device.
  • the behavior of a physical device can be completely simulated by software, so that at a distance, it is impossible for the service provider to know if it corresponds to a physical device or indeed to a software emulation of a such device.
  • this physical device is the support of a paid subscription to a service provided by the provider (for for example, Internet access to newspaper articles published in a daily newspaper). Access to the paid service is conditioned for the user by opening a session with the service provider, during which he authenticates himself by means of his physical device.
  • a paid subscription to a service provided by the provider for for example, Internet access to newspaper articles published in a daily newspaper.
  • the service provider it is therefore particularly important for the service provider to ensure that the customer who wishes to access the service is indeed in possession of the physical device, in order to avoid that several people can access (simultaneously or not) the service, by paying a single subscription. , which would be the case if the subscription medium could be cloned (for example if the subscription medium was a set "username / password" or a private key (even encrypted) stored on a hard disk) .
  • devices are made available to users.
  • physical cards such as smart cards or USB “dongles”("Universal Serial Bus” for “universal serial bus”), which are conventionally associated with a pair of asymmetric keys (P 0 , S 0 ) comprising a private key S 0 and a public key P 0 .
  • the private key S 0 is an electronic element which must remain secret, and which is therefore stored in a protected space of the physical device, protected from any attempted intrusion.
  • the public key P 0 can be stored for free reading in the physical device, or be delivered to the user on an external medium, such as a floppy disk, CD-Rom, paper document, or a reserved space a data server.
  • This pair of keys (S 0 , P 0 ) is created in the factory, before the device is marketed and put into service.
  • Such a physical device also conventionally comprises calculation means making it possible to implement an asymmetric cryptographic algorithm for authentication and / or signature.
  • RSA Raster-Shamir-Adleman
  • DSA DSA
  • GQ Guardou-Quisquater
  • GPS GPS type algorithms
  • this asymmetric cryptographic algorithm may be subject to the prior presentation of a carrier code (or PESf code for "Personal Identification Number") initialized during a phase of (pre) personalization of the physical device, and managed according to conventional techniques, which are not the subject of the present patent application.
  • a carrier code or PESf code for "Personal Identification Number”
  • the physical device can then be sold in this form to a user, by a means of distribution independent of any service provider.
  • the user of the physical device also called a client, must have a C 1 certificate binding the public key issued by the service provider, or by an independent certification authority.
  • P 0 of the device and an identifier Id 1 relevant for the service provider (note: in systems where the anonymity of the user vis-à-vis the service provider must be preserved, the identifier Id 1 is different from the civil identity user).
  • This operation can be carried out with n separate service providers, so that the client is assigned n certificates ⁇ C l5 C2, ..., C n ⁇ binding n identifiers (Id 1 , Id 2 , ..., Id n J (each of them being relevant for a given service provider) to said public key P 0 .
  • the only method allowing a service provider or a certification authority to ensure that the transaction in progress is carried out using a given physical device is based on the physical manipulation of the device by the service provider or the certification authority. Indeed, it can then read itself the public key P 0 or Pi in the device, in the case where it is stored there; otherwise, he can have the device sign a hazard, using the secret key S 0 or Si, and then verify the result of this signature using the public key P 0 or Pi supplied by the client on a medium external.
  • the invention particularly aims to overcome these drawbacks of the prior art.
  • an objective of the invention is to provide a technique for controlling secure transactions implementing a physical device associated with several pairs of asymmetric keys and capable of being used to conclude transactions with several distinct providers, making it possible to s '' ensure that a transaction is carried out using a physical device given, while guaranteeing non-traceability of the user by all or part of the service providers.
  • Another objective of the invention is to propose such a technique which is simple to implement and introduces little additional complexity into the physical devices used and very few modifications in the software and server of service providers or certification authorities.
  • Another object of the invention is to provide such a technique which is reliable and makes it possible to obtain a strong non-repudiation property, so as to create, for the provider, an environment of trust.
  • the invention also aims to propose such a technique which makes it possible, if necessary, to ensure the traceability of the client by one or more certification authorities.
  • the invention is based on a completely new and inventive approach to securing electronic transactions carried out by means of a physical device of the USB "dongle" type, chip card, etc., for which it is desired to ensure the non - user traceability.
  • the technique of the invention is based: on the one hand, on the use of several pairs of asymmetric keys of the device, each pair being associated with a distinct identifier of the client, and making it possible to ensure its non-traceability to with regard to the various service providers with which it comes into contact; and secondly on the intervention, to introduce an additional degree of security, of a particular certification authority (ACP), to which the various certification third parties and the various service providers place all their trust.
  • ACP certification authority
  • This particular certification authority issues, prior to the commissioning of the physical device (USB dongle, smart card, etc.), a certificate relating to this physical device (and not, as in the prior art, a certificate relating to an identifier of its holder), which makes it possible to verify that the first public key P 0 of the physical device indeed corresponds to a first private key S 0 stored, in accordance with good practice, in a secret zone of the device.
  • the ACP therefore certifies the physical device.
  • a provisional certificate C'i produced (generally by the device itself) using the secret key S 0 whose corresponding public key P 0 is certified by the ACP, makes it possible to guarantee that a second public key Pi of the physical device corresponds to a second device private key If also stored, in accordance with good practice, in a secret and inviolable zone of the device.
  • This public device key Pi is the one used by the client to carry out a transaction with an i th provider.
  • the verification of the validity of the device certificate Ci and the examination of the ⁇ info> field is a guarantee, for the provider, that it is, even remotely, in the presence of a real physical device, and not equipment (computer, PDA, etc.) which fraudulently reproduces its behavior.
  • a chain of trust is thus built up, between a service provider who places his trust in a trusted third party verifying the factory and provisional certificates, and who himself trusts the particular certification authority issuing the factory certificate C 0 .
  • the transaction control method according to the invention uses the commitment of the ACP to assure a provider that a customer who wishes to initiate a secure transaction has a device physical, which has been certified by the CPA.
  • the control techniques according to the prior art only ensure the identification of a user, if necessary using a chain of authentications and certifications based on the use of a succession of authorities.
  • the method according to the invention comprises, in addition to certifying the identity of the user, the prior certification of the physical device subsequently owned by this user. This ensures a provider, possibly remotely, that the user who authenticates with him has a physical device. Only this assurance allows the establishment of the transaction control process to continue.
  • the generation, on the fly, by the physical device, of other pairs of asymmetric keys corresponding to a need to establish a secure transaction between a provider and a user ensures the non-repudiation of the keys generated, because the use of the secret key S 0 to certify this pair of keys. Indeed, S 0 cannot be substituted by another key due to the certification by the ACP of P 0 , the certificates which result from the signature by S 0 of the pairs of asymmetric keys cannot be repudiated.
  • such a control method is implemented for at least two second pairs of asymmetric keys of said device, each associated with an identifier (Idi) of said user, and each of said device certificates (Ci) issued during said issuing steps. one of said second public device keys (Pi) to said associated identifier (Idi).
  • the physical device can thus be used during transactions with several providers, with each of whom the user is identified by a separate Idi identifier.
  • said characteristic information of said physical device belongs to the group comprising the following information:
  • said provider consults said information ( ⁇ info>) characteristic of said device certificate (Ci).
  • such a control method comprises a phase of personalization of said physical device, during which said first pair of asymmetric keys, said factory certificate (C 0 ), and said information ( ⁇ info>) of said factory certificate uniquely to said physical device, so as to reduce the risks of fraudulent transactions.
  • This personalization phase can be done for example in the factory, before marketing the device.
  • said factory certificate (C 0 ) and provisional certificate (C'i) are stored in at least one memory area in free reading of said physical device. They are thus easily accessible for the service provider or the trusted third party.
  • At least one of said first and second verification steps is carried out by said service provider.
  • said first certification key (S T ) is a private key and said second certification key (P ⁇ ) is a public key.
  • said particular certification authority uses a symmetric key (K), so that said first certification key (S T ) and said second certification key (P ⁇ ) are identical.
  • the invention also relates to a physical device owned by a user and intended to be used during secure transactions, said physical device carrying at least a first pair of asymmetric keys, comprising a first public device key (P 0 ) and a first key. private device (S 0 ) corresponding.
  • P 0 public device key
  • S 0 private device
  • such a device also carries a factory certificate (C 0 ), issued after verification that said private device key S 0 is housed in an inviolable zone of said physical device), corresponding to the signature of said first device key.
  • said factory certificate (C 0 ) is stored in said physical device before it is put into service.
  • the invention also relates to a computer program product downloadable from a communication network and / or stored on a computer-readable medium and / or executable by a microprocessor, which comprises program code instructions for the implementation of at least one step of the secure transaction control method as described above.
  • the invention also relates to a system for controlling secure transactions on a communication network, implementing a physical device owned by a user and carrying at least a first pair of asymmetric keys, comprising a first public device key (P 0 ). and a corresponding first private device key (S 0 ).
  • such a control system comprises at least: a particular certification server connected to said network, delivering to said physical device, after verification that said private device key S 0 is housed in an inviolable zone of said physical device and prior to its commissioning, a factory certificate (C 0 ) corresponding to the signature of said first public device key (P 0 ) and information ( ⁇ info>) characteristic of the physical device by a first certification key (S T ) of said particular certification server (ACP); a trusted third party (44) verifying said factory certificate (C 0 ) by means of a second certification key (P ⁇ ) corresponding to said first certification key (S T ), and a provisional certificate (Ci) stored in said physical device, corresponding to the signature of a second public device key (Pi) by said first private device key (S 0 ), by means of said first public device key (P 0 ), and delivering to said user, in in the case of positive verification, a device certificate (Ci) corresponding to the signature by said trusted third party
  • FIG. 1 illustrates the principle of the certification, by a particular certification authority, of the public key of a physical device, during a phase of personalization of the device
  • FIG. 2 shows the principle of creating a second pair of asymmetric keys (Pi, Si), as well as a provisional certificate Ci in a physical device
  • FIG. 3 illustrates a block diagram of the different steps implemented in the method for controlling secure transactions of the invention
  • FIG. 4 describes the different exchanges between a user and different servers of the invention, via a communication network, within the framework of the method of FIG. 3. 7. Description of an embodiment of the invention
  • the general principle of the invention is based on the certification of the public keys P 0 and Pi of a physical device, making it possible to guarantee to a provider, during a secure transaction (possibly remotely), that he is dealing well with real physical device, in which the corresponding private keys S 0 and Si are stored, while ensuring the non-traceability, by the service provider, of the user of this device.
  • a particular certification authority, or ACP, 10 has a pair of asymmetric keys (PT, ST) comprising a public key PT and a private key ST kept in a secret and inaccessible zone 101.
  • asymmetric keys PT, ST
  • Such an ACP 10 is for example the manufacturer of the physical device: the secret zone 101 in which the private key S T is stored is then a particular physical device (a smart card for example) owned by the manufacturer, or a protected memory zone with restricted access of one of its devices IT.
  • the public key P T is published by the ACP 10, or supplied on request to potential providers likely to need it (ie to trusted third parties likely to carry out transactions with the owner of the physical device 13) .
  • a pair of asymmetric keys (P 0 , S 0 ) is recorded therein comprising a public key P 0 , stored in a zone 131 accessible for reading from the device 13, and a private key S 0 stored in a protected area 132 of this device 13.
  • This protected or tamper-resistant area 132 is designed so as to prevent the reading of the private key S 0 and to resist any attempt at software or hardware intrusion.
  • the use of the private key S 0 by the device 13 is strongly constrained: in particular, as explained below, the device 13 cannot use this device private key S 0 to produce external data signatures.
  • the public key P 0 can also be communicated to the holder of the physical device 13 on an external medium, independent of the device itself.
  • the operations illustrated in FIG. 1 are carried out before the marketing of the physical device, in the factory, during a personalization phase. If it is a certification authority independent of the manufacturer, these operations can be carried out at the end of the production lines, before the distribution of the physical devices to the end users.
  • the physical device 13 communicates via the ACP 10 its public device key P 0 .
  • the factory certificate C 0 issued by the ACP 10 may correspond to the signature by the ACP 10 of the public key of the device P 0 and of the field ⁇ info>, which is a field grouping together a set of information characteristic of the device 13 (for example, the name of the manufacturer, the type of device, the nature of the cryptographic signature algorithms used by the device, etc.).
  • A denotes a cryptographic signature algorithm, of RSA type for example
  • the ACP thus initially certifies that the device private key S 0 is housed in a physical device 13 with characteristics given by the ⁇ info> field.
  • the ⁇ info> field can be stored in free reading in the area referenced 131 of the device 13, or on an external medium, or simply be communicated to providers or third parties of trust who might need it.
  • the ACP 10 (manufacturer or trusted third party) naturally agrees to produce such factory certificates C 0 (ie such signatures with its private key S T ) only for public keys P 0 corresponding to private keys stored in a physical device of a given type.
  • the certification operations of FIG. 1 can also, in an alternative embodiment of the invention, be shared for several manufacturers of physical devices of different types.
  • the ACP 10 is a trusted third party independent of all of the manufacturers, who holds the private key S T and who, in order to produce the factory certificate C 0 of a given physical device 13, signs with its private certification key S T , the pair (P 0 , ⁇ info>).
  • the characteristic information contained in the ⁇ info> field makes it possible, for example, to provide information on the nature of the device 13, namely a USB "dongle", a smart card, etc. It can also be the product reference used by the manufacturer to designate one of the devices it builds.
  • the factory certificate C 0 can be signed in the factory certificate C 0 , such as the name of the manufacturer ( ⁇ name of the manufacturer), the type of cryptographic algorithm used ( ⁇ algorithm type>), device serial number, etc.
  • the key K can be shared between the manufacturer of the physical device 13 and a (or a few rare) trusted third parties, whose manufacturer knows that they will keep this key K secret; in this case, only these third parties or the manufacturer himself can verify the certificate. It is also conceivable that the key K is only used by an ACP 10 independent of the manufacturer, who signs the factory certificate C 0 with symmetric key, only on request from the manufacturer of physical devices 13. Likewise, this ACP 10 will be the only one ability to verify factory certificates C 0 , at the request of providers wishing to carry out a transaction with the associated physical devices 13. Again, this ACP 10 can of course be the manufacturer itself.
  • the quadruplet (P 0 , S 0 , C 0 , ⁇ info>) can be characteristic of a given physical device 13, or be the same for all the physical devices 13 having identical characteristics described in the ⁇ info> field. In the latter case, it is not necessary to call on the ACP 10 during the personalization of the device 13, because the quadruplet (P 0 , S 0 , C 0 , ⁇ info>) consists of one and only one times for a given series of devices.
  • the physical device 13 in which the certificate C 0 has been registered by the ACP 10 is sold by a means of distribution independent of any service provider, for example in a large area or at an authorized reseller.
  • Such a recording comprises: a first operation for creating a second pair of asymmetric device keys (Pi, Si), which will be used during exchanges with the service provider n ° i; a second operation of issuing a device certificate Ci by a trusted third party.
  • the physical device 13 comprises, in a free-read memory area 1311, a first public key of the device P 0 , a factory certificate C 0 , and possibly an ⁇ info> field which has not been shown in FIG. 2. It also comprises, in a tamper-proof memory area 1321, a first secret key of device S 0 .
  • asymmetrical Pi, Si
  • this couple is created by the physical device 13 itself. Indeed, many cryptographic devices are capable of self-generating their keys, according to a technique conventionally called “on board key generation”. It is an APDU ("Application Protocol Data Unit") which triggers the key generation process (Pi, Si).
  • the public device key Pi is then housed in an area 1312 of the physical device 13 accessible for reading, and the private device key Si is housed in an inviolable area 1322, having specific access conditions. Indeed, such a tamper-evident zone 1322 is neither accessible in reading nor in writing, and only a suitable cryptographic signature algorithm can use this secret device key Si.
  • this use is subject to the correct prior presentation of a carrier code (or PIN code).
  • the key generation APDU (Pi, Si) implemented in the physical device 13 also performs an additional operation, consisting in signing the second public device key Pi with the first key deprived of device S 0 housed in the inviolable zone 1321.
  • the pair of asymmetric keys additional (Pi, Si) is created outside of the physical device 13, for example by a computer equipped with a security module.
  • a specific APDU is then implemented in the physical device 13, which makes it possible: to introduce the second private device key Si in the inviolable zone
  • Such an operation for generating a triplet can be carried out several times, to equip the physical device 13 with a plurality of such triplets, and therefore authorize the user to carry out secure transactions with several separate providers, while ensuring its non-traceability.
  • the issuance of the provisional certificate Ci must constitute the only possible use of the first device private key S 0 .
  • the first device private key S 0 can only be used to sign, within a single APDU, public keys Pi, that they have been generated by the physical device or introduced into it in the form of a pair of asymmetric keys (Pi, Si).
  • the physical device 13 has been acquired by a user 40, who wishes to use it to access the services offered by a provider 43, via a communication network 42, for example the global Internet network.
  • a provider 43 may for example be a service provider (access to a weather service, or to a geolocation service for example) or a seller of goods (merchant on the Internet for example).
  • the physical device 13 serves for example as a support for a paid subscription subscribed by the user 40 from the provider 43 (for example a subscription to a daily horoscope published on the Internet).
  • the user 40 To be able to access the services of the provider 43, the user 40 must register with a trusted third party, that is to say be issued a device certificate Ci, which contains the signature by the trusted third party 44 of the public device key Pi, of an identifier Idi of the user, as well as other information, such as the date of validity of the certificate, etc.
  • a trusted third party that is to say be issued a device certificate Ci, which contains the signature by the trusted third party 44 of the public device key Pi, of an identifier Idi of the user, as well as other information, such as the date of validity of the certificate, etc.
  • the identifier Idi can differ from the civil identity of the user. It will be noted that the problem of the correspondence between the identifier Idi and the real identity of the user is not the subject of the present invention and will therefore not be described here in more detail. For a solution to this problem, reference may be made for example to French patent document FR 04 08992 in the name of the same applicants as the present patent application.
  • the trusted third party 44 who may be the service provider 43, must have the following elements 31: the public device keys P 0 and Pi; factory certificates C 0 and provisional C'i; an identifier Idi of the user 40; characteristic information ⁇ info> of the physical device 13.
  • Trusted third party 44 must also have other information required according to the X509 standard cited above, such as the validity date of the device certificate Ci to be issued, certain information relating to the use of the different keys, etc.
  • the trusted third party performs various additional verifications in the context of the invention.
  • the trusted third party performs the verification E33 of the factory certificate C 0 , using the public key P T of the particular certification authority 10, in order to verify that the public device key P 0 which has been transmitted to the service provider 43 corresponds to a secret key S 0 stored in a physical device described by the ⁇ info> field.
  • Such an operation E33 consists in verifying that the signature of the public device key P 0 and of the ⁇ info> field contained in the factory certificate C 0 is exact.
  • the trusted third party 44 can end E36 in the transaction, and refuse to issue the device certificate Ci.
  • the trusted third party acquires the certainty that the public key P 0 corresponds to a private key S 0 housed in a physical device 13 with characteristics ⁇ info>, and can then proceed to verify E34 of the provisional certificate Ci, using the first public device key P 0 .
  • the trusted third party 44 can end E36 the exchanges with the user 40. If, on the other hand, the signature C'i of the second public key of device Pi is exact, the trusted third party 44 acquires the certainty (insofar as he trusts the ACP 10) that the public key of device Pi corresponds well to a device private key If stored on a physical device 13 whose characteristics are specified in the ⁇ info> field, and it can therefore access the request of the user 40, by issuing E35 of the device certificate Ci .
  • the trusted third party 44 delivers to the user 40 a device certificate Ci corresponding to the signature of the public device key Pi, of the identifier Idi and of information characteristic of the physical device.
  • the various verifications E33 to E34 described above in relation to FIG. 3 can be performed by the provider 43 itself or by a trusted third party 44 (AC), also connected to the network 42.
  • the provider 43 transmits the two factory certificates C 0 and provisional C'i to the trusted third party 44 by the through the network 42.
  • the certification server 45 of the ACP 10, which created the factory certificate C 0 of the physical device 13, communicates or communicated its public key P T to the verification server or AC 44.
  • the trusted third party 44 only has to use, on the one hand, the public certification key P ⁇ of the certification server 45 to verify E33 the authenticity of the factory certificate C 0 , and on the other hand, the device public key P 0 of device 13 to verify E34 the authenticity of the provisional certificate CV
  • the verification of the factory certificate C 0 can be carried out by a trusted third party 44 or by the ACP. This last case is particularly relevant in the case of the use of a symmetric key K
  • the trusted third party 44 When the trusted third party 44 has issued the device certificate Ci, the latter is transmitted to the user's communication terminal 41 via the communication network 42 to which the provider's registration server 43 is connected.
  • a user 40 can register E35 with one or more different trusted third parties, each of which will issue a separate device certificate Ci linking the public key Pi of the physical device 13 to an identifier Idi of the user 40, relevant to the trusted third party considered.
  • the user can then begin to carry out secure transactions with the service provider 43: to do this, he uses his physical device 13 to sign a provided hazard by the service provider (we speak then of authentication) or a message (we speak then of signature) thanks to its secret device key Si, and by associating with it the corresponding device certificate Ci, according to standard protocols which do not subject of this patent application and are therefore not described here in more detail.
  • the invention does not modify the mode of use of a physical device for performing authentication, signing, or even doing encryption.
  • providers who need the device certificate Ci for example to verify an authentication, or a signature, or to encrypt a message
  • the content of this field ⁇ info> gives assurance to providers 43 who interact with a user 40 that the user is in possession of a physical device 13 with characteristics contained in the ⁇ info> field.
  • the quadruplet (P 0 , S 0 , C 0 , ⁇ info>) can be the same for all physical devices of the same given type, described in the ⁇ info> field (for example for all USB "dongles" produced by the same manufacturer), so that all these devices carry the same private device key S 0 .
  • the quadruplet (P 0 , S 0 , C 0 , ⁇ info>) can be specific to a given physical device. This second solution is more advantageous in terms of security, and makes it possible to better counter possible fraud attempts by users.
  • the quadruplet (P 0 , S 0 , C 0 , ⁇ info>) is specific to each device, it is always possible for a fraudster to fraudulently seize the private key of device S 0 , but this fraud can be countered by introducing one or more of the following measures: the trusted third party issuing the device certificates Ci puts the fraudulent quadruplet (P 0 , S 0 , C 0 , ⁇ info>) in opposition, and refrains from issuing Ci device certificates to users presenting this quadruplet during the registration phase; the trusted third party communicates the list of the fraudulent quadruplet (s) that it has been able to detect to the ACP 10, which can then publish it or make it available to all the trusted third parties or service providers who trust it, so that none of them issue more Ci device certificates to users with such quadruplets; Finally, each trusted third party puts in opposition all of the Ci device certificates which have already been issued from a quadruplet identified as fraudulent, in order to prevent such Ci device certificates
  • the invention therefore allows secure transactions to be carried out between a user, who owns a physical device, and one or more providers, while ensuring the non-traceability of the user by the different providers.
  • the device certificate Ci is issued by a certification authority independent of the service provider, the latter has access only to the device certificate Ci, and therefore to the extension field ⁇ info> which is associated with it.
  • this ⁇ info> field contains only generic information on the physical device, the provider cannot then establish a link between the Idi identifier associated with the device certificate Ci and the physical device itself (identified in the embodiment described above by a single quadruplet (P 0 , S 0 , C 0 , ⁇ info>).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne le contrôle de transactions sécurisées mettant en œuvre un dispositif physique détenu par un utilisateur et portant au moins une première paire de clés asymétriques, comprenant une première clé de dispositif publique (P0) et une première clé de dispositif privée correspondante. Selon l'invention, un tel contrôle comprend les étapes suivantes : préalablement à la mise en service dudit dispositif, certification d'une première clé de dispositif publique (P0) et d'informations (<info>) caractéristiques du dispositif physique par signature au moyen d'une première clé de certification, délivrant un certificat usine (C0), après vérification que ladite clé de dispositif privée S0 est logée dans une zone inviolable dudit dispositif physique ; génération d'au moins une deuxième paire de clés asymétriques, comprenant une deuxième clé de dispositif publique (Pi) et une deuxième clé de dispositif privée, logée dans une zone inviolable du dispositif ; certification d'une deuxième clé de dispositif publique (Pi) par signature au moyen de la première clé de dispositif privée, délivrant un certificat rovisoire (Ci) ; vérification (E33, E34) des certificats usine (C0) et provisoire (Ci), au moyen respectivement d'une deuxième clé de certification correspondant à ladite première clé de certification, et de la première clé de dispositif publique (P0) ; en cas de vérification positive, délivrance (E35) par un tiers de confiance d'un certificat de dispositif correspondant à la signature par ledit prestataire d'au moins ladite deuxième clé de dispositif publique (Pi) et d'un identifiant dudit utilisateur et desdites informations (<info>) caractéristiques du dispositif.

Description

Procédé de contrôle de transactions sécurisées mettant en œuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système, et programme d'ordinateur correspondants.
1. Domaine de l'invention
Le domaine de l'invention est celui de la sécurisation des transactions électroniques, mettant notamment en œuvre des opérations d'authentification, de signature électronique et de paiement, effectuées par le biais de réseaux de communication tels que le réseau Internet par exemple.
Plus précisément, l'invention concerne une technique de contrôle de transactions sécurisées faisant intervenir un dispositif physique détenu par un utilisateur, et pouvant être utilisé pour réaliser des transactions avec plusieurs prestataires ou fournisseurs de biens ou de services distincts.
2. Solutions de l'art antérieur
Le fort développement des réseaux de communication, comme le réseau mondial Internet par exemple, et l'accroissement constant du nombre de transactions effectuées chaque jour sur ces réseaux, a fait naître un besoin sans cesse croissant de sécurisation des transactions. En effet, il est apparu nécessaire de reproduire sur ces réseaux informatiques ou de radiocommunication l'environnement de confiance entourant les échanges physiques par courrier classique ou par contact direct.
Selon l'art antérieur, un certificat permet notamment de vérifier la validité d'une clé cryptographique publique utilisée sur un réseau informatique, et est un message comprenant, au minimum, une clé publique, un identifiant de son détenteur, une période de validité, une identification d'une autorité de certification, ainsi qu'une signature cryptographique de ces différentes données, réalisée au moyen de la clé secrète de cette autorité de certification émettrice du certificat.
La lecture du certificat permet d'authentifier avec certitude l'émetteur d'un message reçu dans le cas de la signature et l'identifiant de celui qui s'authentifie dans le cas de l'authentification. Pour plus d'information sur les certificats, on pourra se référer notamment au standard X.509, et plus particulièrement X.509v3 défini dans la RFC3280 (Request For Comment n°3280) publiée par l'IETF (Internet Engineering Task Force).
Lorsqu'un client souhaite pouvoir s'authentifier ou signer en utilisant n identifiants (Id1, Id 2,..., IdnJ de manière totalement indépendante, il utilise plusieurs paires de clés asymétriques (Si, Pi), où i=l,...,n. Les certificats Ci délivrés par une autorité de certification lient alors les différentes clés publiques Pi aux identifiants Idi, ainsi qu'à d'éventuelles autres informations.
On définit alors n triplets (Pi, Si, Ci) associés chacun à un identifiant Idi distinct, et constitués d'une clé publique Pi, d'une clé privée Si et d'un certificat Ci.
Lorsqu'il veut ensuite réaliser une transaction sécurisée avec le ilème prestataire, le client signe un aléa envoyé par le prestataire (on parle alors d'authentification) ou un message (on parle alors de signature électronique) grâce à sa clé secrète Si et en y associant le certificat correspondant Ci fourni par l'autorité de certification (qui peut, le cas échéant, être le prestataire lui-même), selon des protocoles standardisés.
On garantit ainsi la non-traçabilité du client, même s'il conclut des transactions avec différents prestataires.
Cependant, un inconvénient de la technique de l'art antérieur citée ci- dessus est qu'elle ne permet pas à une autorité de certification ou à un prestataire de s'assurer simplement, et à distance, que le certificat Ci qu'elle délivre ou qu'il utilise certifie une clé publique Pi correspondant à une clé privée Si stockée dans un dispositif physique donné.
En effet, le comportement d'un dispositif physique peut être totalement simulé par un logiciel, si bien qu'à distance, il est impossible pour le prestataire de savoir s'il correspond à un dispositif physique ou bien à une émulation logicielle d'un tel dispositif.
Or il existe plusieurs circonstances dans lesquelles il est important pour un prestataire d'avoir la preuve qu'il dialogue avec un véritable dispositif physique. En effet, si la clé privée Si du dispositif physique reste stockée, conformément aux "bonnes pratiques" dans une zone secrète et inaccessible, le dispositif physique ne peut être clone, et constitue donc un objet unique, qui est seul capable de produire les authentifiants et les signatures correspondant à la clé publique Pi, donc au certificat Ci, et donc également à l'identifiant Idi par lequel le client est connu du ilème prestataire. Le possesseur du dispositif physique est alors le seul à pouvoir s'authentifier ou signer avec l'identifiant Idi vis-à-vis du ilème prestataire, ce qui constitue une propriété de non-répudiation forte, gage de sécurité pour le prestataire.
Une autre circonstance dans laquelle il est important pour le prestataire de pouvoir s'assurer qu'il a affaire à un dispositif physique donné est le cas où ce dispositif physique est le support d'un abonnement payant à un service fourni par le prestataire (par exemple, l'accès sur Internet aux articles de journaux publiés dans un quotidien). L'accès au service payant est conditionné, pour l'utilisateur, par l'ouverture d'une session auprès du prestataire, au cours de laquelle il s'authentifie au moyen de son dispositif physique.
Il est donc particulièrement important pour le prestataire de s'assurer que le client qui souhaite accéder au service est bien en possession du dispositif physique, afin d'éviter que plusieurs personnes puissent accéder (simultanément ou non) au service, en payant un seul abonnement, ce qui serait le cas si le support de l'abonnement pouvait être clone (par exemple si le support de l'abonnement était un ensemble "identifiant/mot de passe" ou une clé privée (même chiffrée) stockée sur un disque dur).
La demande de brevet français FR 96 08692 intitulée "Procédé de contrôle de transactions sécurisées indépendantes utilisant un dispositif physique unique", au nom du même demandeur que la présente demande de brevet, décrit plus particulièrement l'utilisation d'un dispositif physique pour réaliser une authentification auprès d'un ou plusieurs prestataires, avec lesquels l'utilisateur du dispositif souhaite effectuer une transaction.
Selon ce procédé, on met à la disposition des utilisateurs des dispositifs physiques tels que des cartes à puce ou des "dongles" USB ("Universal Sériai Bus" pour "bus série universel"), qui sont classiquement associés à une paire de clés asymétriques (P0, S0) comprenant une clé privée S0 et une clé publique P0. La clé privée S0 est un élément électronique qui doit rester secret, et qui est donc stocké dans un espace protégé du dispositif physique, à l'abri de toute tentative d'intrusion. La clé publique P0 quant à elle peut être stockée en lecture libre dans le dispositif physique, ou être livrée à l'utilisateur sur un support externe, tel qu'une disquette, un CD-Rom, un document papier, ou un espace réservé d'un serveur de données. Cette paire de clés (S0, P0) est créée en usine, préalablement à la commercialisation et à la mise en service du dispositif.
Un tel dispositif physique comprend également classiquement des moyens de calcul permettant de mettre en œuvre un algorithme cryptographique asymétrique d'authentification et/ou de signature. Parmi ces algorithmes, on peut citer les algorithmes de type RSA (Rivest-Shamir-Adleman), DSA, GQ (Guillou- Quisquater) ou GPS par exemple.
L'utilisation de cet algorithme cryptographique asymétrique peut être assujettie à la présentation préalable d'un code porteur (ou code PESf pour "Personal Identification Number") initialisé lors d'une phase de (pré)personnalisation du dispositif physique, et géré selon des techniques classiques, qui ne font pas l'objet de la présente demande de brevet.
Le dispositif physique peut être ensuite vendu sous cette forme à un utilisateur, par un moyen de distribution indépendant de tout prestataire.
Pour pouvoir réaliser une transaction sécurisée (authentification, signature) avec un prestataire, l'utilisateur du dispositif physique, encore appelé client, doit se faire délivrer par le prestataire, ou par une autorité de certification indépendante, un certificat C1 liant la clé publique P0 du dispositif et un identifiant Id1 pertinent pour le prestataire (remarque : dans les systèmes où l'anonymat de l'utilisateur vis-à-vis du prestataire doit être préservé, l'identifiant Id1 est différent de l'identité civile de l'utilisateur).
Cette opération, appelée "enregistrement", peut être réalisée auprès de n prestataires distincts, de sorte que le client se voit attribuer n certificats {Cl5C2,...,Cn} liant n identifiants (Id1, Id2,..., IdnJ (chacun d'entre eux étant pertinent pour un prestataire donné) à ladite clé publique P0.
3. Inconvénients de l'art antérieur
Selon la technique antérieure, la seule méthode permettant à un prestataire ou une autorité de certification de s'assurer que la transaction en cours se fait bien au moyen d'un dispositif physique donné repose sur la manipulation physique du dispositif par le prestataire ou l'autorité de certification. En effet, il peut alors lire lui-même la clé publique P0 ou Pi dans le dispositif, dans le cas où elle y est stockée ; dans le cas contraire, il peut faire signer un aléa au dispositif, au moyen de la clé secrète S0 ou Si, et vérifier ensuite le résultat de cette signature au moyen de la clé publique P0 ou Pi fournie par le client sur un support externe.
Cependant, un inconvénient de cette solution antérieure est qu'elle impose que le prestataire ou l'autorité de certification puissent opérer physiquement sur le dispositif, et exclut donc toute action à distance, ce qui s'avère très problématique, et même souvent impossible, dans le cadre de transactions effectuées sur les réseaux de communication modernes tels qu'Internet.
Par ailleurs, dans le cas du procédé selon la demande FR 96 08692, comme tous les certificats (C1, C2,..., Cn} utilisent la même clé publique P0, il est possible pour une entité mal- intentionnée de corréler les différents identifiants (Id1, Id2,..., IdnJ du client, ce qui constitue un inconvénient dans le cas où l'on souhaite garantir une non-traçabilité de l'utilisateur du dispositif physique.
4. Objectifs de l'invention
L'invention a notamment pour objectif de pallier ces inconvénients de l'art antérieur.
Plus précisément, un objectif de l'invention est de fournir une technique de contrôle de transactions sécurisées mettant en œuvre un dispositif physique associé à plusieurs paires de clés asymétriques et susceptible d'être utilisé pour conclure des transactions avec plusieurs prestataires distincts, permettant de s'assurer qu'une transaction est bien effectuée au moyen d'un dispositif physique donné, tout en garantissant une non-traçabilité de l'utilisateur par tout ou partie des prestataires.
Un autre objectif de l'invention est de proposer une telle technique qui soit simple à mettre en œuvre et introduise peu de complexité supplémentaire dans les dispositifs physiques utilisés et très peu de modifications dans les logiciels et serveur des prestataires ou des autorités de certification.
L'invention a encore pour objectif de fournir une telle technique qui soit fiable et permette d'obtenir une propriété de non répudiation forte, de façon à créer, pour le prestataire, un environnement de confiance.
L'invention a aussi pour objectif de proposer une telle technique qui permette, si besoin, d'assurer la traçabilité du client par une ou plusieurs autorités de certification.
Un objectif secondaire de l'invention est de proposer une telle technique qui permette aux prestataires d'accéder à des informations sur les caractéristiques
(marque, type, algorithmes utilisés, ...) du dispositif physique avec lequel ils dialoguent.
5. Exposé de l'invention
Ces objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints à l'aide d'un procédé de contrôle de transactions sécurisées mettant en œuvre un dispositif physique détenu par un utilisateur et portant au moins une première paire de clés asymétriques, comprenant une première clé de dispositif publique
(P0) et une première clé de dispositif privée (S0) correspondante, ladite première clé de dispositif privée (S0).
Selon l'invention, un tel procédé de contrôle comprend les étapes suivantes : préalablement à la mise en service dudit dispositif physique, une première étape de certification de ladite première clé de dispositif publique (P0) et d'informations (<info>) caractéristiques du dispositif physique par signature au moyen d'une première clé de certification (ST) d'une autorité de certification particulière (ACP), délivrant un certificat usine (C0), après vérification que ladite clé de dispositif privée S0 est logée dans une zone inviolable dudit dispositif physique ; une étape de génération d'au moins une deuxième paire de clés asymétriques, comprenant une deuxième clé de dispositif publique (Pi) et une deuxième clé de dispositif privée (Si) (i=l,...), ladite deuxième clé de dispositif privée (Si) étant logée dans une zone inviolable dudit dispositif ; une deuxième étape de certification de ladite deuxième clé de dispositif publique (Pi) par signature au moyen de ladite première clé de dispositif privée (S0), délivrant un certificat provisoire (C'i) ; une première étape de vérification dudit certificat usine (C0) au moyen d'une deuxième clé de certification (Pτ) correspondant à ladite première clé de certification (ST) ; une deuxième étape de vérification dudit certificat provisoire (C'i) au moyen de ladite première clé de dispositif publique (P0) ; en cas de vérification positive desdits certificat usine (C0) et certificat provisoire (C'i), une étape de délivrance par un tiers de confiance d'un certificat de dispositif (Ci) correspondant à la signature au moins de ladite deuxième clé de dispositif publique (Pi), d'un identifiant (Idi) dudit utilisateur et desdites informations (<info>) caractéristiques du dispositif. Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de la sécurisation des transactions électroniques effectuées au moyen d'un dispositif physique de type "dongle" USB, carte à puces, etc., pour lesquelles on souhaite assurer la non-traçabilité de l'utilisateur. En effet, la technique de l'invention repose : d'une part, sur l'utilisation de plusieurs paires de clés asymétriques du dispositif, chaque paire étant associée à un identifiant distinct du client, et permettant d'assurer sa non-traçabilité à l'égard des différents prestataires avec lesquels il entre en relation ; et d'autre part sur l'intervention, pour introduire un degré supplémentaire de sécurisation, d'une autorité de certification particulière (ACP), à laquelle les différents tiers de certification et les différents prestataires accordent toute leur confiance. Cette autorité de certification particulière délivre, préalablement à la mise en service du dispositif physique ("dongle" USB, carte à puce, ...), un certificat relatif à ce dispositif physique (et non, comme dans l'art antérieur, un certificat relatif à un identifiant de son détenteur), qui permet de vérifier que la première clé publique P0 du dispositif physique correspond bien à une première clé privée S0 stockée, conformément aux bonnes pratiques, dans une zone secrète du dispositif. L'ACP certifie donc le dispositif physique. Un certificat provisoire C'i, produit (généralement par le dispositif lui- même) grâce à la clé secrète S0 dont la clé publique P0 correspondante est certifiée par l'ACP, permet quant à lui de garantir qu'une deuxième clé publique Pi du dispositif physique correspond bien à une deuxième clé privée de dispositif Si également stockée, conformément aux bonnes pratiques, dans une zone secrète et inviolable du dispositif. Cette clé publique de dispositif Pi est celle qui est utilisée par le client pour réaliser une transaction avec un ilème prestataire.
La vérification de la validité de ces deux certificats, usine et provisoire, est une garantie, pour le tiers de confiance, qu'il se trouve, même à distance, en présence d'un véritable dispositif physique, et non d'un équipement (ordinateur, PDA, etc.) qui en reproduirait frauduleusement le comportement.
Enfin, la vérification de la validité du certificat de dispositif Ci et l'examen du champ <info> est une garantie, pour le prestataire, qu'il se trouve, même à distance, en présence d'un véritable dispositif physique, et non d'un équipement (ordinateur, PDA, etc.) qui en reproduirait frauduleusement le comportement.
On construit ainsi une chaîne de confiance, entre un prestataire qui accorde sa confiance à un tiers de confiance vérifiant les certificats usine et provisoire, et qui fait lui-même toute confiance à l'autorité de certification particulière émettant le certificat usine C0. Ainsi, le procédé de contrôle de transactions selon l'invention utilise l'engagement de l'ACP pour assurer à un prestataire qu'un client qui souhaite engager une transaction sécurisée possède bien un dispositif physique, lequel a été certifié par l'ACP. On se distingue ainsi fortement de l'art antérieur, qui n'assure pas à distance que l'utilisateur possède un dispositif physique. En effet, les techniques de contrôle selon l'art antérieur assurent seulement l'identification d'un utilisateur, si besoin à l'aide d'un enchaînement d'authentifications et de certifications basé sur l'utilisation d'une succession d'autorités de certification, mais ayant toujours pour unique conséquence la certification de l'identité d'un utilisateur. Le procédé selon l'invention comprend, outre la certification de l'identité de l'utilisateur, la certification préalable du dispositif physique subséquemment détenu par cet utilisateur. Cela permet d'assurer à un prestataire, éventuellement à distance, que l'utilisateur qui s'authentifie auprès de lui possède un dispositif physique. Seule cette assurance permet la poursuite de l'établissement du processus de contrôle de transaction.
De plus, la génération, à la volée, par le dispositif physique, d'autres paires de clés asymétriques correspondant à un besoin d'établissement d'une transaction sécurisée entre un prestataire et un utilisateur assure la non répudiation des clés générées, du fait de l'utilisation de la clé secrète S0 pour certifier cette paire de clés. En effet, S0 ne pouvant être substituée par une autre clé du fait de la certification par l'ACP de P0, les certificats qui résultent de la signature par S0 des paires de clés asymétriques ne peuvent pas être répudiés.
Avantageusement, un tel procédé de contrôle est mis en œuvre pour au moins deux deuxièmes paires de clés asymétriques dudit dispositif, associées chacune à un identifiant (Idi) dudit utilisateur, et chacun desdits certificats de dispositif (Ci) délivrés lors desdites étapes de délivrance lie l'une desdites deuxièmes clés de dispositif publiques (Pi) audit identifiant (Idi) associé.
Le dispositif physique peut ainsi être utilisé lors de transactions avec plusieurs prestataires, auprès de chacun desquels l'utilisateur est identifié par un identifiant Idi distinct.
Préférentiellement, lesdites informations caractéristiques dudit dispositif physique appartiennent au groupe comprenant les informations suivantes :
- type de dispositif physique (carte à puce, « dongle » USB, etc.) ; - identification du fabricant dudit dispositif physique ;
- type d'algorithme cryptographique utilisé par ledit dispositif physique RSA, GQ, etc.) ;
- numéro de série dudit dispositif physique.
Selon une caractéristique avantageuse de l'invention, lors d'une transaction, ledit prestataire consulte lesdites informations (<info>) caractéristiques dudit certificat de dispositif (Ci).
De manière préférentielle, un tel procédé de contrôle comprend une phase de personnalisation dudit dispositif physique, au cours de laquelle ladite première paire de clés asymétriques, ledit certificat usine (C0), et lesdites informations (<info>) dudit certificat usine sont associées de manière unique audit dispositif physique, de façon à réduire les risques de transactions frauduleuses. Cette phase de personnalisation peut être faite par exemple en usine, avant commercialisation du dispositif.
De façon avantageuse, lesdits certificat usine (C0) et certificat provisoire (C'i) sont stockés dans au moins une zone de mémoire en lecture libre dudit dispositif physique. Ils sont ainsi aisément accessibles pour le prestataire ou le tiers de confiance.
Préférentiellement, l'une au moins desdites première et deuxième étapes de vérification est effectuée par ledit prestataire.
Selon une première variante avantageuse, ladite première clé de certification (ST) est une clé privée et ladite deuxième clé de certification (Pτ) est une clé publique.
Selon une deuxième variante avantageuse, ladite autorité de certification particulière utilise une clé symétrique (K), de sorte que ladite première clé de certification (ST) et ladite deuxième clé de certification (Pτ) sont identiques.
L'invention concerne aussi un dispositif physique détenu par un utilisateur et destiné à être utilisé lors de transactions sécurisées, ledit dispositif physique portant au moins une première paire de clés asymétriques, comprenant une première clé de dispositif publique (P0) et une première clé de dispositif privée (S0) correspondante.
Selon l'invention, un tel dispositif porte également un certificat usine (C0), délivré après vérification que ladite clé de dispositif privée S0 est logée dans une zone inviolable dudit dispositif physique), correspondant à la signature de ladite première clé de dispositif publique (P0) et d'informations (<info>) caractéristiques du dispositif physique par une première clé de certification (ST) d'une autorité de certification particulière (ACP), au moins une deuxième paire de clés asymétriques comprenant une deuxième clé de dispositif publique (Pi) et une deuxième clé de dispositif privée (Si) correspondante, ladite première clé de dispositif privée (S0) étant logée dans au moins une zone inviolable dudit dispositif, et un certificat provisoire (Ci) correspondant à la signature de ladite deuxième clé de dispositif publique (Pi) par ladite première clé de dispositif privée (S0). En outre, ledit certificat usine (C0) est stocké dans ledit dispositif physique préalablement à sa mise en service.
L'invention concerne encore un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, qui comprend des instructions de code de programme pour la mise en œuvre d'au moins une étape du procédé de contrôle de transactions sécurisées tel que décrit précédemment.
L'invention concerne également un système de contrôle de transactions sécurisées sur un réseau de communication, mettant en œuvre un dispositif physique détenu par un utilisateur et portant au moins une première paire de clés asymétriques, comprenant une première clé de dispositif publique (P0) et une première clé de dispositif privée (S0) correspondante.
Selon l'invention, un tel système de contrôle comprend au moins : un serveur de certification particulière relié audit réseau, délivrant audit dispositif physique, après vérification que ladite clé de dispositif privée S0 est logée dans une zone inviolable dudit dispositif physique et préalablement à sa mise en service, un certificat usine (C0) correspondant à la signature de ladite première clé de dispositif publique (P0) et d'informations (<info>) caractéristiques du dispositif physique par une première clé de certification (ST) dudit serveur de certification particulière (ACP) ; un tiers de confiance (44) vérifiant ledit certificat usine (C0) au moyen d'une deuxième clé de certification (Pτ) correspondant à ladite première clé de certification (ST), et un certificat provisoire (Ci) stocké dans ledit dispositif physique, correspondant à la signature d'une deuxième clé de dispositif publique (Pi) par ladite première clé de dispositif privée (S0), au moyen de ladite première clé de dispositif publique (P0), et délivrant audit utilisateur, en cas de vérification positive, un certificat de dispositif (Ci) correspondant à la signature par ledit tiers de confiance (44) au moins de ladite deuxième clé de dispositif publique (Pi), d'un identifiant (Idi) dudit utilisateur et des informations (<info>) caractéristiques du dispositif, ledit tiers de confiance étant relié audit réseau. 6. Liste des figures
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 illustre le principe de la certification, par une autorité de certification particulière, de la clé publique d'un dispositif physique, lors d'une phase de personnalisation du dispositif ; la figure 2 présente le principe de la création d'une deuxième paire de clés asymétriques (Pi, Si), ainsi que d'un certificat provisoire Ci dans un dispositif physique ; la figure 3 illustre un synoptique des différentes étapes mises en œuvre dans le procédé de contrôle de transactions sécurisées de l'invention ; la figure 4 décrit les différents échanges entre un utilisateur et différents serveurs de l'invention, via un réseau de communication, dans le cadre du procédé de la figure 3. 7. Description d'un mode de réalisation de l'invention
Le principe général de l'invention repose sur la certification des clés publiques P0 et Pi d'un dispositif physique, permettant de garantir à un prestataire, lors d'une transaction sécurisée (éventuellement à distance), qu'il traite bien avec un véritable dispositif physique, dans lequel sont stockées les clés privées S0 et Si correspondantes, tout en assurant la non-traçabilité, par le prestataire, de l'utilisateur de ce dispositif.
On présente, en relation avec la figure 1, un mode de réalisation de la certification de la clé publique P0 d'un dispositif physique 13 donné, préalablement à sa mise en service. Une telle certification peut avoir lieu lors d'une phase standard de personnalisation en usine du dispositif physique 13, au cours de laquelle on équipe le dispositif d'un quadruplet (P0, S0, C0 et <info>).
Une autorité de certification particulière, ou ACP, 10 possède une paire de clés asymétriques (PT, ST) comprenant une clé publique PT et une clé privée ST conservée dans une zone secrète et inaccessible 101. Une telle ACP 10 est par exemple le fabricant du dispositif physique : la zone secrète 101 dans laquelle est mémorisée la clé privée ST est alors un dispositif physique particulier (une carte à puce par exemple) détenu par le fabricant, ou une zone mémoire protégée à accès restreint de l'un de ses équipements informatiques.
La clé publique PT quant à elle est publiée par l'ACP 10, ou fournie à la demande à des prestataires potentiels susceptibles d'en avoir besoin (i.e. aux tiers de confiance susceptibles de réaliser des transactions avec le détenteur du dispositif physique 13).
Lors de la fabrication du dispositif physique 13, on y enregistre une paire de clés asymétriques (P0, S0) comprenant une clé publique P0, mémorisée dans une zone 131 accessible en lecture du dispositif 13, et une clé privée S0 mémorisée dans une zone protégée 132 de ce dispositif 13. Cette zone protégée, ou inviolable, 132 est conçue de façon à empêcher la lecture de la clé privée S0 et à résister à toute tentative d'intrusion logicielle ou matérielle. En effet, l'usage de la clé privée S0 par le dispositif 13 est fortement contraint : notamment, comme expliqué ci-dessous, le dispositif 13 ne peut pas utiliser cette clé privée de dispositif S0 pour produire des signatures de données externes. En variante, la clé publique P0 peut également être communiquée au détenteur du dispositif physique 13 sur un support externe, indépendant du dispositif lui-même.
Comme indiqué ci-dessus, si l'ACP 10 est le fabricant du dispositif physique 13, les opérations illustrées sur la figure 1 sont réalisées avant la commercialisation du dispositif physique, en usine, lors d'une phase de personnalisation. S'il s'agit d'une autorité de certification indépendante du fabricant, ces opérations peuvent être réalisées en sortie des chaînes de fabrication, avant la distribution des dispositifs physiques aux utilisateurs finaux.
Plus précisément, le dispositif physique 13 communique l i a l'ACP 10 sa clé publique de dispositif P0. Le certificat usine C0 délivré par l'ACP 10 peut correspondre à la signature par l'ACP 10 de la clé publique de dispositif P0 et du champ <info>, qui est un champ regroupant un ensemble d'informations caractéristiques du dispositif 13 (par exemple, le nom du fabricant, le type du dispositif, la nature des algorithmes cryptographiques de signature utilisés par le dispositif, etc.).
Cette signature 12 constitue un certificat usine C0=A(Sτ,Po<info>) (où A désigne un algorithme cryptographique de signature, de type RSA par exemple) qui, comme la clé publique de dispositif P0 pourra être inscrit dans le dispositif physique 13, dans une zone en lecture libre 131, ou fourni à l'utilisateur du dispositif 13 sur un support externe (disquette, CD-Rom, document papier, ...).
L'ACP certifie ainsi initialement que la clé privée de dispositif S0 est logée dans un dispositif physique 13 de caractéristiques données par le champ <info>. Comme la clé publique de dispositif P0 et le certificat usine C0, le champ <info> peut être stocké en lecture libre dans la zone référencée 131 du dispositif 13, ou sur un support externe, ou simplement être communiqué aux prestataires ou tiers de confiance qui pourraient en avoir besoin.
L'ACP 10 (fabricant ou tiers de confiance) s'engage bien sûr à ne produire de tels certificats usine C0 (i.e. de telles signatures avec sa clé privée ST) que pour des clés publiques P0 correspondant à des clés privées stockées dans un dispositif physique d'un type donné.
Les opérations de certification de la figure 1 peuvent également, dans une variante de réalisation de l'invention, être mutualisées pour plusieurs fabricants de dispositifs physiques de types différents. Dans ce cas, l'ACP 10 est un tiers de confiance indépendant de l'ensemble des fabricants, qui détient la clé privée ST et qui, pour produire le certificat usine C0 d'un dispositif physique 13 donné, signe, avec sa clé privée de certification ST, le couple (P0, <info>). Les informations caractéristiques contenues dans le champ <info> permettent de renseigner par exemple sur la nature du dispositif 13, à savoir un "dongle" USB, une carte à puce, etc. Il peut également s'agir de la référence produit utilisée par le fabricant pour désigner l'un des dispositifs qu'il construit.
De même, en variante, d'autres informations pertinentes pour l'utilisation du dispositif physique 13 peuvent être signées dans le certificat usine C0, telles que le nom du fabricant (<nom du fabricant), le type d'algorithme cryptographique utilisé (<type d'algorithme>), le numéro de série du dispositif, etc.
Ainsi, lors d'une phase ultérieure de vérification du certificat usine C0 par un prestataire (décrite ci-dessous plus en détail en relation avec les figures 3 et 4), ce dernier sera assuré que la clé publique de dispositif P0 correspond à une clé secrète S0 stockée dans un dispositif 13 de type <info>, fabriqué par <nom du fabricant^ et utilisant l'algorithme cryptographique <type d'algorithme>. Cette assurance résulte de la confiance qu'a le prestataire en l'autorité de certification particulière 10.
On peut également imaginer, en variante des opérations illustrées par la figure 1, que PT=ST=K soit une clé symétrique.
Dans ce cas, la clé K peut être partagée entre le fabricant du dispositif physique 13 et un (ou quelques rares) tiers de confiance, dont le fabricant sait qu'ils garderont cette clé K secrète ; dans ce cas, seuls ces tiers ou le fabricant lui- même pourront vérifier le certificat. On peut aussi envisager que la clé K ne soit utilisée que par une ACP 10 indépendante du fabricant, qui signe le certificat usine C0 à clé symétrique, uniquement sur demande du fabricant de dispositifs physiques 13. De même, cette ACP 10 sera seule à pouvoir vérifier les certificats usine C0, sur requête des prestataires souhaitant réaliser une transaction avec les dispositifs physiques 13 associés. A nouveau, cette ACP 10 peut bien sûr être le fabricant lui-même.
Le quadruplet (P0, S0, C0, <info>) peut être caractéristique d'un dispositif physique 13 donné, ou être le même pour tous les dispositifs physiques 13 ayant des caractéristiques identiques décrites dans le champ <info>. Dans ce dernier cas, il n'est pas nécessaire de faire appel à l'ACP 10 lors de la personnalisation du dispositif 13, car le quadruplet (P0, S0, C0, <info>) est constitué une et une seule fois pour une série de dispositifs donnés.
Le dispositif physique 13 dans lequel le certificat C0 a été enregistré par l'ACP 10 est vendu par un moyen de distribution indépendant de tout prestataire, par exemple dans une grande surface ou chez un revendeur agréé.
Il peut alors être utilisé pour réaliser des transactions sécurisées avec un prestataire, ce qui nécessite la mise en œuvre d'une phase d'enregistrement, décrite plus en détail en relation avec la figure 2.
Un tel enregistrement comprend : une première opération de création d'une deuxième paire de clés asymétriques de dispositif (Pi, Si), qui seront utilisées lors des échanges avec le prestataire n°i ; une deuxième opération de délivrance d'un certificat de dispositif Ci par un tiers de confiance.
En reprenant les notations et références numériques de la figure 1, le dispositif physique 13 comprend, dans une zone de mémoire en lecture libre 1311, une première clé publique de dispositif P0, un certificat usine C0, et éventuellement un champ <info> qui n'a pas été représenté sur la figure 2. Il comprend également, dans une zone de mémoire inviolable 1321, une première clé secrète de dispositif S0. Afin d'assurer la non-traçabilité de l'utilisateur du dispositif 13 lors, le cas échéant, de ses différents échanges avec des prestataires, il est nécessaire, dans un tel cas, de stocker dans le dispositif 13 d'autres paires de clés asymétriques (Pi, Si), qu'il pourra utiliser pour réaliser des signatures et s'authentifier auprès d'un ilème prestataire.
Deux solutions peuvent être envisagées pour la création de ces paires de clés asymétriques supplémentaires (Pi, Si).
Dans une première variante de réalisation, ce couple (Pi, Si) est créé par le dispositif physique 13 lui-même. En effet, de nombreux dispositifs cryptographiques sont capables d'auto-générer leurs clés, selon une technique classiquement appelée "on board key génération". C'est une APDU ("Application Protocol Data Unit" pour "unité de données de protocole d'application") qui déclenche le processus de génération des clés (Pi, Si). La clé publique de dispositif Pi est ensuite logée dans une zone 1312 du dispositif physique 13 accessible en lecture, et la clé privée de dispositif Si est logée dans une zone 1322 inviolable, présentant des conditions d'accès spécifiques. En effet, une telle zone inviolable 1322 n'est accessible ni en lecture ni en écriture, et seul un algorithme cryptographique de signature adapté peut utiliser cette clé secrète de dispositif Si. En outre, cette utilisation est assujettie à la présentation préalable correcte d'un code porteur (ou code PIN).
Selon l'invention, dans cette première variante de réalisation, l'APDU de génération de clés (Pi, Si) implémentée dans le dispositif physique 13 réalise également une opération supplémentaire, consistant à signer la deuxième clé publique de dispositif Pi avec la première clé privée de dispositif S0 logée dans la zone inviolable 1321. Cette signature constitue un certificat provisoire C'i=A(S0,Pi) (où A est un algorithme cryptographique de signature, par exemple de type RSA ou GQ), que l'on stocke également dans une zone du dispositif physique 13 accessible en lecture, par exemple la zone 1312 dans laquelle est déjà stockée la clé publique de dispositif Pi.
Dans une deuxième variante de réalisation, le couple de clés asymétriques supplémentaires (Pi, Si) est créé en dehors du dispositif physique 13, par exemple par un ordinateur équipé d'un module de sécurité. On implémente alors dans le dispositif physique 13 une APDU spécifique, qui permet : d'introduire la deuxième clé privée de dispositif Si dans la zone inviolable
1322, par exemple en réalisant un transport chiffré de cette clé Si entre le module de sécurité de l'ordinateur l'ayant créée et le dispositif physique
13 ; d'écrire la deuxième clé publique de dispositif Pi dans une zone 1312 accessible en lecture du dispositif physique ; de réaliser la signature de la deuxième clé publique de dispositif Pi au moyen de la première clé privée de dispositif S0, et de stocker le certificat provisoire Ci ainsi obtenu dans une zone 1312 accessible en lecture du dispositif physique.
Que la paire de clés (Pi, Si) ait été créée dans ou hors du dispositif physique 13, celui-ci dispose à l'issue de cette opération d'un triplet (Pi, Si, Ci), dont les différents éléments sont stockés dans des zones du dispositif 13 aux conditions d'accès adéquates.
Une telle opération de génération d'un triplet (Pi, Si, Ci) peut être réalisée à plusieurs reprises, pour équiper le dispositif physique 13 d'une pluralité de tels triplets, et donc autoriser l'utilisateur à réaliser des transactions sécurisées avec plusieurs prestataires distincts, tout en assurant sa non-traçabilité.
On notera que, dans chacune de ces deux variantes de réalisation, les zones 1311 et 1312 accessibles en lecture peuvent ou non être confondues. Il en est de même pour les zones inviolables à accès restreint 1321 et 1322.
La délivrance du certificat provisoire Ci doit constituer la seule utilisation possible de la première clé privée de dispositif S0. En d'autres termes, selon l'invention, la première clé privée de dispositif S0 ne peut être utilisée que pour signer, au sein d'une seule APDU, des clés publiques Pi, qu'elles aient été générées par le dispositif physique ou introduites dans celui-ci sous la forme d'une paire de clés asymétriques (Pi, Si). On présente maintenant, en relation avec les figures 3 et 4, la façon dont les certificats usine C0 et provisoire C'i sont utilisés pour la délivrance à l'utilisateur 40 du dispositif physique 13 d'un certificat de dispositif Ci.
Le dispositif physique 13 a été acquis par un utilisateur 40, qui souhaite l'utiliser pour accéder aux services proposés par un prestataire 43, via un réseau de communication 42, par exemple le réseau mondial Internet. Un tel prestataire 43 peut être par exemple un prestataire de services (accès à un service météo, ou à un service de géolocalisation par exemple) ou un vendeur de biens (commerçant sur Internet par exemple). Le dispositif physique 13 sert par exemple de support à un abonnement payant souscrit par l'utilisateur 40 auprès du prestataire 43 (par exemple un abonnement à un horoscope quotidien publié sur Internet).
Pour pouvoir accéder aux services du prestataire 43, l'utilisateur 40 doit s'enregistrer auprès d'un tiers de confiance, c'est-à-dire se faire délivrer un certificat de dispositif Ci, qui contient la signature par le tiers de confiance 44 de la clé publique de dispositif Pi, d'un identifiant Idi de l'utilisateur, ainsi que d'autres informations, telles que la date de validité du certificat, etc. Pour préserver l'anonymat de l'utilisateur 40, l'identifiant Idi peut différer de l'identité civile de l'utilisateur. On notera que le problème de la correspondance entre l'identifiant Idi et l'identité réelle de l'utilisateur ne fait pas l'objet de la présente invention et ne sera donc pas décrit ici plus en détail. Pour une solution à ce problème, on pourra se référer par exemple au document de brevet français FR 04 08992 au nom des mêmes déposants que la présente demande de brevet.
Pour pouvoir délivrer E35 le certificat de dispositif Ci, le tiers de confiance 44, qui peut le cas échéant être le prestataire 43, doit disposer des éléments 31 suivants : les clés publiques de dispositif P0 et Pi ; les certificats usine C0 et provisoire C'i ; un identifiant Idi de l'utilisateur 40 ; des informations caractéristiques <info> du dispositif physique 13.
Le tiers de confiance 44 doit également disposer d'autres informations requises selon le standard X509 cité précédemment, telles que la date de validité du certificat de dispositif Ci à délivrer, certaines informations relatives à l'utilisation des différentes clés, etc.
La façon dont l'autorité de certification acquiert la connaissance de ces différents éléments 31 ne fait pas l'objet de la présente demande de brevet et ne sera donc pas décrite ici plus en détail. On suppose dans la suite que l'autorité de certification est bien en possession de ces différentes informations 31.
Outre les vérifications standards imposées par la norme X509 que l'on ne décrit pas dans ce document, le tiers de confiance procède à différentes vérifications complémentaires dans le cadre de l'invention.
Selon l'invention, le tiers de confiance procède à la vérification E33 du certificat usine C0, au moyen de la clé publique PT de l'autorité de certification particulière 10, afin de vérifier que la clé publique de dispositif P0 qui a été transmise au prestataire 43 correspond bien à une clé secrète S0 stockée dans un dispositif physique décrit par le champ <info>. Une telle opération E33 consiste à vérifier que la signature de la clé publique de dispositif P0 et du champ <info> contenue dans le certificat usine C0 est exacte.
En cas de vérification négative, c'est-à-dire si le certificat usine C0 ne correspond pas à la signature de la clé publique P0 du dispositif physique et du champ <info> par la clé privée de certification ST de l'ACP 10, le tiers de confiance 44 peut mettre fin E36 à la transaction, et refuser la délivrance du certificat de dispositif Ci.
En cas de vérification positive en revanche, le tiers de confiance acquiert la certitude que la clé publique P0 correspond bien à une clé privée S0 logée dans un dispositif physique 13 de caractéristiques <info>, et peut alors procéder à la vérification E34 du certificat provisoire Ci, au moyen de la première clé publique de dispositif P0.
Si la signature Ci de la deuxième clé publique de dispositif Pi n'est pas exacte, le tiers de confiance 44 peut mettre fin E36 aux échanges avec l'utilisateur 40. Si en revanche la signature C'i de la deuxième clé publique de dispositif Pi est exacte, le tiers de confiance 44 acquiert la certitude (dans la mesure où il fait confiance à l'ACP 10) que la clé publique de dispositif Pi correspond bien à une clé privée de dispositif Si stockée sur un dispositif physique 13 dont les caractéristiques sont précisées dans le champ <info>, et il peut donc accéder à la demande de l'utilisateur 40, en procédant à la délivrance E35 du certificat de dispositif Ci.
Pour ce faire, le tiers de confiance 44 délivre à l'utilisateur 40 un certificat de dispositif Ci correspondant à la signature de la clé publique de dispositif Pi, de l'identifiant Idi et d'informations caractéristiques du dispositif physique.
Selon un mode de réalisation, lorsqu'un utilisateur 40 souhaite s'enregistrer auprès d'un prestataire 43 pour pouvoir réaliser des transactions sécurisées avec ce dernier, les différentes vérifications E33 à E34 décrites ci-dessus en relation avec la figure 3 peuvent être effectuées par le prestataire 43 lui-même ou par un tiers de confiance 44 (AC), également connecté au réseau 42. Dans ce cas, le prestataire 43 transmet les deux certificats usine C0 et provisoire C'i au tiers de confiance 44 par le biais du réseau 42. Le serveur de certification 45 de l'ACP 10, qui a créé le certificat usine C0 du dispositif physique 13, communique ou a communiqué sa clé publique PT au serveur de vérification ou AC 44.
Le tiers de confiance 44 n'a plus qu'à utiliser, d'une part, la clé publique de certification Pτ du serveur de certification 45 pour vérifier E33 l'authenticité du certificat usine C0, et d'autre part, la clé publique de dispositif P0 du dispositif 13 pour vérifier E34 l'authenticité du certificat provisoire CV
La vérification du certificat usine C0 peut être réalisée par un tiers de confiance 44 ou par l'ACP. Ce dernier cas est particulièrement pertinent dans le cas d'une utilisation d'une clé symétrique K
Lorsque le tiers de confiance 44 a émis le certificat de dispositif Ci, ce dernier est transmis au terminal de communication 41 de l'utilisateur par le biais du réseau de communication 42 auquel est connecté le serveur d'enregistrement du prestataire 43. De manière générale, un utilisateur 40 peut procéder à un enregistrement E35 auprès d'un ou de plusieurs tiers de confiance différents, qui délivreront chacun un certificat de dispositif distinct Ci liant la clé publique Pi du dispositif physique 13 à un identifiant Idi de l'utilisateur 40, pertinent pour le tiers de confiance considéré.
Lorsque l'enregistrement E35 de l'utilisateur 40 auprès du tiers de confiance a été effectué, l'utilisateur peut alors commencer à réaliser des transactions sécurisées avec le prestataire 43 : pour ce faire, il utilise son dispositif physique 13 pour signer un aléa fourni par le prestataire (on parle alors d'authentification) ou un message (on parle alors de signature) grâce à sa clé secrète de dispositif Si, et en y associant le certificat de dispositif correspondant Ci, selon des protocoles standards qui ne font pas l'objet de la présente demande de brevet et ne sont donc pas décrits ici plus en détail.
En d'autres termes, l'invention ne modifie pas le mode d'utilisation d'un dispositif physique pour réaliser une authentification, une signature, ou même faire du chiffrement. Cependant, grâce à l'invention, les prestataires qui ont besoin du certificat de dispositif Ci (par exemple pour vérifier une authentification, ou une signature, ou pour chiffrer un message) ont la possibilité, s'ils le souhaitent, de consulter le champ <info> placé dans une extension du certificat de dispositif Ci. Le contenu de ce champ <info> donne l'assurance aux prestataires 43 qui dialoguent avec un utilisateur 40 que celui-ci est bien en possession d'un dispositif physique 13 de caractéristiques contenues dans le champ <info>.
Comme déjà indiqué précédemment dans ce document, le quadruplet (P0, S0, C0, <info>) peut être le même pour tous les dispositifs physiques d'un même type donné, décrit dans le champ <info> (par exemple pour tous les "dongles" USB produits par un même fabricant), de sorte que tous ces dispositifs portent la même clé privée de dispositif S0. A l'inverse, le quadruplet (P0, S0, C0, <info>) peut être spécifique à un dispositif physique donné. Cette deuxième solution est plus avantageuse en termes de sécurité, et permet de mieux contrer d'éventuelles tentatives de fraudes des utilisateurs. En effet, si tous les dispositifs physiques d'un type donné présentent le même quadruplet (P0, S0, C0, <info>), et si, par malheur, un fraudeur parvient à extraire de l'un des dispositifs (par attaque physique, DPA "Differential Power Analysis" ou attaque par canaux cachés, etc.) la clé privée de dispositif S0, l'utilisation de tous ces dispositifs physiques se trouve remise en cause. En effet, le fraudeur peut alors construire lui-même un dispositif frauduleux, à partir de la clé privée de dispositif S0, ou l'émuler sous forme logicielle. Le tiers de confiance n'a alors plus aucun moyen pour déterminer s'il se trouve en présence d'un véritable dispositif physique, acquis dans des conditions honnêtes, ou du dispositif frauduleux, ce qui s'avère particulièrement problématique.
Si en revanche le quadruplet (P0, S0, C0, <info>) est spécifique à chaque dispositif, il reste toujours possible pour un fraudeur de s'emparer frauduleusement de la clé privée de dispositif S0, mais cette fraude peut être contrée en instaurant une ou plusieurs des mesures suivantes : le tiers de confiance qui délivre les certificats de dispositif Ci met en opposition le quadruplet (P0, S0, C0, <info>) frauduleux, et s'abstient de délivrer des certificats de dispositif Ci aux utilisateurs présentant ce quadruplet lors de la phase d'enregistrement ; le tiers de confiance communique la liste du ou des quadruplets frauduleux qu'elle a pu détecter à l'ACP 10, qui peut alors la publier ou la mettre à disposition de tous les tiers de confiance ou prestataires qui lui font confiance, de façon qu'aucun d'entre eux ne délivre plus de certificats de dispositif Ci aux utilisateurs présentant de tels quadruplets ; enfin, chaque tiers de confiance met en opposition l'ensemble des certificats de dispositif Ci qui ont déjà été délivrés à partir d'un quadruplet identifié comme frauduleux, afin d'empêcher que de tels certificats de dispositif Ci puissent être utilisés pour effectuer de nouvelles transactions. L'invention permet donc la réalisation de transactions sécurisées entre un utilisateur, détenteur d'un dispositif physique, et un ou plusieurs prestataires, tout en assurant la non-traçabilité de l'utilisateur par les différents prestataires. En effet, si le certificat de dispositif Ci est délivré par une autorité de certification indépendante du prestataire, ce dernier n'a accès qu'au certificat de dispositif Ci, et donc au champ d'extension <info> qui lui est associé. Sous réserve que ce champ <info> ne contienne que des informations génériques sur le dispositif physique, le prestataire ne peut alors pas établir de lien entre l'identifiant Idi associé au certificat de dispositif Ci et le dispositif physique lui-même (identifié dans le mode de réalisation décrit ci-dessus par un quadruplet (P0, S0, C0, <info>) unique).
Si en revanche on souhaite assurer une certaine traçabilité du dispositif physique, par exemple uniquement par l'ACP et les autres autorités de certification, on peut choisir d'ajouter dans le champ <info> un élément d'identification du dispositif physique, tel que son numéro de série par exemple. Pour maintenir, vis-à-vis de l'utilisateur, une garantie de non-traçabilité par les prestataires, il est alors nécessaire de ne pas recopier ce numéro de série dans le champ d'extension <info> du certificat de dispositif Ci.
A l'inverse, si l'on souhaite au contraire permettre la traçabilité du dispositif physique par au moins certains des prestataires, il suffit de recopier le numéro de série du dispositif dans le champ <info> des certificats de dispositif Ci de tous les prestataires concernés.

Claims

REVENDICATIONS
1. Procédé de contrôle de transactions sécurisées mettant en œuvre un dispositif physique détenu par un utilisateur et portant au moins une première paire de clés asymétriques, comprenant une première clé de dispositif publique (P0) et une première clé de dispositif privée (S0) correspondante, ladite première clé de dispositif privée (S0), caractérisé en ce que ledit procédé de contrôle comprend les étapes suivantes : préalablement à la mise en service dudit dispositif physique, une première étape de certification de ladite première clé de dispositif publique (P0) et d'informations (<info>) caractéristiques du dispositif physique par signature au moyen d'une première clé de certification (ST) d'une autorité de certification particulière (ACP), délivrant un certificat usine (C0), après vérification que ladite clé de dispositif privée S0 est logée dans une zone inviolable (132 ; 1321) dudit dispositif physique (13) ; une étape de génération d'au moins une deuxième paire de clés asymétriques, comprenant une deuxième clé de dispositif publique (Pi) et une deuxième clé de dispositif privée (Si) (i=l,...), ladite deuxième clé de dispositif privée (Si) étant logée dans une zone inviolable (1322) dudit dispositif (13) ; une deuxième étape de certification de ladite deuxième clé de dispositif publique (Pi) par signature au moyen de ladite première clé de dispositif privée (S0), délivrant un certificat provisoire (C\) ; une première étape de vérification (E33) dudit certificat usine (C0) au moyen d'une deuxième clé de certification (Pτ) correspondant à ladite première clé de certification (ST) ; une deuxième étape de vérification (E34) dudit certificat provisoire (Ci) au moyen de ladite première clé de dispositif publique (P0) ; en cas de vérification positive desdits certificat usine (C0) et certificat provisoire (Ci), une étape de délivrance (E35) par un tiers de confiance
(44) d'un certificat de dispositif (Ci) correspondant à la signature au moins de ladite deuxième clé de dispositif publique (Pi), d'un identifiant (Idi) dudit utilisateur et desdites informations (<info>) caractéristiques du dispositif.
2. Procédé de contrôle selon la revendication 1, caractérisé en ce qu'il est mis en œuvre pour au moins deux deuxièmes paires de clés asymétriques dudit dispositif, associées chacune à un identifiant (Idi) dudit utilisateur (40), et en ce que chacun desdits certificats de dispositif (Ci) délivrés lors desdites étapes de délivrance (E35) lie l'une desdites deuxièmes clés de dispositif publiques (Pi) audit identifiant (Idi) associé.
3. Procédé de contrôle selon l'une quelconque des revendications 1 et 2, caractérisé en ce que lesdites informations caractéristiques dudit dispositif physique appartiennent au groupe comprenant les informations suivantes :
- type de dispositif physique ;
- identification du fabricant dudit dispositif physique ;
- type d'algorithme cryptographique utilisé par ledit dispositif physique ;
- numéro de série dudit dispositif physique.
4. Procédé de contrôle selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, lors d'une transaction, ledit prestataire consulte lesdites informations (<info>) caractéristiques dudit certificat de dispositif (Ci).
5. Procédé de contrôle selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'il comprend une phase de personnalisation dudit dispositif physique, au cours de laquelle ladite première paire de clés asymétriques, ledit certificat usine (C0), et lesdites informations (<info>) dudit certificat usine sont associées de manière unique audit dispositif physique, de iàçon à réduire les risques de transactions frauduleuses.
6. Procédé de contrôle selon l'une quelconque des revendications 1 à 5, caractérisé en ce que lesdits certificat usine (C0) et certificat provisoire (Ci) sont stockés dans au moins une zone de mémoire en lecture libre (131 ; 1311, 1312) dudit dispositif physique.
7. Procédé de contrôle selon l'une quelconque des revendications 1 à 6, caractérisé en ce que l'une au moins desdites première et deuxième étapes de vérification est effectuée par ledit prestataire.
8. Procédé de contrôle selon l'une quelconque des revendications 1 à 7, caractérisé en ce que ladite première clé de certification (ST) est une clé privée et ladite deuxième clé de certification (Pτ) est une clé publique.
9. Procédé de contrôle selon l'une quelconque des revendications 1 à 8, caractérisé en ce que ladite autorité de certification particulière utilise une clé symétrique (K), de sorte que ladite première clé de certification (ST) et ladite deuxième clé de certification (Pτ) sont identiques.
10. Dispositif physique (13) détenu par un utilisateur (40) et destiné à être utilisé lors de transactions sécurisées, ledit dispositif physique portant au moins une première paire de clés asymétriques, comprenant une première clé de dispositif publique (P0) et une première clé de dispositif privée (S0) correspondante, caractérisé en ce qu'il porte également un certificat usine (C0), délivré après vérification que ladite clé de dispositif privée S0 est logée dans une zone inviolable (132 ; 1321) dudit dispositif physique (13), correspondant à la signature de ladite première clé de dispositif publique (P0) et d'informations (<info>) caractéristiques du dispositif physique par une première clé de certification (ST) d'une autorité de certification particulière (ACP), au moins une deuxième paire de clés asymétriques comprenant une deuxième clé de dispositif publique (Pi) et une deuxième clé de dispositif privée (Si) correspondante, ladite première clé de dispositif privée (S0) étant logée dans au moins une zone inviolable dudit dispositif, et un certificat provisoire (Ci) correspondant à la signature de ladite deuxième clé de dispositif publique (Pi) par ladite première clé de dispositif privée
(So), et en ce que ledit certificat usine (C0) est stocké dans ledit dispositif physique préalablement à sa mise en service.
11. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en œuvre d'au moins une étape du procédé de contrôle de transactions sécurisées selon l'une quelconque des revendications 1 à 9. 12. Système de contrôle de transactions sécurisées sur un réseau de communication (42), mettant en œuvre un dispositif physique (13) détenu par un utilisateur (40) et portant au moins une première paire de clés asymétriques, comprenant une première clé de dispositif publique (P0) et une première clé de dispositif privée (S0) correspondante, caractérisé en ce qu'il comprend au moins : un serveur de certification particulière (ACP, 45) relié audit réseau, délivrant audit dispositif physique, après vérification que ladite clé de dispositif privée S0 est logée dans une zone inviolable (132 ; 1321) dudit dispositif physique (13) et préalablement à sa mise en service, un certificat usine (C0) correspondant à la signature de ladite première clé de dispositif publique (P0) et d'informations (<info>) caractéristiques du dispositif physique par une première clé de certification (ST) dudit serveur de certification particulière (ACP) ; un tiers de confiance (44) vérifiant ledit certificat usine (C0) au moyen d'une deuxième clé de certification (Pτ) correspondant à ladite première clé de certification (ST), et un certificat provisoire (Ci) stocké dans ledit dispositif physique, correspondant à la signature d'une deuxième clé de dispositif publique (Pi) par ladite première clé de dispositif privée (S0), au moyen de ladite première clé de dispositif publique (P0), et délivrant audit utilisateur, en cas de vérification positive, un certificat de dispositif (Ci) correspondant à la signature par ledit tiers de confiance (44) au moins de ladite deuxième clé de dispositif publique (Pi), d'un identifiant (Idi) dudit utilisateur et des informations (<info>) caractéristiques du dispositif, ledit tiers de confiance étant relié audit réseau (42).
EP06777839A 2005-07-26 2006-07-18 Procédé de contrôle de transactions sécurisées mettant en oeuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système et programme d'ordinateur correspondants Withdrawn EP1908215A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0507991 2005-07-26
PCT/EP2006/064384 WO2007012584A1 (fr) 2005-07-26 2006-07-18 Procédé de contrôle de transactions sécurisées mettant en oeuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système et programme d'ordinateur correspondants

Publications (1)

Publication Number Publication Date
EP1908215A1 true EP1908215A1 (fr) 2008-04-09

Family

ID=36129841

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06777839A Withdrawn EP1908215A1 (fr) 2005-07-26 2006-07-18 Procédé de contrôle de transactions sécurisées mettant en oeuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système et programme d'ordinateur correspondants

Country Status (3)

Country Link
US (1) US20080250246A1 (fr)
EP (1) EP1908215A1 (fr)
WO (1) WO2007012584A1 (fr)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7318050B1 (en) * 2000-05-08 2008-01-08 Verizon Corporate Services Group Inc. Biometric certifying authorities
EP1911194A1 (fr) * 2005-07-26 2008-04-16 France Télécom Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d'ordinateur correspondants
US8527770B2 (en) * 2006-07-20 2013-09-03 Research In Motion Limited System and method for provisioning device certificates
JP5081763B2 (ja) * 2008-08-13 2012-11-28 株式会社日立メディアエレクトロニクス 光情報検出方法、光ピックアップ及び光情報記録再生装置
US8370481B2 (en) * 2009-05-13 2013-02-05 Verizon Patent And Licensing Inc. Inventory management in a computing-on-demand system
US9832019B2 (en) 2009-11-17 2017-11-28 Unho Choi Authentication in ubiquitous environment
US9918226B2 (en) * 2013-12-30 2018-03-13 Apple Inc. Spoofing protection for secure-element identifiers
US9449346B1 (en) 2014-05-21 2016-09-20 Plaid Technologies, Inc. System and method for programmatically accessing financial data
US9595023B1 (en) 2014-05-21 2017-03-14 Plaid Technologies, Inc. System and method for facilitating programmatic verification of transactions
EP3288214B1 (fr) * 2015-04-23 2021-03-03 Unho Choi Authentification dans un environnement omniprésent
US10067802B2 (en) * 2015-07-02 2018-09-04 Red Hat, Inc. Hybrid security batch processing in a cloud environment
CA3119897C (fr) 2015-09-08 2022-08-09 Plaid Inc. Autorisation securisee d'un acces a des comptes d'utilisateur, comprenant la suppression d'autorisation securisee d'un acces a des comptes d'utilisateur
US10726491B1 (en) 2015-12-28 2020-07-28 Plaid Inc. Parameter-based computer evaluation of user accounts based on user account data stored in one or more databases
US10984468B1 (en) 2016-01-06 2021-04-20 Plaid Inc. Systems and methods for estimating past and prospective attribute values associated with a user account
US11468085B2 (en) 2017-07-22 2022-10-11 Plaid Inc. Browser-based aggregation
US10878421B2 (en) 2017-07-22 2020-12-29 Plaid Inc. Data verified deposits
GB2566107B (en) * 2017-09-05 2019-11-27 Istorage Ltd Methods and systems of securely transferring data
US11316862B1 (en) 2018-09-14 2022-04-26 Plaid Inc. Secure authorization of access to user accounts by one or more authorization mechanisms
CN110535657B (zh) * 2019-08-21 2022-03-04 上海唯链信息科技有限公司 一种多个私钥管理设备相互身份认证的方法及装置
US11887069B2 (en) 2020-05-05 2024-01-30 Plaid Inc. Secure updating of allocations to user accounts
US11327960B1 (en) 2020-10-16 2022-05-10 Plaid Inc. Systems and methods for data parsing

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030110084A1 (en) * 1998-03-04 2003-06-12 Martin Forest Eberhard Secure content distribution system
US20010011238A1 (en) * 1998-03-04 2001-08-02 Martin Forest Eberhard Digital rights management system
US6513117B2 (en) * 1998-03-04 2003-01-28 Gemstar Development Corporation Certificate handling for digital rights management system
US7778934B2 (en) * 2000-04-17 2010-08-17 Verisign, Inc. Authenticated payment
US8601566B2 (en) * 2001-10-23 2013-12-03 Intel Corporation Mechanism supporting wired and wireless methods for client and server side authentication
JP2004048660A (ja) * 2002-05-24 2004-02-12 Sony Corp 情報処理システムおよび方法、情報処理装置および方法、記録媒体、並びにプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007012584A1 *

Also Published As

Publication number Publication date
US20080250246A1 (en) 2008-10-09
WO2007012584A1 (fr) 2007-02-01

Similar Documents

Publication Publication Date Title
EP1908215A1 (fr) Procédé de contrôle de transactions sécurisées mettant en oeuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système et programme d&#39;ordinateur correspondants
EP3590223B1 (fr) Procédé et dispositif pour mémoriser et partager des données intégrés
EP3395006B1 (fr) Procédé de gestion d&#39;une identité de confiance
WO2007012583A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d&#39;ordinateur correspondants
WO2003056750A2 (fr) Systeme cryptographique de signature de groupe
WO2011117486A1 (fr) Infrastructure non hierarchique de gestion de bi-cles de securite de personnes physiques
EP3446436A1 (fr) Procédé d&#39;obtention par un terminal mobile d&#39;un jeton de sécurité
FR3035248A1 (fr) Systeme-sur-puce a fonctionnement securise et ses utilisations
EP2306668B1 (fr) Système et procédé de transaction sécurisée en ligne
WO2003060841A1 (fr) Procede cryptographique de revocation a l&#39;aide d&#39;une carte a puce
WO2018002351A1 (fr) Procede d&#39;authentification de donnees de paiement, dispositifs et programmes correspondants
EP2954449B1 (fr) Authentification de signature manuscrite numérisée
EP3479325B1 (fr) Procédé d&#39;authentification de données de paiement, dispositifs et programmes correspondants.
FR2896646A1 (fr) Certification avec autorite de certification distribuee
CA2831167C (fr) Infrastructure non hierarchique de gestion de bi-cles de securite de personnes physiques ou d&#39;elements (igcp/pki)
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
FR3073111A1 (fr) Procede et dispositif pour memoriser et partager des donnees integres
FR2898423A1 (fr) Procede securise de configuration d&#39;un dispositif de generation de signature electronique.
EP3029878B1 (fr) Procédé de transmission de secret à durée de vie limitée pour réaliser une transaction entre un terminal mobile et un équipement
WO2017077210A1 (fr) Procédé de verification d&#39;identité lors d&#39;une virtualisation

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: 20071217

AK Designated contracting states

Kind code of ref document: A1

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

RIN1 Information on inventor provided before grant (corrected)

Inventor name: ARDITTI, DAVID

Inventor name: FRISCH, LAURENT

Inventor name: CARON, SIDONIE

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20130201