• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The invention relates to a method for authenticating a first electronic entity (C) by a second electronic entity (H). The first electronic entity (C) implements the following steps: - receiving a first challenge (HCH) from the second electronic entity (H); - generating a second challenge (CCH) based on a current value of a counter (SQC) and a first secret key (K-ENC); - Generation of a cryptogram (CAC) according to the first challenge (HCH) and a second secret key (S-MAC); - Transmission to the second electronic entity (H) of a response including the cryptogram (CAC) without transmission of the second challenge (CCH).
    公开号:FR3022053A1
    申请号:FR1455185
    申请日:2014-06-06
    公开日:2015-12-11
    发明作者:Emmanuelle Dottax；Florian Galdo；Jean-Philippe Vallieres
    申请人:Oberthur Technologies SA；
    IPC主号:
    专利说明:

    [0001] TECHNICAL FIELD TO WHICH THE INVENTION RELATES The present invention relates to the establishment of a secure channel between two electronic entities.
    [0002] It relates more particularly to a method of authentication of a first electronic entity by a second electronic entity, and an electronic entity implementing such a method. The invention applies particularly advantageously in the case where a cryptographic key used by the first electronic entity to generate a challenge for the second electronic entity is also used to generate a session key for encrypting data exchanges between the first electronic entity electronic entity and the second electronic entity. BACKGROUND When a first electronic entity wishes to authenticate with a second electrical entity by proving its knowledge of a secret (generally a cryptographic key) without transmitting this secret, it is possible to carry out a challenge exchange -response (or "challenge-response" according to the Anglo-Saxon name) between the two electronic entities: the second electronic entity sends a challenge to the first electronic entity, which must to authenticate return an expected response associated with the challenge, typically the result of a calculation combining the secret and the challenge received. In order to perform mutual authentication, the first electronic entity also sends a challenge to the second electronic entity, which must determine the expected response to this other challenge and send it to the first electronic entity. The challenges used are generally random numbers generated by the electronic entity issuing the challenge in order to prevent a malicious third party from being able to authenticate itself by simply repeating (sometimes called "replay") a response previously sent by the former. electronic entity.
    [0003] These random values may furthermore be used, in combination with a cryptographic key known only from the two electronic entities, to generate session keys for securing the exchange of data between the two electronic entities. The session keys thus generated are thus different for each exchange session between the two electronic entities.
    [0004] The use of random values generated respectively in each of the two electronic entities, however, makes it necessary to exchange data bidirectionally to complete the process of mutual authentication and generation of session keys (since each entity must receive the random value generated by the other entity). To avoid this and thus allow the implementation of such processes without having to wait for an immediate return of the first electronic entity (hereinafter called "slave"), it has been planned to use, instead of the value random generated by the first electronic entity, a so-called "pseudo-random" value, based for example on the value of a counter of the first electronic entity. The second electronic entity (hereinafter referred to as "master" or "host"), which is also aware of the value of the counter, can thus prepare in advance the data to be sent (typically in the form of commands destined for the counter). electronic entity slave), by encrypting this data by means of the session key obtained depending in particular on the value of the counter, and transmit them in batches. This technique is used for customization of secure electronic entities (such as microcircuit cards or secure integrated circuits) but can also be used in other contexts. Processes as described above are for example described in the technical specification "GlobalPlatform Card Technology - Secure Channel Protocol 03 - Card Specification v 2.2 Amendment D", version 1.1, September 2009.
    [0005] This specification notably provides that the response of the slave electronic entity to the challenge of the host electronic entity is accompanied by the challenge generated by the slave electronic entity and intended for the host electronic entity, as is customary when a mutual authentication is sought. OBJECT OF THE INVENTION In this context, the present invention proposes a method of authentication of a first electronic entity by a second electronic entity, characterized by the following steps implemented by the first electronic entity: - reception of a first challenge from the second electronic entity; generating a second challenge based on a current value of a counter and a first secret key; generating a cryptogram according to the first challenge and a second secret key; transmission to the second electronic entity of a response including the cryptogram without transmission of the second challenge. The absence of transmission of the second challenge makes it possible to prevent an attacker from attempting to discover the first secret key by observing the 10 values of the second challenge transmitted during repeated implementations of the method, as is the case when an attack by cryptoanalysis. The absence of transmission of the second challenge is however not detrimental to the continuation of the authentication process since it is in this case a pseudo-random value, which the second electronic entity 15 can determine on the based on a datum representative of the current value of the counter. The second secret key is for example a session key generated in particular on the basis of the first challenge. As explained below, the first challenge may be a random value generated by the second electronic entity, in which case the second secret key is always different. The response may instead include, for example instead of the second challenge, a random number generated by the first electronic entity or a predetermined value. It can further be provided that the response includes said current value. In practice, the random number or the predetermined value may be located in the response to a location provided for a card challenge according to the Secure Channel Protocol 03, the technical specification of which is mentioned above. The cryptogram and the second challenge may also be respectively a card cryptogram and a card challenge compliant with the Secure Channel Protocol 03. The method may furthermore comprise a step of generating a session key as a function of a cryptographic key, the first challenge and the second challenge. According to an implementation possibility described below, this cryptographic key is the first secret key. Then there may be a step of exchange, between the first electronic entity and the second electronic entity, of encrypted data by means of an encryption algorithm using the session key.
    [0006] As already indicated, the second secret key can also be one of the session keys generated. The cryptogram is then generated on the basis of a different session key for each implementation of the method. An attacker can not in this case deduce from the observation of the successive values of the cryptogram.
    [0007] In practice, the step of generating the cryptogram can use the second challenge. The authentication method may further comprise the following steps implemented by the second electronic entity: determining the second challenge based on a data representative of the current value of the counter and the first secret key; determining another cryptogram according to the second challenge and a third secret key (possibly identical to the second secret key); - Transmission of the other cryptogram to the first electronic entity for authentication of the second electronic entity by the first electronic entity. The first electronic entity is for example a microcircuit card or a secure integrated circuit; the second electronic entity may be a remote server or a telecommunications terminal. The invention also proposes an electronic entity comprising means for receiving a first challenge from another electronic entity, means for generating a second challenge based on a current value of a counter and a first secret key, means for generating a cryptogram according to the first challenge and a second secret key and means for transmitting to the other electronic entity a response including the cryptogram without transmission of the second challenge . The optional features presented above with respect to the authentication method may also apply to this electronic entity. DETAILED DESCRIPTION OF AN EXEMPLARY EMBODIMENT The following description with reference to the accompanying drawings, given as non-limiting examples, will make it clear what the invention consists of and how it can be achieved. In the accompanying drawings: FIG. 1 represents the main steps of a process for initiating a secure exchange of data between a first electronic entity and a second electronic entity in accordance with the teachings of the invention; FIG. 2 represents the main steps of a mutual authentication process which follows the initiation process of FIG. 1.
    [0008] FIG. 1 represents a process for initiating a secure exchange of data between a first electronic entity and a second electronic entity in accordance with the teachings of the invention. Each of the first and second electronic entities comprises a communication interface by means of which the relevant electronic entity can transmit and / or receive data on a communication medium, where the data is represented by signals, for example electrical signals or optics. The first electronic entity and the second electronic entity can thus exchange data either directly (their respective communication interfaces being connected to one another) or via one or more other electronic entities (for example computers), possibly connected to each other and to the first and second electronic entities by means of a computer network. Each of the first and second electronic entities is for example an electronic device which comprises, in addition to the communication interface mentioned above, a processor and at least one memory capable of storing the data received and manipulated by the electronic entity. This memory also stores computer program instructions which, when executed, enable the electronic entity to implement the methods described below. As a variant, at least one of the electronic entities could be implemented in the form of a specific application integrated circuit (or ASIC according to the English acronym). In the example which follows, the first electronic entity is a microcircuit card C (or ICC for "Integrated Circuit Card") and the second electronic entity is a terminal H. The invention however applies to other types of electronic entities. By way of example, the first electronic entity may alternatively be a secure integrated circuit (or SE for "Secure Element"), an eSE ("embedded secure element" for embedded security element) or an "embedded universal integrated circuit" (eUICC). An integrated and integrated circuit board card.) A secure element comprises a processor of its own, different from the processor of the host electronic device in which it is embedded or embedded, and a non-volatile memory for the storage of programs. The secure element is, for example, in accordance with ISO / IEC 7816 standards, Common Criteria standards and / or GlobalPlatform Card Specification v 2.2.1, the second electronic entity could be a server. remote connected to the first electronic entity through a wireless connection, or a server directly connected to the second entity through the The method represented in FIG. 1 allows the launching of a mutual authentication process between the two electronic entities, on the initiative of the terminal H which here acts as the master or host electronic entity. .
    [0009] During a step E2, the terminal H generates a random challenge HCH host. The terminal H then transmits (step E4) to the microcircuit card C an initialization command of the mutual authentication process, for example a command of the type INITALIZE UPDATE, accompanied by the host challenge HCH. As already indicated, this command can be transmitted directly from the terminal H to the microcircuit card C (the communication interfaces being for example respectively a card reader equipping the terminal H and the contacts of the microcircuit card C), or by intermediate of one or more other electronic entities. The microcircuit card C receives the initialization command and the host challenge HCH in step E6. The microcircuit card C then proceeds to the incrementation of a SOC counter in step E8. A new counter value must indeed be used to generate new session keys as explained below. Alternatively, the incrementation of the counter is performed by the microcircuit card C after receiving the EXTERNAL AUTHENTICATE command described below.
    [0010] Step E8 is followed by step E10 at which a pseudo-random value CCH is generated (for example by means of a key derivation process) as a function of the current value of the counter SQC (value after incrementation of the step E8), a K-ENC cryptographic key stored in the microcircuit card C and an identifier AID of the application for which the establishment of the secure channel is performed. The generation of the pseudo-random value CCH is for example carried out in accordance with the section "6.2.2.1 Card Challenge" in the document "GlobalPlatform Card Technology - Secure Channel Protocol 03 - Card Specification and 2.2 Amendment D" already mentioned. . Note that the cryptographic key K-ENC used here for the generation of the pseudo-random value CCH is a static key, which therefore has a constant value during successive implementations of the process (with a view, in each case, of the establishment of a new exchange session between the terminal H and the microcircuit card C). Moreover, as will be explained below, the pseudo-random value CCH is used as a challenge of the microcircuit card C for authentication of the terminal H with the microcircuit card C. It then proceeds to the step E12 to which the microcircuit card C generates different SK session keys. For example, each session key SK is generated, by means of a key derivation process, on the basis of a corresponding (so-called static) cryptographic key K memorized in the microcircuit card C, of the HCH host challenge. (received in step E6) and the pseudo-random value CCH (generated in step E10). For example, the generation of the session keys SK is performed in accordance with the "6.2.1 AES Session Keys" clause in the "GlobalPlatform Card Technology - Secure 30 Channel Protocol 03 - Card Specification and 2.2 Amendment D" document already mentioned. . Among the session keys SK, an S-ENC encryption session key is generated in particular on the basis of the K-ENC cryptographic key already mentioned, the host challenge HCH and the pseudo-random value CCH. The microcircuit card C then determines in step E14 the authentication cryptogram of the card CAC, for example by means of a key derivation process, on the basis of one of the session keys SK (for example an S-MAC integrity verification session key distinct from the S-ENC encryption session key), the HCH host challenge (received in step E6) and the pseudo-random value CCH (generated at step E10). The identification of the authentication cryptogram of the CAC card is, for example, carried out in accordance with the section "6.2.2.2 Card Authentication Cryptogram" in the document "GlobalPlatform Card Technology - Secure Channel Protocol 03 - Card Specification y 2.2 Amendment D". "already mentioned.
    [0011] The microcircuit card C then generates in step E16 a random number RAND, for example of length (in bytes) equal to that of the pseudo-random value CCH (here 8 bytes). The microcircuit card C then emits at step E18 its response to the initialization command (see steps E4 and E6 above), which response includes the random number RAND generated in step E16, the CAC cryptogram. generated in step E14 and the current value of the SOC counter. Note that, due to the use of a random number RAND of the same length as the pseudo-random value CCH, the response has the length predicted in the document "GlobalPlatform Card Technology - Secure Channel Protocol 03 - Card Specification". 2.2 Amendment D "already mentioned, here 32 bytes. However, since this response does not contain the pseudo-random value CCH as defined by the previously mentioned document as a card challenge (but here a random number RAND), it will not be possible to malicious third party to attempt to deduce the cryptographic key K-ENC (used for the generation of the pseudo-random value as indicated above) by the observation of the pseudo-random value CCH, typically during successive implementations of a lot of such mutual authentication processes. According to one conceivable variant, the microcircuit card C could return a predetermined or deterministic value instead of the random number RAND (in which case the step E16 of generating the random number RAND could be omitted). According to another conceivable variant, the microcircuit card C could send no data instead of the random number RAND. The response emitted by the microcircuit card C in step E18 could then for example contain only the CAC cryptogram and the SQC counter. According to another embodiment, which can be combined with the various embodiments which have just been indicated, the SQC counter could not be included in the response transmitted by the microcircuit card C in step E18. The terminal H receives the response in step E20 and can thus store in particular the authentication cryptogram of the CAC card included in this response. This completes the initialization phase of the mutual authentication process; the mutual authentication process can then continue in step E21 as explained below with reference to FIG. 2. In step E21, the terminal H determines the pseudo-random value CCH 15 according to a method identical to that used by the microcircuit card C in step E10, using the current value of the counter SQC, the cryptographic key K-ENC and the identifier AID. Note that, in the example described here, the terminal received the current value of the counter in step E20 and was thus able to store a datum representative of this current value. In the embodiments where the value of the counter SQC is not transmitted by the microcircuit card in step E18, it is possible, for example, for the counter to have an initial value equal to 0 (or another predetermined value) when of the first exchange (first session) and that the terminal H increments a datum representative of the current value of the counter SQC at each new session. It may optionally be provided in addition that the terminal H can issue a command (for example of the GET DATA type) in order to obtain in response (from the microcircuit card C) the current value of the counter SQC. The cryptographic key K-ENC is itself stored in the terminal H (being a shared secret between the terminal H and the microcircuit card C). The value of the identifier AID is known from the application of the terminal H when the application installed on the terminal H and the application installed on the microcircuit card C are provided by the same provider. The value of the identifier AID is then written in the code of the application of the terminal H.
    [0012] Alternatively, the value of the identifier AID is transmitted by the microcircuit card C, after receiving a command to that effect. The method continues in step E22 in which the terminal H in turn determines the cryptogram of the card CAC *, using the same process and the same data used by the microcircuit card C in step E14. To do this, the terminal H generates in particular the S-MAC session key used, with the host challenge HCH (generated by the terminal in step E2) and the pseudo-random value CCH (determined by the terminal H in step E21), to determine the cryptogram of the card CAC *.
    [0013] It can be expected that the terminal H generates at this stage other session keys, in particular the already mentioned session key S-ENC (calculated by the terminal H on the basis of the stored cryptographic key K-ENC, of the challenge of HCH host generated in step E2 and the pseudo-random value CCH determined in step E21).
    [0014] The terminal H then compares, in step E24, the cryptogram CAC * determined in step E22 with the cryptogram CAC received at step E20. Note that this step E24 is optional in predictive mode. In fact, this mode makes it possible to pre-generate a set of session keys, and thus makes it possible to prevent the microcircuit card C and the terminal H from being connected. In this case, the card issues a response, but the terminal is not necessarily connected with the card C and therefore does not analyze this response. If the result of the comparison is positive (that is to say if the calculated cryptogram CAC * is equal to the received cryptogram CAC), the microcircuit card C has correctly answered the challenge of the terminal H and has therefore authenticated with of the terminal H. The mutual authentication process can then continue in the step E28 described below (for authentication of the terminal H by the microcircuit card C). If the result of the comparison of the step E24 is negative (that is to say if the calculated cryptogram CAC * is different from the received cryptogram CAC), the authentication of the microcircuit card C by the terminal H has failed. and the terminal H then proceeds to step E26 with the treatment of this anomaly, for example by terminating the data exchange with the microcircuit card C. When the mutual authentication process continues (in case of a positive result of the comparison in step E24), the terminal H proceeds to step E28 to the generation of an authentication cryptogram of the host HAC. The authentication cryptogram of the host HAC is for example generated by means of a key derivation process and on the basis of one of the session keys SK (for example the integrity check session key S MAC), the host challenge HCH (generated in step E2) and the pseudo-random value CCH (determined in step E21). The identification of the authentication cryptogram of the host HAC is for example carried out in accordance with the section "6.2.2.3 Host Authentication Cryptogram" in the "GlobalPlatform Card Technology - Secure Channel Protocol 03 - Card Specification y 2.2 Amendment" document. D "already mentioned. In order to obtain an authentication cryptogram of the host HAC different from the authentication cryptogram of the card CAC while the key derivation processes used in each case are identical, it is provided in the example described here that the process key derivation applies not only to the data mentioned above (S-MAC session key, HCH host challenge, CCH pseudo-random value), but also to a derivation constant (for example a length of 1 byte) having different values respectively in the case of the generation of the authentication cryptogram of the card CAC (steps E14 and E22), where the derivative constant has for example the value 0, and in the case of the generation the authentication cryptogram of the HAC host (steps E28 and E34 described below), where the derivation constant has for example the value 1. The terminal H then transmits to the microcircuit card C the generated HAC cryptogram in step E28, for example within an EXTERNAL AUTHENTICATE command. It is also possible to transmit a message authentication code on this occasion so that the microcircuit card can verify the integrity of the transmitted HAC cryptogram. The microcircuit card C receives the cryptogram HAC in the step E32 and, after a possible verification of the message authentication code when such a code is transmitted, stores the cryptogram HAC for later comparison (see below). step E36). The microcircuit card C then determines for its part in step E34 the expected value HAC * of the authentication cryptogram of the host on the basis of the same process and the same data as those used in step E28. The microcircuit card C uses in this step the session key S-MAC generated in step E12, the host challenge HCH received in step E6, the pseudo-random value CCH generated in step E10 and the predetermined derivation constant associated with the calculation of the authentication cryptogram of the host (of value 1 in the example described here). The microcircuit card can thus compare in step E36 the cryptogram HAC received in step E32 and the cryptogram HAC * determined (by the microcircuit card C) in step E34. If the received cryptogram HAC and the calculated cryptogram HAC * are equal (positive result of the comparison), the terminal H has correctly authenticated with the microcircuit card C and the mutual authentication process therefore successfully ends according to the modalities explained below (steps E40 and E42). On the other hand, if the received cryptogram HAC and the calculated cryptogram HAC * are different (negative result of the comparison), the terminal H is not authenticated by the microcircuit card C and the opening of a secure channel between the terminal H and the microcircuit card C is impossible. For example, it is provided in this case that the microcircuit card C sends in step E38 an error status to the terminal H in response to the EXTERNAL AUTHENTICATE command.
    [0015] When the result of the comparison of the step E36 is positive, the microcircuit card C proceeds to the step E40 at the emission of a response including a correct operating status OK to the terminal H. The terminal H receives this response to step E42, which confirms the success of the mutual authentication process.
    [0016] We note that at no time (either during the initiation phase described in Figure 1 or during the phase of mutual authentication stricto sensu described in Figure 2) the challenge of the microcircuit card C intended for the terminal H (that is to say here the pseudo-random value CCH) has been transmitted from the microcircuit card C to the terminal H.
    [0017] As the mutual authentication process is successfully completed, secure data exchanges can be implemented between the H terminal and the microcircuit card C (step E44), for example by encrypting the data exchanged by means of an algorithm. symmetric encryption using the S-ENC encryption session key.
    权利要求:
    Claims (16)
    [0001]
    REVENDICATIONS1. A method of authenticating a first electronic entity (C) by a second electronic entity (H), characterized by the following steps implemented by the first electronic entity (C) - receiving (E6) a first challenge (HCH ) from the second electronic entity (H); - generating (E10) a second challenge (CCH) based on a current value of a counter (SQC) and a first secret key (K-ENC); generating (E14) a cryptogram (CAC) according to the first challenge (HCH) and a second secret key (S-MAC); - Transmission (E18) to the second electronic entity (H) of a response including the cryptogram (CAC) without transmission of the second challenge (CCH).
    [0002]
    2. The authentication method according to claim 1, wherein the response includes a random number (RAND) generated by the first electronic entity (C).
    [0003]
    The authentication method of claim 2, wherein said random number (RAND) is located in the response at a location provided for a card challenge according to Secure Channel Protocol 03.
    [0004]
    The authentication method of claim 1, wherein the response includes a predetermined value.
    [0005]
    The authentication method of claim 4, wherein said predetermined value is located in response to a location provided for a card challenge according to Secure Channel Protocol 03.
    [0006]
    6. Authentication method according to one of claims 1 to 5, wherein the response includes said current value (SQC).
    [0007]
    7. Authentication method according to one of claims 1 to 6, comprising a step of generating (E12) a session key (SK;) according to a cryptographic key (K-ENC), the first challenge (HCH) and second challenge (CCH).
    [0008]
    The authentication method according to claim 7, wherein the cryptographic key is the first secret key (K-ENC).
    [0009]
    9. Authentication method according to claim 7 or 8, comprising a step (E44) of exchange, between the first electronic entity (C) and the electronic second entity (H), encrypted data by means of an encryption algorithm using the session key (S-ENC).
    [0010]
    The authentication method of claim 7, wherein the generated session key is the second secret key (S-MAC).
    [0011]
    11. Authentication method according to one of claims 1 to 10, wherein the generation step (E14) of the cryptogram (CAC) uses the second challenge (CCH).
    [0012]
    12. Authentication method according to one of claims 1 to 11, characterized in that it comprises the following steps implemented by the second electronic entity (H): - determination of the second challenge (CCH) according to a data representative of the current value of the counter (SQC) and the first secret key (K-ENC); - determination of another cryptogram (HAC) according to the second challenge (CCH) and a third secret key (S-MAC); - Transmission of the other cryptogram (HAC) to the first electronic entity (C) for authentication of the second electronic entity (H) by the first electronic entity (C).
    [0013]
    13. Method according to one of claims 1 to 12, wherein the first electronic entity (C) is a microcircuit card or a secure integrated circuit.
    [0014]
    14. Method according to one of claims 1 to 13, wherein the second electronic entity (H) is a remote server or a telecommunications terminal.
    [0015]
    15. The method as claimed in one of claims 1 to 14, in which the cryptogram (CAC) and the second challenge (CCH) are respectively a card cryptogram and a card challenge compliant with the Secure Channel Protocol 03.
    [0016]
    16. Electronic entity (C) comprising: - means for receiving a first challenge (HCH) from another electronic entity (H); means for generating a second challenge (CCH) according to a current value of a counter (SQC) and a first secret key (K-ENC); means for generating a cryptogram (CAC) according to the first challenge (HCH) and a second secret key (S-MAC); means for transmitting to the other electronic entity (H) a response including the cryptogram (CAC) without transmission of the second challenge (CCH).
    类似技术:
    公开号 | 公开日 | 专利标题
    EP3152860B1|2021-05-05|Method for the authentication of a first electronic entity by a second electronic entity, and electronic entity implementing such a method
    EP3348085A1|2018-07-18|Method for loading a virtual key in a user terminal and associated user terminal
    EP2166728B1|2020-12-02|Verfahren zum Austausch von Daten, beispielsweise von kryptographischen Schlüsseln, zwischen einem Informationssystem und einer elektronischen Einheit, wie beispielsweise einer Mikrochip-Karte
    EP3010175B1|2019-04-10|Replay of a batch of secure commands in a secure channel
    EP3308564B1|2020-11-18|Procédé de chargement d'une clé virtuelle et terminal utilisateur associé
    EP2909963B1|2019-07-31|Electronic signature method with ephemeral signature
    WO2016102833A1|2016-06-30|Secure electronic entity, electronic apparatus and method for verifying the integrity of data stored in such a secure electronic entity
    EP3185468B1|2019-09-25|Data-transmission method, data-receiving method, corresponding devices and programs
    EP3395040A1|2018-10-31|Method of receiving data within an electronic entity and associated electronic entity
    EP3238474B1|2019-03-13|Method for securing contactless transactions
    FR3061618A1|2018-07-06|METHODS IMPLEMENTED BY A DEVICE AND IN A NETWORK, ASSOCIATED ELECTRONIC ENTITY
    FR2991796A1|2013-12-13|METHOD OF SAVING DATA OUTSIDE A SECURE MICROCIRCUIT
    EP3340096B1|2019-08-07|Method for configuring a cryptographic program intended for being run by a terminal
    FR3030817A1|2016-06-24|USER AUTHENTICATION METHOD, SECURE MODULE, ELECTRONIC APPARATUS AND SYSTEM THEREOF
    EP3140951A1|2017-03-15|Electronic entity and method for generating a session key
    WO2016102832A1|2016-06-30|Method for authenticating an application, associated electronic apparatus and computer program
    FR3102024A1|2021-04-16|A method of managing a public key database, a method of authenticating public keys, and server and client devices implementing these methods
    EP3724799A1|2020-10-21|Technique for protecting a cryptographic key by means of a user password
    WO2021165625A1|2021-08-26|Method for calculating a session key, and method for recovering such a session key
    WO2014140456A1|2014-09-18|Method, device and computer program for optimising the creation of a secure application domain between a computer system and an electronic entity
    WO2016034812A1|2016-03-10|Securing of encryption keys for transactions on a device lacking a secure module
    FR3042362A1|2017-04-14|MEANS FOR MANAGING ACCESS TO DATA
    FR3025631A1|2016-03-11|SECURE SELECTION OF AN APPLICATION IN A CHIP OR EQUIVALENT CARD
    FR3029722A1|2016-06-10|METHOD FOR CONDITIONALLY TRANSMITTING DATA FROM A SERVER TO A TERMINAL, TERMINAL AND ASSOCIATED SERVER
    同族专利:
    公开号 | 公开日
    US10581589B2|2020-03-03|
    WO2015185833A1|2015-12-10|
    CN106464498A|2017-02-22|
    CN106464498B|2020-02-21|
    EP3152860B1|2021-05-05|
    KR20170042549A|2017-04-19|
    US20190020469A1|2019-01-17|
    FR3022053B1|2018-02-02|
    EP3152860A1|2017-04-12|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    CN1319337C|2003-07-02|2007-05-30|华为技术有限公司|Authentication method based on Ethernet authentication system|
    US7805611B1|2004-12-03|2010-09-28|Oracle America, Inc.|Method for secure communication from chip card and system for performing the same|
    EP2034458A3|2007-03-09|2009-09-02|ActivIdentity, Inc.|One-time passwords|
    RU2480925C2|2008-06-06|2013-04-27|Телефонактиеболагет Лм Эрикссон |Generation of cryptographic key|
    JP5254697B2|2008-08-05|2013-08-07|株式会社東海理化電機製作所|Communications system|
    US10223743B2|2011-03-29|2019-03-05|Blackberry Limited|Communication system providing near field communication transaction features and related methods|
    WO2012162843A1|2011-06-03|2012-12-06|Research In Motion Limted|System and method for accessing private networks|
    US9106272B2|2011-11-02|2015-08-11|Blackberry Limited|Mobile communications device providing secure element data wiping features and related methods|
    FR2997209B1|2012-10-19|2016-01-01|Titan Germany Ii Gp|SYSTEM AND METHOD FOR SECURING DATA EXCHANGES, USER PORTABLE OBJECT, AND REMOTE DATA DOWNLOAD DEVICE|
    GB201221433D0|2012-11-28|2013-01-09|Hoverkey Ltd|A method and system of providing authentication of user access to a computer resource on a mobile device|
    US9208300B2|2013-10-23|2015-12-08|At&T Intellectual Property I, Lp|Apparatus and method for secure authentication of a communication device|
    US9313660B2|2013-11-01|2016-04-12|At&T Intellectual Property I, Lp|Apparatus and method for secure provisioning of a communication device|
    US9436455B2|2014-01-06|2016-09-06|Apple Inc.|Logging operating system updates of a secure element of an electronic device|
    US9779224B2|2014-05-05|2017-10-03|Securekey Technologies Inc.|Methods and systems for client-enhanced challenge-response authentication|
    US11178124B2|2014-09-02|2021-11-16|Apple Inc.|Secure pairing of a processor and a secure element of an electronic device|
    FR3046000B1|2015-12-21|2018-02-16|Oberthur Technologies|METHOD FOR RECEIVING DATA WITHIN AN ELECTRONIC ENTITY AND ELECTRONIC ENTITY THEREFOR|CN109922027B|2017-12-13|2020-08-28|中国移动通信集团公司|Credible identity authentication method, terminal and storage medium|
    US11025416B1|2018-03-09|2021-06-01|Wells Fargo Bank, N.A.|Systems and methods for quantum session authentication|
    US10812258B1|2018-03-09|2020-10-20|Wells Fargo Bank, N.A.|Systems and methods for quantum session authentication|
    US10728029B1|2018-03-09|2020-07-28|Wells Fargo Bank, N.A.|Systems and methods for multi-server quantum session authentication|
    US10855454B1|2018-03-09|2020-12-01|Wells Fargo Bank, N.A.|Systems and methods for quantum session authentication|
    US10728230B2|2018-07-05|2020-07-28|Dell Products L.P.|Proximity-based authorization for encryption and decryption services|
    US10540146B1|2018-08-20|2020-01-21|Wells Fargo Bank, N.A.|Systems and methods for single chip quantum random number generation|
    US11095439B1|2018-08-20|2021-08-17|Wells Fargo Bank, N.A.|Systems and methods for centralized quantum session authentication|
    US10552120B1|2018-08-20|2020-02-04|Wells Fargo Bank, N.A.|Systems and methods for single chip quantum random number generation|
    US11240013B1|2018-08-20|2022-02-01|Wells Fargo Bank, N.A.|Systems and methods for passive quantum session authentication|
    US10855457B1|2018-08-20|2020-12-01|Wells Fargo Bank, N.A.|Systems and methods for single chip quantum random number generation|
    US10855453B1|2018-08-20|2020-12-01|Wells Fargo Bank, N.A.|Systems and methods for time-bin quantum session authentication|
    US11210664B2|2018-10-02|2021-12-28|Capital One Services, Llc|Systems and methods for amplifying the strength of cryptographic algorithms|
    法律状态:
    2015-05-26| PLFP| Fee payment|Year of fee payment: 2 |
    2015-12-11| PLSC| Publication of the preliminary search report|Effective date: 20151211 |
    2016-05-26| PLFP| Fee payment|Year of fee payment: 3 |
    2017-05-23| PLFP| Fee payment|Year of fee payment: 4 |
    2018-05-25| PLFP| Fee payment|Year of fee payment: 5 |
    2020-05-20| PLFP| Fee payment|Year of fee payment: 7 |
    2020-10-02| CA| Change of address|Effective date: 20200826 |
    2020-10-02| CJ| Change in legal form|Effective date: 20200826 |
    2021-05-19| PLFP| Fee payment|Year of fee payment: 8 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1455185|2014-06-06|
    FR1455185A|FR3022053B1|2014-06-06|2014-06-06|METHOD FOR AUTHENTICATING A FIRST ELECTRONIC ENTITY BY A SECOND ELECTRONIC ENTITY AND ELECTRONIC ENTITY USING SUCH A METHOD|FR1455185A| FR3022053B1|2014-06-06|2014-06-06|METHOD FOR AUTHENTICATING A FIRST ELECTRONIC ENTITY BY A SECOND ELECTRONIC ENTITY AND ELECTRONIC ENTITY USING SUCH A METHOD|
    EP15729547.8A| EP3152860B1|2014-06-06|2015-05-29|Method for the authentication of a first electronic entity by a second electronic entity, and electronic entity implementing such a method|
    US15/316,374| US10581589B2|2014-06-06|2015-05-29|Method for the authentication of a first electronic entity by a second electronic entity, and electronic entity implementing such a method|
    CN201580029825.9A| CN106464498B|2014-06-06|2015-05-29|Method for authenticating a first electronic entity by a second electronic entity and electronic entity|
    KR1020177000494A| KR20170042549A|2014-06-06|2015-05-29|Method for the authentication of a first electronic entity by a second electronic entity, and electronic entity implementing such a method|
    PCT/FR2015/051424| WO2015185833A1|2014-06-06|2015-05-29|Method for the authentication of a first electronic entity by a second electronic entity, and electronic entity implementing such a method|
    [返回顶部]