WO2016102832A1 - Procédé d'authentification d'une application, appareil électronique et programme d'ordinateur associés - Google Patents

Procédé d'authentification d'une application, appareil électronique et programme d'ordinateur associés Download PDF

Info

Publication number
WO2016102832A1
WO2016102832A1 PCT/FR2015/053586 FR2015053586W WO2016102832A1 WO 2016102832 A1 WO2016102832 A1 WO 2016102832A1 FR 2015053586 W FR2015053586 W FR 2015053586W WO 2016102832 A1 WO2016102832 A1 WO 2016102832A1
Authority
WO
WIPO (PCT)
Prior art keywords
app
application
key
processor
secure module
Prior art date
Application number
PCT/FR2015/053586
Other languages
English (en)
Inventor
Emmanuelle Dottax
Philippe Muresianu
Michele Sartori
Original Assignee
Oberthur Technologies
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oberthur Technologies filed Critical Oberthur Technologies
Publication of WO2016102832A1 publication Critical patent/WO2016102832A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G06F21/123—Restricting unauthorised execution of programs by using dedicated hardware, e.g. dongles, smart cards, cryptographic processors, global positioning systems [GPS] devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103—Challenge-response

Definitions

  • the present invention relates to the authentication of executable applications on a processor.
  • It relates more particularly to an application authentication method, and an associated electronic device and computer program.
  • the invention applies particularly advantageously in the case where the processor on which the application is executing exchanges data with a secure module.
  • the application may need to authenticate with the third-party electronic device to ensure that the application it exchanges data with the application provided for this purpose, and not with a malicious program (or "malware").
  • the application transmits to the latter electronic authentication data (for example a signature) prepared by means of a secret key (for example a private key). known only to the application.
  • a secret key for example a private key
  • the present invention proposes a method of authenticating an application executed by a processor of an electronic device, characterized in that it comprises the following steps:
  • the secret key can thus be used for the preparation of the authentication data after receiving the data of an external electronic entity, but is not accessible without these data and therefore can not be used by a malicious person.
  • the encrypted secret key is stored in a rewritable non-volatile memory
  • the decrypted secret key is stored in a random access memory
  • the authentication method comprises steps of receiving a challenge and preparing said authentication data by application to the challenge received from a cryptographic algorithm using the decrypted secret key;
  • said received data item is prepared by the external electronic entity on the basis of data received from the application and a key stored in the external electronic entity;
  • the authentication data are sent to a secure module
  • the challenge is generated, for example by random draw, by the secure module and sent by the secure module to the application;
  • the external electronic entity is the secure module
  • the external electronic entity is a server (and is therefore distinct from the secure module);
  • the secret key is a private key
  • the method comprises a step of transmission by the secure module of a signed message by means of a private key stored in the secure module to a server;
  • the authentication process of the secure module with the application uses a public key stored in the electronic device in association with a message authentication code produced by an external authority;
  • the electronic device is a mobile phone or a digital tablet
  • the electronic device comprises a holding element on a part the body of the user
  • the method comprises a transmission step by applying a signed message using the decrypted secret key to a server;
  • the method comprises a step of decrypting part of an executable code of the application by means of the derived cryptographic key
  • the secure module is a secure element.
  • the authentication method may further comprise the following steps:
  • the authentication method may also include a secure module authentication process with the application.
  • the invention also proposes an electronic apparatus comprising a processor and at least one memory storing an application executable by the processor, the application being designed so that the processor implements a method as proposed above when the application is executed by the processor.
  • the invention proposes that the aforementioned application is a computer program comprising instructions executable by a processor of an electronic device (in particular by the processor of the aforementioned electronic device) and designed so that the processor implement a method as proposed above when these instructions are executed by the processor.
  • FIG. 1 shows schematically the main elements of a first example of a system in which the invention can be implemented;
  • FIG. 2 represents the main steps of a first exemplary authentication method of an application;
  • FIG. 3 represents the main steps of a second exemplary method of authenticating an application
  • FIG. 4 represents the main steps of a third exemplary method of authenticating an application
  • FIG. 5 schematically shows the main elements of a second example of a system in which the invention can be implemented.
  • FIG. 6 represents the main steps of a fourth exemplary method of authenticating an application.
  • FIG. 1 schematically represents the main elements of a first exemplary system, here an electronic device, in which the invention can be implemented.
  • This electronic device is for example a mobile phone, a digital tablet, a connected watch or glasses connected.
  • the electronic device comprises a holding element on a part of the body of the user (for example a bracelet in the case of a connected watch, or branches in the case of connected glasses).
  • processor 10 for example a microprocessor
  • rewritable non-volatile memory 12 for example a rewritable non-volatile memory
  • random access memory 14 for example a rewritable non-volatile memory
  • secure module 20 for example a secure module
  • these elements are part of the aforementioned electronic apparatus. As a variant, these elements could be distributed in several electronic devices forming a system, the processor 10, the non-volatile memory 12 and the random access memory 14 being for example included in one and the same electronic device, whereas the secure module is included in a other electronic device.
  • the rewritable non-volatile memory 12 stores applications whose execution by the processor 10 allows the implementation of data processing methods and data exchange, in particular with the secure module 20.
  • the non-volatile memory rewritable 12 thus memorizes an App application that seeks, during its execution by the processor 10, to authenticate with the secure module 20 and implements for this purpose the steps described below with reference to Figure 2.
  • the rewritable non-volatile memory 12 also stores data used during the processing processes implemented by the processor 10.
  • non-volatile rewritable memory 12 stores the following cryptographic data, used as described below in the context of the method of FIG. 2:
  • App_SK private key allocated to the App application stored in the rewritable non-volatile memory 12 in encrypted form by an AEK cryptographic key (hence the [App_SK] AEK notation adopted in FIG. 1);
  • App_PK public key associated with the private key App_SK (in a PKI for Public Key Infrastructure) and the SIG signature (App_PK, OT_SK) of this public key App_PK.
  • the cryptographic key AEK (with which is encrypted the private key
  • part of the executable code (that is, instructions executable by the processor 10) of the App application can also be encrypted using the cryptographic key AEK.
  • Such an encryption can for example be carried out by the application provider.
  • Yet part of the code is in this case stored in non-volatile memory rewritable 12 without encryption in order to perform the steps described below, at least until decryption of the encrypted part of the code.
  • the SIG signature (App_PK, OT_SK) is obtained (also at the level of the external authority 30) by application to the public key App_PK a signature cryptographic algorithm using a private key of the external authority OT_SK (this private key being used whatever the application concerned).
  • the random access memory 14 can store the data manipulated by these methods, in particular as described below.
  • the secure module 20 is for example a secure element, such as a secure element integrated in the electronic device (or eSE for "embedded Secure Element”).
  • a secure element such as a secure element integrated in the electronic device (or eSE for "embedded Secure Element”).
  • it could be a microcircuit card, for example example of the type UlCC (for "Universal Integrated Circuit Card”) or eUICC (for "Embedded Universal Integrated Circuit Card”), or a secure micro-SD type card.
  • the secure module 20 comprises a processor and a rewritable non-volatile memory. As represented in FIG. 1, this non-volatile rewritable memory notably stores the aforementioned OT_Apps root key and the public key OT_PK associated with the aforementioned private key OT_SK (in a public key infrastructure). These keys have for example been entered in the secure module during a personalization step of this secure module 20 (as schematically shown in dotted lines in Figure 1). According to one possible embodiment, potentially usable when the aforementioned electronic device comprises telecommunication means, these keys could be updated remotely (according to a so-called OTA technique for "Over-The-Air") from a server of the external authority 30.
  • OTA technique for "Over-The-Air for "Over-The-Air
  • the methods implemented by the secure module 20 as described below result from the execution, by the processor of the secure module 20, of program instructions stored in the rewritable non-volatile memory of the secure module 20, or of another memory of the secure module 20.
  • the secure module 20 could be implemented as a specific application integrated circuit (or ASIC for "Application Specified Integrated Circuit"), programmed to implement the methods described below.
  • ASIC Application Specified Integrated Circuit
  • the processor 10 is connected to the secure module 20, for example by means of a bus (or alternatively via a link of ISO 7816 or SPI type or HCI / SWP), and can thus, because of the execution of the instructions of the applications stored in non-volatile memory 12 or possibly in RAM 14, exchange data with the secure module 20.
  • the processor 10 and the secure module 20 could alternatively exchange data via a telephone and / or computer network (for example using GSM and / or UMTS and / or TCP / IP and / or Bluetooth type protocols), especially in the cases mentioned above where the processor 10 and the secure module 20 are not part of the same electronic device.
  • FIG. 2 represents the main steps of a first exemplary method of authenticating an application. Such a method is here implemented in the system of FIG.
  • this method comprises exchanges between the processor 10 and the secure module 20. These exchanges can be made directly between these elements, without setting up a secure channel. However, according to one conceivable variant, it is possible beforehand to establish a secure channel between the processor 10 and the secure module 20 and to carry out the exchanges described below via this secure channel, which makes it possible to prevent a passive attacker from having access (by simple observation) to the data exchanged.
  • the secure module 20 and the processor 10 use, for example, a Diffie-Hellman type schema, each generating an ephemeral key, by signing this ephemeral key with their secret key, verifying the signature made by the ephemeral key. Another module and, in case of verification, deducting from these elements a common secret and session keys to be used to encrypt subsequent exchanges.
  • the method of FIG. 2 starts at step E2 by the sending by the processor 10 (due to the execution of the App application) of the public key App_PK and the signature SIG ( App_PK, OT_SK) associated.
  • the secure module 20 receives the public key App_PK and the signature SIG (App_PK, OT_SK) associated with the step E4.
  • the secure module 20 can thus verify in step E6 the signature received
  • SIG (App_PK, OT_SK) using the public key OT_PK (associated with the private key OT_SK and stored in the secure module as already indicated), for example by applying the signature SIG (App_PK, OT_SK) a cryptographic verification algorithm using the OT_PK public key and comparing the result got to the public key App_PK (possibly transformed by a hash function used to form the signature).
  • the SIG signature (App_PK, OT_SK) can be verified by applying to the public key App_PK and to the received signature SIG (App_PK, OT_SK), a cryptographic signature verification algorithm using the public key OT_KK and producing (directly) a positive or negative result.
  • the secure module 20 terminates the authentication process, for example by sending an error message to the processor 10.
  • step E8 the secure module 20 generates a challenge (or "challenge" according to the English name) SE_Ch, for example by random draw.
  • the secure module 20 then sends in step E10 the challenge SE_Ch and the root key OT_Apps to the processor 10 on which the application App runs.
  • the processor 10 receives the challenge SE_Ch and the root key OT_Apps in the step E12 and then implements the following steps because of the execution of the application App.
  • the processor 10 determines in step E14 the cryptographic key AEK
  • the processor 10 can then decrypt, in step E16, the private key App_SK by application to the encrypted version [App_SK] AEK (stored in the non-volatile memory 12) of a decryption cryptographic algorithm using the cryptographic key AEK determined in FIG. step E14.
  • the private key App_SK thus obtained can be stored in the RAM 14 until the implementation of step E18 described below (and then possibly deleted later).
  • the processor 10 can then proceed to decrypt the encrypted portion of the code of the App application.
  • the processor 10 generates in step E18 a signature SIC by application to the challenge SE_Ch received in step E12 of a signature cryptographic algorithm using the private key App_SK (decrypted in step E16).
  • the processor 10 sends the SIC signature thus obtained to the secure module 20 in step E20.
  • the secure module 20 receives the SIC signature in step E22 and can thus check the SIC signature in step E24 using the public key App_PK (whose signature by the external authority has been verified in step E6), for example by applying to the received SIC signature a cryptographic signature verification algorithm using the public key App_PK, then comparing the result obtained to the challenge SE_Ch generated in step E8.
  • the signature SIC can be verified by applying, to the challenge SE_Ch and the received signature SIC, a cryptographic algorithm for verification of signature using the public key App_PK and producing (directly) a positive or negative result.
  • step E24 If the SIC signature is correctly verified in step E24, the processor 10 on which the application App runs has thus demonstrated that it held the private key App_SK and thus authenticated.
  • FIG. 3 represents the main steps of a second exemplary method of authenticating an application.
  • This method is implemented in a system of the type of that of FIG. 1, in which the non-volatile rewritable memory 12 also stores additional derivation data App_AEK_Deriv. This data is also entered in the non-volatile memory 12 during the installation of the App application (prepared by or in collaboration with the external authority).
  • the cryptographic key AEK used for the encryption of the private key App_SK is obtained by using not only the derivation data App_Deriv, but also the derivation data App_AEK_Deriv, for example as follows:
  • the authentication method of FIG. 3 begins at step E30 by the sending by the processor 10 (due to the execution of the App application) of the public key App_PK and the signature SIG (App_PK, OT_SK ) associated, as well as derivation data App_Deriv.
  • the secure module 20 receives the public key App_PK, the signature SIG (App_PK, OT_SK) associated and the derivation data App_Deriv in step E32.
  • the secure module 20 can thus verify in step E34 the received signature SIG (App_PK, OT_SK) using the public key OT_PK, as explained above for step E6 in the context of FIG. 2.
  • the secure module 20 terminates the authentication process, for example by sending an error message to the processor 10.
  • step E36 the secure module 20 generates a challenge SE_Ch, for example by random draw.
  • the secure module 20 determines in step E38 the derived key OT_App_K by applying the derivation function G to the root key OT_Apps (stored as indicated above and visible in FIG. 1 in the secure module 20) and the derivation data.
  • App_Deriv the derivation function G
  • OT_App_K G (OT_Apps, App_Deriv).
  • the secure module 20 then sends in step E40 the challenge SE_Ch and the key derived OT_App_K to the processor 10 on which the application App runs.
  • the transmitted key (here OT_App_K) is different depending on the application (here App) with which the secure module is in communication (since the derivation data App_Deriv are variable depending on the application), which avoids issuing a key always the same.
  • the processor 10 receives the SE_Ch challenge and the derived key OT_App_K in the step E42 and then implements the following steps because of the execution of the App application.
  • the processor 10 determines in step E44 the cryptographic key AEK by applying the derivation function F to the derived key OT_App_K received in step E12 and the additional derivation data App_AEK_Deriv stored as indicated above in the non-volatile memory 12 .
  • step E16 The process is then continued in the same manner as described above with reference to FIG. 2, starting from step E16.
  • FIG. 4 represents the main steps of a third exemplary method of authenticating an application.
  • This method is implemented in a system of the type of that of FIG. 1, in which the non-volatile rewritable memory 12 also stores App_AEK_Deriv derivation data (as for the second example of an authentication method described above). with reference to Figure 3) and derivation data App_AIK_Deriv. These data are specific to the application concerned (in this case the App application) and entered in the non-volatile memory 12 during the installation of the App application (prepared by or in collaboration with the external authority).
  • the cryptographic key AEK used for the encryption of the private key App_SK is obtained in accordance with what has been described above in the context of the description of FIG.
  • the secure module 20 also stores an authentication private key OT_Auth_SK and the non-volatile memory 12 stores (in association with the application App) the public key OT_Auth_PK associated with the authentication private key OT_Auth_SK (in a key infrastructure public) and a MAC authentication code of this public key OT_Auth_PK.
  • Such a MAC authentication code (for "Message Authentication Code") is first produced by the external authority 30 by application to the public key OT_Auth_PK of a cryptographic algorithm for generating message authentication code using an AIK key obtained by derivation from the derived key OT_App_K and derivation data App_AIK_Deriv, here using the derivation function F already mentioned:
  • AIK F (OT_App_K, App_AIK_Deriv). It is also possible to use the AIK key in order to obtain an authentication code of the App application (which could then be stored app app and used to check the integrity of the App application).
  • the method of FIG. 4 starts in the same manner as in FIG. 3 by the steps E30 to E44 described above.
  • step E46 the processor 10 decrypts the private key App_SK by application to the encrypted version [App_SK] AEK (stored in the non-volatile memory 12) of a cryptographic algorithm of decryption using the cryptographic key AEK determined in step E44.
  • the private key App_SK thus obtained is stored in the RAM 14 at least until the implementation of step E48 described below.
  • the processor 10 then generates in step E48 a signature SIG 'by application to challenge SE_Ch received in step E42 of a cryptographic signature algorithm using the private key App_SK (decrypted in step E46).
  • the processor 10 generates an App_Ch challenge, for example by random draw, in step E50.
  • the processor 10 sends the signature GIS 'and the challenge App_Ch to the secure module 20 in step E52.
  • E46 to E52 are implemented due to the processor executing the App application used in the present embodiment.
  • the secure module 20 receives the signature SIG 'at the step E54 and can thus check the signature SIG' at the step E56 using the public key App_PK (whose signature by the external authority has been verified at the step E34 ), for example as described above with respect to step E24.
  • step E56 If the signature SIG 'is correctly verified in step E56, the processor 10 on which the application App runs has authenticated.
  • the method described here then continues for the authentication of the secure module 20 by the processor 10 on which the application App runs.
  • the secure module 20 generates in step E58 a signature SIG "by application to the challenge App_Ch received in step E54 of an algorithm cryptographic signature using the authentication key OT_Auth_SK (stored in the secure module as indicated above).
  • the secure module 20 sends the GIS signature thus obtained to the processor 10 in step E60.
  • the processor 10 receives the GIS signature "in the step E62 and implements the following steps due to the execution of the App application used in this embodiment.
  • the processor 10 can thus verify in step E66 that the MAC authentication code stored in association with the public key OT_Auth_PK is equal to the result of the application, to the public key OT_Auth_PK stored, of the generation algorithm. message authentication code using the AIK key obtained in step E64, which ensures the integrity of the public key OT_Auth_PK stored.
  • the processor 10 terminates the authentication process, for example by sending an error message to the secure module 20.
  • the processor 10 checks the signature GIS "in the step E68 by using the public key OT_Auth_PK, for example by applying to the received GIS signature a cryptographic algorithm of verification of signature using the public key OT_Auth_PK, then comparing the result obtained to the challenge App_Ch generated in step E50.
  • step E68 If the signature SIG "is correctly verified in step E68, the secure module 20 has authenticated with the processor 10 (on which the application App executes), thus obtaining a mutual authentication of the processor 10 on which executes the application App and the secure module 20.
  • part of the code of the application App is stored encrypted in the non-volatile memory 12
  • FIG. 5 schematically represents the main elements of a second exemplary system in which the invention can be implemented.
  • This system includes an electronic apparatus 100, for example a cellular telephone, an application provider server 200, and a server of an outside authority 300.
  • the electronic apparatus comprises a processor 1 10 (for example a microprocessor), a rewritable non-volatile memory 1 12, a random access memory 1 14, a communication module 1 16 and a secure module 120.
  • a processor 1 10 for example a microprocessor
  • the non-volatile memory rewritable 1 12 stores applications whose execution by the processor 1 10 allows the implementation of data processing processes and data exchange, here in particular with the secure module 120 and the server 200.
  • the rewritable non-volatile memory 12 thus notably stores an application App which, when it is executed by the processor 10, seeks to authenticate itself with the secure module 120 and implements, for this purpose, the steps described below with reference in Figure 6.
  • the rewritable non-volatile memory 1 12 also stores data used during the processing processes implemented by the processor 10.
  • non-volatile rewritable memory 1 12 stores the following cryptographic data, used as described below in the context of the method of FIG. 6:
  • App_PK public key associated with the private key App_SK (in a public key infrastructure) and the GIS signature of this public key App_PK by means of a private key of an external authority OT_SK;
  • an associated OT_Auth_PK public key (in a public key infrastructure) to a private key OT_Auth_SK stored in the secure module 120, as mentioned below, as well as a MAC authentication code of the key public OT_Auth_PK.
  • the private key pair App_SK - public key App_PK, as well as the derivation data App_Deriv, App_AEK_Deriv, App_AIK_Deriv, are prepared and provided by the provider of the App application (the signature GIS and the public key OT_Auth_PK being provided by the external authority 300 to the app application provider as schematically shown in dashed lines in Figure 5).
  • the application provider calculates:
  • Prov_App_K G (Prov_Apps, App_Deriv) ;
  • AEK F (Prov_App_K, App_AEK_Deriv);
  • AIK F (Prov_App_K, App_AIK_Deriv).
  • the application provider can thus encrypt the private key App_SK by applying a cryptographic cryptographic function using the cryptographic key AEK.
  • the provider of the application also obtains from the aforementioned external authority the GIS signature of the public key App_PK (the public key App_PK being for example transmitted to a server of the external authority, which calculates the signature GIS by means of its OT_SK private key and return the GIS signature).
  • the application provider also obtains external authority
  • the public key OT_Auth_PK (associated with the private key OT_Auth_SK stored in the secure module 120) and can thus generate the MAC authentication code by applying, to the public key OT_Auth_PK, an algorithm code generation using the AIK key previously calculated as indicated above.
  • the random access memory 1 14 can memorize the data manipulated by these methods, in particular as described below.
  • the secure module 120 is of the same type as the secure module 20 described above with reference to Figure 1 and will not be described again.
  • the secure module 120 stores, for example in its rewritable non-volatile memory, the associated public key OT_PK (in a public key infrastructure) to the private key OT_SK of the external authority and the private key OT_Auth_SK already mentioned, provided by the external authority 300 (as shown in dashed lines in FIG. 5).
  • the processor 1 10 is connected to the secure module 120 and the communication module 1 16, for example by means of a bus, and can thus exchange data with these elements.
  • the communication module 1 16 allows the connection of the processor
  • a telecommunication network comprising, for example, a mobile telephone network (for example of the GSM type) and a public network (such as the Internet network, for example using an IP type protocol), on which the network is also connected.
  • application provider server 200 and the external authority server 300 are also connected.
  • the processor 1 10, the server of the application provider 200 and the server of the external authority 300 can thus exchange data via the communication module 1 16, as schematically represented in FIG. 5, in particular data used in the course of an authentication method such as that presented below with reference to Figure 6.
  • the messages exchanged as described below can for example be placed within http or https requests or in responses to such requests.
  • the server 200 memorizes the Prov_Apps root key already mentioned (generated by the application provider and valid for all applications).
  • FIG. 6 represents the main steps of a fourth example of an authentication method of an application, implemented here within the framework of the system of FIG. 5.
  • the steps of this method implemented by the processor 1 10 are performed due to the execution by the processor 1 10 App App.
  • step E100 at which the processor 100 sends the derivation data App_Deriv to the server 200.
  • the server 200 receives the derivation data App_Deriv in the step E102 and can thus determine in step E108 the derived key Prov_App_K by applying the derivation function G to the root key Prov_Apps (stored in the server 200) and the App_Deriv derivation data received:
  • Prov_App_K G (Prov_Apps, App_Deriv).
  • the server 200 sends the Prov_App_K derived key to the processor 1 10 in step E106.
  • the processor 1 10 receives the derivative key Prov_App_K in the step E108 and stores it (for example in the random access memory 1 14) for later use (see below the steps E122 and E142).
  • the processor 1 10 then emits at step E1 10 the public key App_PK and the associated GIS signature, destined for the secure module 120.
  • the processor 1 10 then emits at step E1 10 the public key App_PK and the associated GIS signature, destined for the secure module 120.
  • the secure module 120 receives the public key App_PK and the signature
  • the secure module 120 can thus check in step E1 14 the received signature SIG using the public key OT_PK, as explained above for step E6 in the context of FIG. 2.
  • the secure module 120 terminates the authentication process, for example by returning an error message to the processor 1 10.
  • step E1 16 the secure module 120 generates a challenge SE_Ch, for example by random draw.
  • the secure module 120 can thus issue the SE_Ch challenge to the processor 1 10 in step E1 18.
  • the processor 1 10 can thus decrypt in step E124 the private key App_SK by application to the encrypted version [App_SK] AEK (stored in the non-volatile memory 1 12) of a decryption cryptographic algorithm using the cryptographic key AEK determined in step E122.
  • the private key App_SK thus obtained is stored in the RAM 1 14 at least until the implementation of step E126 described below.
  • the processor 1 10 then generates in step E126 a signature SIC by application to the challenge SE_Ch received in step E120 of a cryptographic signature algorithm using the private key App_SK (decrypted in step E124).
  • the processor 1 10 generates an App_Ch challenge, for example by random draw, in step E128.
  • the processor 110 sends the SIC signature and the App_Ch challenge to the secure module 120 in step E130.
  • the secure module 120 receives the SIC signature in step E132 and can thus check the SIC signature in step E134 using the public key App_PK (whose signature by the external authority has been verified in step E1 14) for example as described above with respect to step E24.
  • the secure module 120 can then send an error message to the processor 1 10.
  • step E134 the processor 1 10 on which the application App runs has authenticated to the secure module 120.
  • the method then continues for the authentication of the secure module 120 by the processor 1 10 on which the application App runs.
  • the secure module 120 generates in step E136 a GIS signature "by application to the challenge App_Ch received in step E132 of a signature cryptographic algorithm using the private key OT_Auth_SK (stored in the secure module 120 as indicated above).
  • the secure module 120 sends the GIS signature thus obtained to the processor 1 10 in step E138.
  • the processor 1 10 receives the signature SIG "in the step E140 and determines in the step E142 the key AIK by derivation from the derived key Prov_App_K (received in the step E108) and the data of derivation App_AIK_Deriv (memorized in the nonvolatile memory 1 12) using the derivation function F:
  • AIK F (Prov_App_K, App_AIK_Deriv).
  • the processor 10 can thus verify in step E144 that the MAC authentication code stored in association with the public key OT_Auth_PK is equal to the result of the application, the public key OT_Auth_PK stored, of the generation algorithm message authentication code using the AIK key obtained in step E142, which ensures the integrity of the public key OT_Auth_PK stored.
  • the processor 1 10 terminates the authentication process, for example by sending an error message to the secure module 120.
  • step E144 If the check of step E144 is correctly performed, the processor 1 10 verifies the signature GIS "in step E146 using the public key OT_Auth_PK, for example by applying to the received GIS signature a cryptographic signature verification algorithm using the public key OT_Auth_PK, then comparing the result obtained to the challenge App_Ch generated in step E128.
  • step E146 If the signature SIG "is correctly verified in step E146, the secure module 120 has authenticated itself to the processor 1 10 (on which the application App executes), thus obtaining a mutual authentication of the processor 1 10 on which executes the application App and the secure module 120.
  • step E148 decrypt this encrypted memory portion (step E148), to means of the AEK cryptographic key in the example given above.
  • the processor 1 10 can then emit at step E150 an authentication confirmation message to the secure module 120.
  • the secure module 120 receives this confirmation message in step E152 and can then send a signed message, for example by means of the private key OT_Auth_SK, to the server of the external authority 300 (E154), where this message can to be received and its signature verified by means of the public key OT_Auth_PK (step E156).

Abstract

L'invention concerne un procédé d'authentification d'une application (App) exécutée par un processeur (10) d'un appareil électronique, comprenant les étapes suivantes : - dérivation d'une clé cryptographique (AEK) à partir d'une donnée (OT_Apps) reçue d'une entité électronique extérieure (20); - déchiffrement, au moyen de la clé cryptographique dérivée (AEK), d'une clé secrète mémorisée chiffrée ([App_SK]AEK); - émission de données d'authentification préparées au moyen de la clé secrète déchiffrée (App_SK). Un appareil électronique et un programme d'ordinateur associés sont également proposés.

Description

Procédé d'authentification d'une application, appareil électronique et
programme d'ordinateur associés
DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne l'authentification des applications exécutables sur un processeur.
Elle concerne plus particulièrement un procédé d'authentification d'une application, ainsi qu'un appareil électronique et un programme d'ordinateur associés.
L'invention s'applique particulièrement avantageusement dans le cas où le processeur sur lequel s'exécute l'application échange des données avec un module sécurisé.
ARRIERE-PLAN TECHNOLOGIQUE
Dans les procédés de traitement et d'échanges de données impliquant un processeur, sur lequel s'exécute une application, et un dispositif électronique tiers, il arrive que l'application doive s'authentifier auprès du dispositif électronique tiers, afin de garantir à celui-ci qu'il échange des données avec l'application prévue à cet effet, et non avec un programme malveillant (ou "malware").
Afin de s'authentifier auprès du dispositif électronique tiers, il a été proposé que l'application transmette à celui-ci des données d'authentification (par exemple une signature) préparées au moyen d'une clé secrète (par exemple une clé privée) connue seulement de l'application.
Dans cette configuration toutefois, la diffusion d'une telle application dans des environnements non-sécurisés, tels que les appareils électroniques sur lesquels une telle application peut être installée, risque de rendre la clé secrète accessible à des personnes malintentionnées.
OBJET DE L'INVENTION
Dans ce contexte, la présente invention propose un procédé d'authentification d'une application exécutée par un processeur d'un appareil électronique, caractérisé en ce qu'il comprend les étapes suivantes :
- dérivation d'une clé cryptographique à partir d'une donnée reçue d'une entité électronique extérieure ;
- déchiffrement, au moyen de la clé cryptographique dérivée, d'une clé secrète mémorisée chiffrée ; - émission de données d'authentification préparées au moyen de la clé secrète déchiffrée.
La clé secrète peut être ainsi utilisée pour la préparation des données d'authentification après réception des données d'une entité électronique extérieure, mais n'est pas accessible sans ces données et ne pourra donc en revanche pas être utilisée par une personne malintentionnée.
Selon des caractéristiques optionnelles et donc non limitatives :
- la clé secrète chiffrée est mémorisée dans une mémoire non-volatile réinscriptible ;
- la clé secrète déchiffrée est mémorisée dans une mémoire vive ;
- le procédé d'authentification comprend des étapes de réception d'un défi et de préparation desdites données d'authentification par application au défi reçu d'un algorithme cryptographique utilisant la clé secrète déchiffrée ;
- ladite donnée reçue est préparée par l'entité électronique extérieure sur la base d'une donnée reçue de l'application et d'une clé mémorisée dans l'entité électronique extérieure ;
- les données d'authentification sont émises à destination d'un module sécurisé ;
- le défi est généré, par exemple par tirage aléatoire, par le module sécurisé et émis par le module sécurisé à destination de l'application ;
- l'entité électronique extérieure est le module sécurisé ;
- l'entité électronique extérieure est un serveur (et est donc distincte du module sécurisé) ;
- la clé secrète est une clé privée ;
- le procédé comprend une étape d'émission par le module sécurisé d'un message signé au moyen d'une clé privée mémorisée dans le module sécurisé à destination d'un serveur ;
- le processus d'authentification du module sécurisé auprès de l'application utilise une clé publique mémorisée au sein de l'appareil électronique en association avec un code d'authentification de message produit par une autorité extérieure ;
- l'appareil électronique est un téléphone mobile ou une tablette numérique ;
- l'appareil électronique comprend un élément de maintien sur une partie du corps de l'utilisateur ;
- le procédé comprend une étape d'émission par l'application d'un message signé au moyen de la clé secrète déchiffrée à destination d'un serveur ;
- le procédé comprend une étape de déchiffrement d'une partie d'un code exécutable de l'application au moyen de la clé cryptographique dérivée ;
- le module sécurisé est un élément sécurisé.
Le procédé d'authentification peut comprendre en outre les étapes suivantes :
- vérification, par le module sécurisé et au moyen d'une première clé publique mémorisée dans le module sécurisé, d'une signature annexée à une seconde clé publique associée à ladite clé privée (dans une infrastructure à clé publique ou PKI, pour "Public Key Infrastructure") ;
- vérification, par le module sécurisé, desdites données d'authentification au moyen de la seconde clé publique.
Le procédé d'authentification peut également comprendre un processus d'authentification du module sécurisé auprès de l'application.
L'invention propose également un appareil électronique comprenant un processeur et au moins une mémoire mémorisant une application exécutable par le processeur, l'application étant conçue de sorte que le processeur mette en œuvre un procédé tel que proposé ci-dessus lorsque l'application est exécutée par le processeur.
De même, l'invention propose que l'application susmentionnée soit un programme d'ordinateur comprenant des instructions exécutables par un processeur d'un appareil électronique (notamment par le processeur de l'appareil électronique susmentionné) et conçues de sorte que le processeur mette en œuvre un procédé tel que proposé ci-dessus lorsque ces instructions sont exécutées par le processeur.
DESCRIPTION DÉTAILLÉE D'UN EXEMPLE DE RÉALISATION La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée.
Sur les dessins annexés :
- la figure 1 représente schématiquement les éléments principaux d'un premier exemple de système dans lequel peut être mise en œuvre l'invention ; - la figure 2 représente les étapes principales d'un premier exemple de procédé d'authentification d'une application ;
- la figure 3 représente les étapes principales d'un second exemple de procédé d'authentification d'une application ;
- la figure 4 représente les étapes principales d'un troisième exemple de procédé d'authentification d'une application ;
- la figure 5 représente schématiquement les éléments principaux d'un second exemple de système dans lequel peut être mise en œuvre l'invention ; et
- la figure 6 représente les étapes principales d'un quatrième exemple de procédé d'authentification d'une application.
La figure 1 représente schématiquement les éléments principaux d'un premier exemple de système, ici un appareil électronique, dans lequel peut être mise en œuvre l'invention. Cet appareil électronique est par exemple un téléphone mobile, une tablette numérique, une montre connectée ou des lunettes connectées. Dans ces derniers cas, l'appareil électronique comprend un élément de maintien sur une partie du corps de l'utilisateur (par exemple un bracelet dans le cas d'une montre connectée, ou des branches dans le cas de lunettes connectées).
Ces éléments comprennent un processeur 10 (par exemple un microprocesseur), une mémoire non-volatile réinscriptible 12, une mémoire vive 14 et un module sécurisé 20.
Ces éléments font ici partie de l'appareil électronique susmentionné. En variante, ces éléments pourraient être répartis dans plusieurs appareils électroniques formant un système, le processeur 10, la mémoire non-volatile 12 et la mémoire vive 14 étant par exemple compris dans un même appareil électronique, tandis que le module sécurisé est compris dans un autre appareil électronique.
La mémoire non-volatile réinscriptible 12 mémorise des applications dont l'exécution par le processeur 10 permet la mise en œuvre de procédés de traitement de données et d'échanges de données, ici notamment avec le module sécurisé 20. La mémoire non-volatile réinscriptible 12 mémorise ainsi notamment une application App qui cherche, lors de son exécution par le processeur 10, à s'authentifier auprès du module sécurisé 20 et met notamment en œuvre pour ce faire les étapes décrites ci-dessous en référence à la figure 2. La mémoire non-volatile réinscriptible 12 mémorise également des données utilisées lors des procédés de traitement mis en œuvre par le processeur 10.
En particulier, la mémoire non-volatile réinscriptible 12 mémorise les données cryptographiques suivantes, utilisées comme décrit ci-dessous dans le cadre du procédé de la figure 2 :
- une clé privée App_SK attribuée à l'application App, mémorisée dans la mémoire non-volatile réinscriptible 12 sous forme chiffrée par une clé cryptographique AEK (d'où la notation [App_SK]AEK adoptée en figure 1 ) ;
- des données de dérivation App_Deriv ;
- une clé publique App_PK associée à la clé privée App_SK (dans une infrastructure à clé publique ou PKI, pour "Public Key Infrastructure") et la signature SIG(App_PK,OT_SK) de cette clé publique App_PK.
Ces données sont spécifiques à l'application concernée (ici l'application App) et ont été calculées par une autorité extérieure 30, puis associées à l'application App et par exemple inscrites dans la mémoire non-volatile réinscriptible 12 lors de l'installation de l'application App dans cette même mémoire non-volatile réinscriptible 12 (comme schématiquement représenté en pointillés en figure 1 ).
La clé cryptographique AEK (avec laquelle est chiffrée la clé privée
App_SK) est obtenue (notamment au préalable, au niveau de l'autorité extérieure 30, en vue du chiffrement de la clé privée App_SK) par application d'une fonction de dérivation F à une clé racine OT_Apps (commune à toutes les applications) et aux données de dérivation App_Deriv susmentionnées (spécifiques à l'application concernée) : AEK = F(OT_Apps,App_Deriv).
On remarque qu'une partie du code exécutable (c'est-à-dire des instructions exécutables par le processeur 10) de l'application App peut également être chiffrée au moyen de la clé cryptographique AEK. Un tel chiffrement peut par exemple être réalisé par le fournisseur de l'application. (Une autre partie du code est dans ce cas mémorisée dans la mémoire non-volatile réinscriptible 12 sans chiffrement afin de pouvoir effectuer les étapes décrites ci-dessous, au moins jusqu'au déchiffrement de la partie chiffrée du code.)
La signature SIG(App_PK,OT_SK) est quant à elle obtenue (également au niveau de l'autorité extérieure 30) par application à la clé publique App_PK d'un algorithme cryptographique de signature utilisant une clé privée de l'autorité extérieure OT_SK (cette clé privée étant utilisée quelle que soit l'application concernée).
Au cours des procédés mis en œuvre par le processeur 10, et notamment le procédé de la figure 2, la mémoire vive 14 peut mémoriser les données manipulées par ces procédés, notamment comme décrit ci-après.
Le module sécurisé 20 est par exemple un élément sécurisé, tel qu'un élément sécurisé intégré à l'appareil électronique (ou eSE pour "embedded Secure Elément'). En variante, il pourrait s'agir d'une carte à microcircuit, par exemple de type UlCC (pour "Universal Integrated Circuit Card') ou eUICC (pour "embedded Universal Integrated Circuit Card'), ou d'une carte de type micro-SD sécurisée.
Le module sécurisé 20 comprend un processeur et une mémoire non- volatile réinscriptible. Comme représenté en figure 1 , cette mémoire non-volatile réinscriptible mémorise notamment la clé racine OT_Apps déjà mentionnée et la clé publique OT_PK associée à la clé privée OT_SK susmentionnée (dans une infrastructure à clé publique). Ces clés ont par exemple été inscrites dans le module sécurisé lors d'une étape de personnalisation de ce module sécurisé 20 (comme schématiquement représenté en pointillés en figure 1 ). Selon une possibilité de réalisation, potentiellement utilisable lorsque l'appareil électronique précité comprend des moyens de télécommunication, ces clés pourraient être mises à jour à distance (selon une technique dite OTA pour "Over-The-Air") depuis un serveur de l'autorité extérieure 30.
Les procédés mis en œuvre par le module sécurisé 20 comme décrit ci- dessous résultent de l'exécution, par le processeur du module sécurisé 20, d'instructions de programmes mémorisés dans la mémoire non-volatile réinscriptible du module sécurisé 20, ou d'une autre mémoire du module sécurisé 20.
En variante, le module sécurisé 20 pourrait être réalisé sous forme d'un circuit intégré à application spécifique (ou ASIC pour "Application Spécifie Integrated Circuit"), programmé pour mettre en œuvre les procédés décrits ci- dessous.
Le processeur 10 est relié au module sécurisé 20, par exemple au moyen d'un bus (ou en variante via une liaison de type ISO7816 ou SPI ou HCI/SWP), et peut ainsi, du fait de l'exécution des instructions des applications mémorisées en mémoire non-volatile 12 ou éventuellement en mémoire vive 14, échanger des données avec le module sécurisé 20. Le processeur 10 et le module sécurisé 20 pourraient en variante échanger des données par l'intermédiaire d'un réseau téléphonique et/ou informatique (par exemple en utilisant des protocoles de type GSM et/ou UMTS et/ou TCP/IP et/ou Bluetooth), notamment dans les cas mentionnés ci-dessus où le processeur 10 et le module sécurisé 20 ne font pas partie du même appareil électronique.
La figure 2 représente les étapes principales d'un premier exemple de procédé d'authentification d'une application. Un tel procédé est ici mis en œuvre dans le système de la figure 1 .
Comme indiqué ci-dessous, ce procédé comprend des échanges entre le processeur 10 et le module sécurisé 20. Ces échanges peuvent être réalisés directement entre ces éléments, sans mise en place d'un canal sécurisé. Toutefois, selon une variante envisageable, on peut au préalable établir un canal sécurisé entre le processeur 10 et le module sécurisé 20 et réaliser les échanges décrits ci-dessous via ce canal sécurisé, ce qui permet d'empêcher un attaquant passif d'avoir accès (par simple observation) aux données échangées.
Pour ce faire, le module sécurisé 20 et le processeur 10 utilisent par exemple un schéma de type Diffie-Hellman, en générant chacun de leur côté une clé éphémère, en signant cette clé éphémère avec leur clé secrète, en vérifiant la signature effectuée par l'autre module et, en cas de vérification, en déduisant de ces éléments un secret commun et des clés de session à utiliser pour chiffrer les échanges ultérieurs.
Quoiqu'il en soit, le procédé de la figure 2 débute à l'étape E2 par l'émission par le processeur 10 (du fait de l'exécution de l'application App) de la clé publique App_PK et de la signature SIG(App_PK,OT_SK) associée.
Le module sécurisé 20 reçoit la clé publique App_PK et la signature SIG(App_PK,OT_SK) associée à l'étape E4.
Le module sécurisé 20 peut ainsi vérifier à l'étape E6 la signature reçue
SIG(App_PK,OT_SK) à l'aide de la clé publique OT_PK (associée à la clé privée OT_SK et mémorisée dans le module sécurisé comme déjà indiqué), par exemple en appliquant la signature SIG(App_PK,OT_SK) un algorithme cryptographique de vérification de signature utilisant la clé publique OT_PK et en comparant le résultat obtenu à la clé publique App_PK (éventuellement transformée par une fonction de hachage utilisée pour former la signature). Selon une variante envisageable, la signature SIG(App_PK,OT_SK) peut être vérifiée en appliquant, à la clé publique App_PK et à la signature reçue SIG(App_PK,OT_SK), un algorithme cryptographique de vérification de signature utilisant la clé publique OT_ PK et produisant (directement) un résultat positif ou négatif.
Si la signature n'est pas correctement vérifiée, le module sécurisé 20 met fin au processus d'authentification, en renvoyant par exemple un message d'erreur au processeur 10.
Si la signature est correctement vérifiée, le procédé de la figure 2 se poursuit à l'étape E8 à laquelle le module sécurisé 20 génère un défi (ou "challenge" selon l'appellation anglo-saxonne) SE_Ch, par exemple par tirage aléatoire.
Le module sécurisé 20 émet ensuite à l'étape E10 le défi SE_Ch et la clé racine OT_Apps à destination du processeur 10 sur lequel s'exécute l'application App.
Le processeur 10 reçoit le défi SE_Ch et la clé racine OT_Apps à l'étape E12 et met alors en œuvre les étapes suivantes du fait de l'exécution de l'application App.
Le processeur 10 détermine à l'étape E14 la clé cryptographique AEK
(déjà mentionnée plus haut) en appliquant la fonction de dérivation F à la clé racine OT_Apps reçue à l'étape E12 et aux données de dérivation App_Deriv mémorisées dans la mémoire non-volatile 12.
Le processeur 10 peut alors déchiffrer à l'étape E16 la clé privée App_SK par application à la version chiffrée [App_SK]AEK (mémorisée dans la mémoire non-volatile 12) d'un algorithme cryptographique de déchiffrement utilisant la clé cryptographique AEK déterminée à l'étape E14. La clé privée App_SK ainsi obtenue (c'est-à-dire déchiffrée) peut être mémorisée dans la mémoire vive 14 jusqu'à la mise en œuvre de l'étape E18 décrite ci-dessous (puis éventuellement supprimée ensuite).
Dans les cas où une partie du code de l'application App est chiffrée au moyen de la clé cryptographique AEK comme décrit ci-dessus, le processeur 10 peut alors également procéder au déchiffrement de la partie chiffrée du code de l'application App. Le processeur 10 génère à l'étape E18 une signature SIC par application au défi SE_Ch reçu à l'étape E12 d'un algorithme cryptographique de signature utilisant la clé privée App_SK (déchiffrée à l'étape E16).
Le processeur 10 envoie la signature SIC ainsi obtenue au module sécurisé 20 à l'étape E20.
Le module sécurisé 20 reçoit la signature SIC à l'étape E22 et peut ainsi vérifier la signature SIC à l'étape E24 en utilisant la clé publique App_PK (dont la signature par l'autorité extérieure a été vérifiée à l'étape E6), par exemple en appliquant à la signature SIC reçue un algorithme cryptographique de vérification de signature utilisant la clé publique App_PK, puis en comparant le résultat obtenu au défi SE_Ch généré à l'étape E8. Selon une variante envisageable, la signature SIC peut être vérifiée en appliquant, au défi SE_Ch et à la signature reçue SIC, un algorithme cryptographique de vérification de signature utilisant la clé publique App_PK et produisant (directement) un résultat positif ou négatif.
Si la signature SIC n'est pas correctement vérifiée, le procédé d'authentification a échoué.
Si la signature SIC est correctement vérifiée à l'étape E24, le processeur 10 sur lequel s'exécute l'application App a ainsi démontré qu'il détenait la clé privée App_SK et s'est donc authentifié.
La figure 3 représente les étapes principales d'un second exemple de procédé d'authentification d'une application.
Ce procédé est mis en œuvre dans un système du type de celui de la figure 1 , dans lequel la mémoire non-volatile réinscriptible 12 mémorise en outre des données de dérivation additionnelles App_AEK_Deriv. Ces données sont également inscrites dans la mémoire non-volatile 12 lors de l'installation de l'application App (préparée par ou en collaboration avec l'autorité extérieure).
Par ailleurs, dans ce mode de réalisation, la clé cryptographique AEK utilisée pour le chiffrement de la clé privée App_SK est obtenue en utilisant non seulement les données de dérivation App_Deriv, mais aussi les données de dérivation App_AEK_Deriv, par exemple comme suit :
- une clé dérivée OT_App_K est déterminée par application d'une fonction de dérivation G à la clé racine OT_Apps et aux données de dérivation App_Deriv, soit OT_App_K = G(OT_App,App_Deriv) ;
- la clé cryptographique AEK est déterminée par application d'une fonction de dérivation F à la clé dérivée OT_App_K et aux données de dérivation additionnelles App_AEK_Deriv, soit AEK = F(OT_App_K,App_AEK_Deriv).
Comme pour le procédé de la figure 2, il est envisageable de manière optionnelle d'établir au préalable un canal sécurisé entre le processeur 10 et le module sécurisé 20 et de réaliser alors les échanges décrits ci-dessous via ce canal sécurisé.
Le procédé d'authentification de la figure 3 débute à l'étape E30 par l'émission par le processeur 10 (du fait de l'exécution de l'application App) de la clé publique App_PK et de la signature SIG(App_PK,OT_SK) associée, ainsi que des données de dérivation App_Deriv.
Le module sécurisé 20 reçoit la clé publique App_PK, la signature SIG(App_PK,OT_SK) associée et les données de dérivation App_Deriv à l'étape E32.
Le module sécurisé 20 peut ainsi vérifier à l'étape E34 la signature reçue SIG(App_PK,OT_SK) à l'aide de la clé publique OT_PK, comme expliqué ci- dessus pour l'étape E6 dans le cadre de la figure 2.
Si la signature n'est pas correctement vérifiée, le module sécurisé 20 met fin au processus d'authentification, en renvoyant par exemple un message d'erreur au processeur 10.
Si la signature est correctement vérifiée, le procédé de la figure 2 se poursuit à l'étape E36 à laquelle le module sécurisé 20 génère un défi SE_Ch, par exemple par tirage aléatoire.
Le module sécurisé 20 détermine alors à l'étape E38 la clé dérivée OT_App_K par application de la fonction de dérivation G à la clé racine OT_Apps (mémorisée comme indiqué plus haut et visible en figure 1 dans le module sécurisé 20) et aux données de dérivation App_Deriv :
OT_App_K = G (OT_Apps,App_Deriv).
Le module sécurisé 20 émet ensuite à l'étape E40 le défi SE_Ch et la clé dérivée OT_App_K à destination du processeur 10 sur lequel s'exécute l'application App.
On remarque que la clé transmise (ici OT_App_K) est ainsi différente selon l'application (ici App) avec laquelle le module sécurisé est en communication (puisque les données de dérivation App_Deriv sont variables selon l'application), ce qui évite d'émettre une clé toujours identique. Le processeur 10 reçoit le défi SE_Ch et la clé dérivée OT_App_K à l'étape E42 et met alors en œuvre les étapes suivantes du fait de l'exécution de l'application App.
Le processeur 10 détermine à l'étape E44 la clé cryptographique AEK en appliquant la fonction de dérivation F à la clé dérivée OT_App_K reçue à l'étape E12 et aux données de dérivation additionnelles App_AEK_Deriv mémorisées comme indiqué plus haut dans la mémoire non-volatile 12.
Le procédé se poursuit ensuite de manière identique à ce qui a été décrit ci-dessus en référence à la figure 2, à partir de l'étape E16.
La figure 4 représente les étapes principales d'un troisième exemple de procédé d'authentification d'une application.
Ce procédé est mis en œuvre dans un système du type de celui de la figure 1 , dans lequel la mémoire non-volatile réinscriptible 12 mémorise en outre des données de dérivation App_AEK_Deriv (comme pour le second exemple de procédé d'authentification décrit ci-dessus en référence à la figure 3) et des données de dérivation App_AIK_Deriv. Ces données sont spécifiques à l'application concernée (ici l'application App) et inscrites dans la mémoire non- volatile 12 lors de l'installation de l'application App (préparée par ou en collaboration avec l'autorité extérieure).
Par ailleurs, dans ce mode de réalisation, la clé cryptographique AEK utilisée pour le chiffrement de la clé privée App_SK est obtenue conformément à ce qui a été décrit ci-dessus dans le cadre de la description de la figure 3.
Le module sécurisé 20 mémorise en outre une clé privée d'authentification OT_Auth_SK et la mémoire non-volatile 12 mémorise (en association avec l'application App) la clé publique OT_Auth_PK associée à la clé privée d'authentification OT_Auth_SK (dans une infrastructure à clé publique) et un code d'authentification MAC de cette clé publique OT_Auth_PK.
Un tel code d'authentification MAC (pour "Message Authentication Code") est produit au préalable par l'autorité extérieure 30 par application à la clé publique OT_Auth_PK d'un algorithme cryptographique de génération de code d'authentification de message utilisant une clé AIK obtenue par dérivation à partir de la clé dérivée OT_App_K et des données de dérivation App_AIK_Deriv, ici en utilisant la fonction de dérivation F déjà mentionnée :
AIK = F(OT_App_K,App_AIK_Deriv). Il est également possible d'utiliser la clé AIK afin d'obtenir un code d'authentification de l'application App (qui pourrait alors être mémorisé annexé à l'application App et utilisé pour vérifier l'intégrité de l'application App).
Le procédé de la figure 4 débute de manière identique à celui de la figure 3 par les étapes E30 à E44 décrites ci-dessus.
Le procédé de la figure 4 se poursuit ensuite à l'étape E46 à laquelle le processeur 10 déchiffre la clé privée App_SK par application à la version chiffrée [App_SK]AEK (mémorisée dans la mémoire non-volatile 12) d'un algorithme cryptographique de déchiffrement utilisant la clé cryptographique AEK déterminée à l'étape E44. La clé privée App_SK ainsi obtenue est mémorisée dans la mémoire vive 14 au moins jusqu'à la mise en œuvre de l'étape E48 décrite ci- dessous.
Le processeur 10 génère alors à l'étape E48 une signature SIG' par application au défi SE_Ch reçu à l'étape E42 d'un algorithme cryptographique de signature utilisant la clé privée App_SK (déchiffrée à l'étape E46).
Le processeur 10 génère un défi App_Ch, par exemple par tirage aléatoire, à l'étape E50.
Le processeur 10 envoie la signature SIG' et le défi App_Ch au module sécurisé 20 à l'étape E52.
Comme déjà indiqué pour les autres modes de réalisation, les étapes
E46 à E52 sont mises en œuvre du fait de l'exécution par le processeur de l'application App utilisée dans le présent mode de réalisation.
Le module sécurisé 20 reçoit la signature SIG' à l'étape E54 et peut ainsi vérifier la signature SIG' à l'étape E56 en utilisant la clé publique App_PK (dont la signature par l'autorité extérieure a été vérifiée à l'étape E34), par exemple comme décrit ci-dessus à propos de l'étape E24.
Si la signature SIG' n'est pas correctement vérifiée, le procédé d'authentification a échoué.
Si la signature SIG' est correctement vérifiée à l'étape E56, le processeur 10 sur lequel s'exécute l'application App s'est authentifié.
Le procédé décrit ici se poursuit alors en vue de l'authentification du module sécurisé 20 par le processeur 10 sur lequel s'exécute l'application App.
Pour ce faire, le module sécurisé 20 génère à l'étape E58 une signature SIG" par application au défi App_Ch reçu à l'étape E54 d'un algorithme cryptographique de signature utilisant la clé privée d'authentification OT_Auth_SK (mémorisée dans le module sécurisé comme indiqué plus haut).
Le module sécurisé 20 envoie la signature SIG" ainsi obtenue au processeur 10 à l'étape E60.
Le processeur 10 reçoit la signature SIG" à l'étape E62 et met en œuvre les étapes qui suivent du fait de l'exécution de l'application App utilisée dans ce mode de réalisation.
Le processeur 10 détermine à l'étape E64 la clé AIK par dérivation à partir de la clé dérivée OT_App_K (reçue à l'étape E42) et des données de dérivation App_AIK_Deriv (mémorisées dans la mémoire non-volatile 12) en utilisant la fonction de dérivation F : AIK = F(OT_App_K,App_AIK_Deriv).
Le processeur 10 peut ainsi vérifier à l'étape E66 que le code d'authentification MAC mémorisé en association avec la clé publique OT_Auth_PK est bien égal au résultat de l'application, à la clé publique OT_Auth_PK mémorisée, de l'algorithme de génération de code d'authentification de message utilisant la clé AIK obtenue à l'étape E64, ce qui permet de s'assurer de l'intégrité de la clé publique OT_Auth_PK mémorisée.
Si cette vérification est un échec, le processeur 10 met fin au procédé d'authentification, en envoyant par exemple un message d'erreur au module sécurisé 20.
Si la vérification de l'étape E66 est correctement effectuée, le processeur 10 vérifie la signature SIG" à l'étape E68 en utilisant la clé publique OT_Auth_PK, par exemple en appliquant à la signature SIG" reçue un algorithme cryptographique de vérification de signature utilisant la clé publique OT_Auth_PK, puis en comparant le résultat obtenu au défi App_Ch généré à l'étape E50.
Si la signature SIG" n'est pas correctement vérifiée, le procédé d'authentification a échoué.
Si la signature SIG" est correctement vérifiée à l'étape E68, le module sécurisé 20 s'est authentifié auprès du processeur 10 (sur lequel s'exécute l'application App). On obtient ainsi une authentification mutuelle du processeur 10 sur lequel s'exécute l'application App et du module sécurisé 20.
Dans certains modes de réalisation dans lesquels une partie du code de l'application App est mémorisée chiffrée dans la mémoire non-volatile 12, on peut procéder, après une telle authentification mutuelle, au déchiffrement de cette partie mémorisée chiffrée, au moyen de la clé cryptographique AEK dans l'exemple donnée plus haut.
La figure 5 représente schématiquement les éléments principaux d'un second exemple de système dans lequel peut être mise en œuvre l'invention.
Ce système comprend un appareil électronique 100, par exemple un téléphone cellulaire, un serveur de fournisseur d'application 200 et un serveur d'une autorité extérieure 300.
L'appareil électronique comprend un processeur 1 10 (par exemple un microprocesseur), une mémoire non-volatile réinscriptible 1 12, une mémoire vive 1 14, un module de communication 1 16 et un module sécurisé 120.
La mémoire non-volatile réinscriptible 1 12 mémorise des applications dont l'exécution par le processeur 1 10 permet la mise en œuvre de procédés de traitement de données et d'échanges de données, ici notamment avec le module sécurisé 120 et le serveur 200. La mémoire non-volatile réinscriptible 12 mémorise ainsi notamment une application App qui cherche, lors de son exécution par le processeur 10, à s'authentifier auprès du module sécurisé 120 et met notamment en œuvre pour ce faire les étapes décrites ci-dessous en référence à la figure 6.
La mémoire non-volatile réinscriptible 1 12 mémorise également des données utilisées lors des procédés de traitement mis en œuvre par le processeur 10.
En particulier, la mémoire non-volatile réinscriptible 1 12 mémorise les données cryptographiques suivantes, utilisées comme décrit ci-dessous dans le cadre du procédé de la figure 6 :
- une clé privée App_SK attribuée à l'application App, mémorisée dans la mémoire non-volatile réinscriptible 1 12 sous forme chiffrée par une clé cryptographique AEK ;
- des données de dérivation App_Deriv, App_AEK_Deriv et App_AIK_Deriv ;
- une clé publique App_PK associée à la clé privée App_SK (dans une infrastructure à clé publique) et la signature SIG de cette clé publique App_PK au moyen d'une clé privée d'une autorité extérieure OT_SK ;
- une clé publique OT_Auth_PK associée (dans une infrastructure à clé publique) à une clé privée OT_Auth_SK mémorisée dans le module sécurisé 120, comme mentionné plus bas, ainsi qu'un code d'authentification MAC de la clé publique OT_Auth_PK.
Mise à part la clé publique OT_Auth_PK (associée au module sécurisé 120), ces données sont spécifiques à l'application concernée (ici l'application App).
La paire clé privée App_SK - clé publique App_PK, ainsi que les données de dérivation App_Deriv, App_AEK_Deriv, App_AIK_Deriv, sont préparées et fournies par le fournisseur de l'application App (la signature SIG et la clé publique OT_Auth_PK étant fournies par l'autorité extérieure 300 au fournisseur de l'application App comme schématiquement représenté en pointillés en figure 5).
Au préalable (c'est-à-dire avant l'installation de l'application App au sein de l'appareil électronique 100), le fournisseur de l'application calcule :
- une clé dérivée Prov_App_K par application d'une fonction de dérivation G à une clé racine Prov_Apps (commune à toutes les applications) et à la donnée de dérivation App_Deriv (spécifique à l'application concernée) : Prov_App_K = G(Prov_Apps,App_Deriv) ;
- la clé cryptographique AEK par application d'une fonction de dérivation F à la clé dérivée Prov_App_K et à la donnée de dérivation App_AEK_Deriv (spécifique à l'application concernée) : AEK = F(Prov_App_K,App_AEK_Deriv) ;
- une clé AIK par application de la fonction de dérivation F à la clé dérivée Prov_App_K et à la donnée de dérivation App_AIK_Deriv (spécifique à l'application concernée) : AIK = F(Prov_App_K,App_AIK_Deriv).
Le fournisseur de l'application peut ainsi chiffrer la clé privée App_SK par application d'une fonction cryptographique de chiffrement utilisant la clé cryptographique AEK.
Le fournisseur de l'application obtient par ailleurs de l'autorité extérieure précitée la signature SIG de la clé publique App_PK (la clé publique App_PK étant par exemple transmise à un serveur de l'autorité extérieure, qui calcule la signature SIG au moyen de sa clé privée OT_SK et retourne la signature SIG).
Le fournisseur de l'application obtient également de l'autorité extérieure
300 (comme schématiquement représenté en pointillés en figure 5) la clé publique OT_Auth_PK (associée à la clé privée OT_Auth_SK mémorisée dans le module sécurisé 120) et peut ainsi générer le code d'authentification MAC en appliquant, à la clé publique OT_Auth_PK, un algorithme de génération de code d'authentification utilisant la clé AIK préalablement calculée comme indiqué ci- dessus.
Toutes ces données peuvent ainsi être associées à l'application App par le fournisseur d'application et inscrites dans la mémoire non-volatile réinscriptible 1 12 lors de l'installation de l'application App dans cette même mémoire non- volatile réinscriptible 12.
Au cours des procédés mis en œuvre par le processeur 1 10, et notamment le procédé de la figure 6, la mémoire vive 1 14 peut mémoriser les données manipulées par ces procédés, notamment comme décrit ci-après.
Le module sécurisé 120 est du même type que le module sécurisé 20 décrit ci-dessus en référence à la figure 1 et ne sera donc pas décrit à nouveau.
Le module sécurisé 120 mémorise, par exemple dans sa mémoire non- volatile réinscriptible, la clé publique OT_PK associée (dans une infrastructure à clé publique) à la clé privée OT_SK de l'autorité extérieure et la clé privée OT_Auth_SK déjà mentionnée, fournies par l'autorité extérieure 300 (comme représenté en pointillés en figure 5).
Le processeur 1 10 est relié au module sécurisé 120 et au module de communication 1 16, par exemple au moyen d'un bus, et peut ainsi échanger des données avec ces éléments.
Le module de communication 1 16 permet la connexion du processeur
1 10 à un réseau de télécommunication, comprenant par exemple un réseau de téléphonie mobile (par exemple de type GSM) et un réseau public (tel que le réseau Internet, utilisant par exemple un protocole de type IP), sur lequel est également connecté le serveur du fournisseur d'application 200 et le serveur de l'autorité extérieure 300.
Le processeur 1 10, le serveur du fournisseur d'application 200 et le serveur de l'autorité extérieure 300 peuvent ainsi échanger des données via le module de communication 1 16, comme schématiquement représenté en figure 5, notamment des données utilisées au cours d'un procédé d'authentification tel que celui présenté ci-dessous en référence à la figure 6. Les messages échangés comme décrits ci-dessous peuvent par exemple être placés au sein de requêtes http ou https ou dans des réponses à de telles requêtes.
Comme visible en figure 5, le serveur 200 mémorise la clé racine Prov_Apps déjà mentionnée (générée par le fournisseur d'application et valable pour toutes les applications).
La figure 6 représente les étapes principales d'un quatrième exemple de procédé d'authentification d'une application, mise en œuvre ici dans le cadre du système de la figure 5. En particulier, les étapes de ce procédé mises en œuvre par le processeur 1 10 sont effectuées du fait de l'exécution par le processeur 1 10 de l'application App.
Le procédé de la figure 6 débute à l'étape E100, à laquelle le processeur 100 envoie la donnée de dérivation App_Deriv à destination du serveur 200.
Le serveur 200 reçoit la donnée de dérivation App_Deriv à l'étape E102 et peut ainsi déterminer à l'étape E108 la clé dérivée Prov_App_K par application de la fonction de dérivation G à la clé racine Prov_Apps (mémorisée dans le serveur 200) et à la donnée de dérivation App_Deriv reçue :
Prov_App_K = G(Prov_Apps,App_Deriv).
Le serveur 200 envoie la clé dérivée Prov_App_K au processeur 1 10 à l'étape E106.
Le processeur 1 10 reçoit la clé dérivée Prov_App_K à l'étape E108 et la mémorise (par exemple dans la mémoire vive 1 14) pour utilisation ultérieure (voir ci-dessous les étapes E122 et E142).
Le processeur 1 10 émet alors à l'étape E1 10 la clé publique App_PK et la signature SIG associée, à destination du module sécurisé 120. Comme indiqué pour les procédés des figures 2 et 3, il est envisageable de manière optionnelle d'établir au préalable un canal sécurisé entre le processeur 1 10 et le module sécurisé 120 et de réaliser alors l'émission de l'étape E1 10 et les échanges décrits ci-dessous via ce canal sécurisé.
Le module sécurisé 120 reçoit la clé publique App_PK et la signature
SIG à l'étape E1 12.
Le module sécurisé 120 peut ainsi vérifier à l'étape E1 14 la signature reçue SIG à l'aide de la clé publique OT_PK, comme expliqué ci-dessus pour l'étape E6 dans le cadre de la figure 2.
Si la signature n'est pas correctement vérifiée, le module sécurisé 120 met fin au processus d'authentification, en renvoyant par exemple un message d'erreur au processeur 1 10.
Si la signature est correctement vérifiée, le procédé de la figure 6 se poursuit à l'étape E1 16 à laquelle le module sécurisé 120 génère un défi SE_Ch, par exemple par tirage aléatoire.
Le module sécurisé 120 peut ainsi émettre le défi SE_Ch à destination du processeur 1 10 à l'étape E1 18.
Le processeur 1 10 reçoit le défi SE_Ch à l'étape E120 et détermine à l'étape E122 la clé cryptographique AEK en appliquant la fonction de dérivation F à la clé dérivée Prov_App_K reçue à l'étape E108 et à la donnée de dérivation App_AEK_Deriv mémorisée comme indiqué plus haut dans la mémoire non- volatile 1 12 : AEK = F(Prov_App_K,App_AEK_Deriv).
Le processeur 1 10 peut ainsi déchiffrer à l'étape E124 la clé privée App_SK par application à la version chiffrée [App_SK]AEK (mémorisée dans la mémoire non-volatile 1 12) d'un algorithme cryptographique de déchiffrement utilisant la clé cryptographique AEK déterminée à l'étape E122. La clé privée App_SK ainsi obtenue est mémorisée dans la mémoire vive 1 14 au moins jusqu'à la mise en œuvre de l'étape E126 décrite ci-dessous.
Le processeur 1 10 génère alors à l'étape E126 une signature SIC par application au défi SE_Ch reçu à l'étape E120 d'un algorithme cryptographique de signature utilisant la clé privée App_SK (déchiffrée à l'étape E124).
Le processeur 1 10 génère un défi App_Ch, par exemple par tirage aléatoire, à l'étape E128.
Le processeur 1 10 envoie la signature SIC et le défi App_Ch au module sécurisé 120 à l'étape E130.
Le module sécurisé 120 reçoit la signature SIC à l'étape E132 et peut ainsi vérifier la signature SIC à l'étape E134 en utilisant la clé publique App_PK (dont la signature par l'autorité extérieure a été vérifiée à l'étape E1 14), par exemple comme décrit ci-dessus à propos de l'étape E24.
Si la signature SIC n'est pas correctement vérifiée, le procédé d'authentification a échoué. Le module sécurisé 120 peut alors émettre un message d'erreur à destination du processeur 1 10.
Si la signature SIC est correctement vérifiée à l'étape E134, le processeur 1 10 sur lequel s'exécute l'application App s'est authentifié auprès du module sécurisé 120.
Le procédé se poursuit alors en vue de l'authentification du module sécurisé 120 par le processeur 1 10 sur lequel s'exécute l'application App.
Pour ce faire, le module sécurisé 120 génère à l'étape E136 une signature SIG" par application au défi App_Ch reçu à l'étape E132 d'un algorithme cryptographique de signature utilisant la clé privée OT_Auth_SK (mémorisée dans le module sécurisé 120 comme indiqué plus haut).
Le module sécurisé 120 envoie la signature SIG" ainsi obtenue au processeur 1 10 à l'étape E138.
Le processeur 1 10 reçoit la signature SIG" à l'étape E140 et détermine à l'étape E142 la clé AIK par dérivation à partir de la clé dérivée Prov_App_K (reçue à l'étape E108) et de la donnée de dérivation App_AIK_Deriv (mémorisées dans la mémoire non-volatile 1 12) en utilisant la fonction de dérivation F :
AIK = F(Prov_App_K,App_AIK_Deriv).
Le processeur 10 peut ainsi vérifier à l'étape E144 que le code d'authentification MAC mémorisé en association avec la clé publique OT_Auth_PK est bien égal au résultat de l'application, à la clé publique OT_Auth_PK mémorisée, de l'algorithme de génération de code d'authentification de message utilisant la clé AIK obtenue à l'étape E142, ce qui permet de s'assurer de l'intégrité de la clé publique OT_Auth_PK mémorisée.
Si cette vérification est un échec, le processeur 1 10 met fin au procédé d'authentification, en envoyant par exemple un message d'erreur au module sécurisé 120.
Si la vérification de l'étape E144 est correctement effectuée, le processeur 1 10 vérifie la signature SIG" à l'étape E146 en utilisant la clé publique OT_Auth_PK, par exemple en appliquant à la signature SIG" reçue un algorithme cryptographique de vérification de signature utilisant la clé publique OT_Auth_PK, puis en comparant le résultat obtenu au défi App_Ch généré à l'étape E128.
Si la signature SIG" n'est pas correctement vérifiée, le procédé d'authentification a échoué.
Si la signature SIG" est correctement vérifiée à l'étape E146, le module sécurisé 120 s'est authentifié auprès du processeur 1 10 (sur lequel s'exécute l'application App). On obtient ainsi une authentification mutuelle du processeur 1 10 sur lequel s'exécute l'application App et du module sécurisé 120.
Dans certains modes de réalisation dans lesquels une partie du code de l'application App est mémorisée chiffrée dans la mémoire non-volatile 12, on peut procéder, après une telle authentification mutuelle, au déchiffrement de cette partie mémorisée chiffrée (étape E148), au moyen de la clé cryptographique AEK dans l'exemple donnée plus haut.
Le processeur 1 10 peut alors émettre à l'étape E150 un message de confirmation de l'authentification à destination du module sécurisé 120.
Le module sécurisé 120 reçoit ce message de confirmation à l'étape E152 et peut alors émettre un message signé, par exemple au moyen de la clé privée OT_Auth_SK, à destination du serveur de l'autorité extérieure 300 (E154), où ce message peut être reçu et sa signature vérifiée au moyen de la clé publique OT_Auth_PK (étape E156).
On pourrait prévoir en variante (ou éventuellement en complément de ce qui vient d'être décrit) l'émission par le processeur 1 10 (du fait de l'exécution de l'application App) d'un message signé (par exemple au moyen de la clé privée App_SK) à destination du serveur 200.

Claims

REVENDICATIONS
1 . Procédé d'authentification d'une application (App) exécutée par un processeur (10 ; 1 10) d'un appareil électronique (100), caractérisé en ce qu'il comprend les étapes suivantes :
- dérivation (E14 ; E44 ; E122) d'une clé cryptographique (AEK) à partir d'une donnée (OT_Apps ; OT_App_K ; Prov_App_K) reçue d'une entité électronique extérieure (20 ; 200) ;
- déchiffrement (E16 ; E46 ; E124), au moyen de la clé cryptographique dérivée (AEK), d'une clé secrète mémorisée chiffrée ([App_SK]AEK) ;
- émission (E20 ; E52 ; E140) de données d'authentification (SIC) préparées au moyen de la clé secrète déchiffrée (App_SK).
2. Procédé d'authentification selon la revendication 1 , dans lequel la clé secrète chiffrée ([App_SK]AEK) est mémorisée dans une mémoire non-volatile réinscriptible (12 ; 1 12) et dans lequel la clé secrète déchiffrée (App_SK) est mémorisée dans une mémoire vive (14 ; 1 14).
3. Procédé d'authentification selon la revendication 1 ou 2, comprenant les étapes suivantes :
- réception (E12 ; E42 ; E120) d'un défi (SE_Ch) ;
- préparation (E18 ; E48 ; E126) desdites données d'authentification
(SIC) par application au défi reçu (SE_Ch) d'un algorithme cryptographique utilisant la clé secrète déchiffrée (App_SK).
4. Procédé d'authentification selon l'une des revendications 1 à 3, dans lequel ladite donnée reçue (OT_App_K ; Prov_App_K) est préparée par l'entité électronique extérieure (20 ; 200) sur la base d'une donnée (App_Deriv) reçue de l'application (App) et d'une clé (OT_Apps ; Prov_Apps) mémorisée dans l'entité électronique extérieure (20 ; 200).
5. Procédé d'authentification selon l'une des revendications 1 à 4, dans lequel les données d'authentification (SIC) sont émises à destination d'un module sécurisé (20).
6. Procédé d'authentification selon la revendication 5, comprenant une étape d'émission par le module sécurisé (20) d'un message signé au moyen d'une clé privée (OT_Auth_SK) mémorisée dans le module sécurisé (20) à destination d'un serveur (300).
7. Procédé d'authentification selon la revendication 5 ou 6, dans lequel l'entité électronique extérieure est le module sécurisé (20).
8. Procédé d'authentification selon l'une des revendications 1 à 6, dans lequel l'entité électronique extérieure est un serveur (200).
9. Procédé d'authentification selon l'une des revendications 5 à 8, la revendication 8 étant prise dans la dépendance de la revendication 5 ou 6, dans lequel la clé secrète est une clé privée (App_SK), le procédé d'authentification comprenant les étapes suivantes :
- vérification (E6 ; E34 ; E1 14), par le module sécurisé (20) et au moyen d'une première clé publique (OT_PK) mémorisée dans le module sécurisé (20), d'une signature (SIG) annexée à une seconde clé publique (App_PK) associée à ladite clé privée (App_SK) ;
- vérification (E24 ; E56 ; E134), par le module sécurisé (20), desdites données d'authentification (SIC) au moyen de la seconde clé publique (App_PK).
10. Procédé d'authentification selon l'une des revendications 5 à 9, la revendication 8 étant prise dans la dépendance de la revendication 5 ou 6, comprenant en outre un processus d'authentification (E58, E68 ; E136 ; E146) du module sécurisé (20) auprès de l'application (App).
1 1 . Procédé d'authentification selon la revendication 10, dans lequel le processus d'authentification du module sécurisé auprès de l'application utilise une clé publique (OT_Auth_PK) mémorisée au sein de l'appareil électronique en association avec un code d'authentification de message (MAC) produit par une autorité extérieure (30 ; 300).
12. Procédé d'authentification selon l'une des revendications 5 à 1 1 , la revendication 8 étant prise dans la dépendance de la revendication 5 ou 6, dans lequel le module sécurisé (20) est un élément sécurisé.
13. Procédé d'authentification selon l'une des revendications 1 à 12, dans lequel l'appareil électronique est un téléphone mobile.
14. Procédé d'authentification selon l'une des revendications 1 à 12, dans lequel l'appareil électronique est une tablette numérique.
15. Procédé d'authentification selon l'une des revendications 1 à 12, dans lequel l'appareil électronique comprend un élément de maintien sur une partie du corps de l'utilisateur.
16. Procédé d'authentification selon l'une des revendications 1 à 15, comprenant une étape d'émission par l'application (App) d'un message signé au moyen de la clé secrète déchiffrée (App_SK) à destination d'un serveur (200).
17. Procédé d'authentification selon l'une des revendications 1 à 16, comprenant une étape de déchiffrement d'une partie d'un code exécutable de l'application au moyen de la clé cryptographique dérivée (AEK).
18. Appareil électronique comprenant un processeur (10 ; 1 10) et au moins une mémoire (12 ; 1 12) mémorisant une application (App) exécutable par le processeur (10 ; 1 10), l'application (App) étant conçue de sorte que le processeur (10 ; 1 10) mette en œuvre un procédé selon l'une des revendications 1 à 17 lorsque l'application (App) est exécutée par le processeur (10 ; 1 10).
19. Programme d'ordinateur (App) comprenant des instructions exécutables par un processeur (10 ; 1 10) d'un appareil électronique et conçues de sorte que le processeur (10 ; 1 10) mette en œuvre un procédé selon l'une des revendications 1 à 17 lorsque ces instructions sont exécutées par le processeur (10 ; 1 10).
PCT/FR2015/053586 2014-12-22 2015-12-17 Procédé d'authentification d'une application, appareil électronique et programme d'ordinateur associés WO2016102832A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1463169 2014-12-22
FR1463169A FR3030821B1 (fr) 2014-12-22 2014-12-22 Procede d'authentification d'une application, appareil electronique et programme d'ordinateur associes

Publications (1)

Publication Number Publication Date
WO2016102832A1 true WO2016102832A1 (fr) 2016-06-30

Family

ID=52478001

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2015/053586 WO2016102832A1 (fr) 2014-12-22 2015-12-17 Procédé d'authentification d'une application, appareil électronique et programme d'ordinateur associés

Country Status (2)

Country Link
FR (1) FR3030821B1 (fr)
WO (1) WO2016102832A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021127666A1 (fr) * 2019-12-17 2021-06-24 Microchip Technology Incorporated Protocole d'authentification mutuelle pour systèmes à liaisons de communication à faible débit et dispositifs permettant sa mise en œuvre

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060211490A1 (en) * 2005-03-17 2006-09-21 Falvey Grahame M Security for gaming devices
US20110131401A1 (en) * 2009-12-02 2011-06-02 Bally Gaming, Inc. Authentication system for gaming machines and related methods
US20130124860A1 (en) * 2010-07-19 2013-05-16 Monika Maidl Method for the Cryptographic Protection of an Application
US20140139318A1 (en) * 2012-11-21 2014-05-22 Ca, Inc. Mapping Biometrics To A Unique Key

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060211490A1 (en) * 2005-03-17 2006-09-21 Falvey Grahame M Security for gaming devices
US20110131401A1 (en) * 2009-12-02 2011-06-02 Bally Gaming, Inc. Authentication system for gaming machines and related methods
US20130124860A1 (en) * 2010-07-19 2013-05-16 Monika Maidl Method for the Cryptographic Protection of an Application
US20140139318A1 (en) * 2012-11-21 2014-05-22 Ca, Inc. Mapping Biometrics To A Unique Key

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Encyclopedia of Cryptography and Security", 26 October 2011, SPRINGER, ISBN: 978-1-4419-5905-8, pages: 679 - 680, XP055223776 *

Also Published As

Publication number Publication date
FR3030821A1 (fr) 2016-06-24
FR3030821B1 (fr) 2017-01-13

Similar Documents

Publication Publication Date Title
EP3152860B1 (fr) Procédé d'authentification d'une première entité électronique par une seconde entité électronique et entité électronique mettant en oeuvre un tel procédé
US10027631B2 (en) Securing passwords against dictionary attacks
EP1401142A1 (fr) Procede de signature electronique, programme et serveur pour la mise en oeuvre du procede
EP3308564B1 (fr) Procédé de chargement d'une clé virtuelle et terminal utilisateur associé
FR2936391A1 (fr) Procede d'echange de donnees, telles que des cles cryptographiques, entre un systeme informatique et une entite electronique, telle qu'une carte a microcircuit
WO2016102833A1 (fr) Entité électronique sécurisée, appareil électronique et procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée
EP3395040B1 (fr) Procédé de réception de données au sein d'une entité électronique et entité électronique associée
EP3419246B1 (fr) Procédé d'authentification par défi-réponse d'un élément sécurisé (se) auprès d'un microcontrôleur
EP3343967B1 (fr) Procédés mis en oeuvre par un dispositif et dans un réseau, entité électronique associée
EP3219077B1 (fr) Procédé et système de gestion d'identités d'utilisateurs destiné à être mis en oeuvre lors d'une communication entre deux navigateurs web
WO2016102832A1 (fr) Procédé d'authentification d'une application, appareil électronique et programme d'ordinateur associés
WO2016102834A1 (fr) Procédé d'authentification d'un utilisateur et d'un module sécurisé, appareil électronique et système associes
US20160057118A1 (en) Communication security system and method
EP3340096B1 (fr) Procédé de configuration d'un programme cryptographique destiné à être exécuté par un terminal
EP4227832A1 (fr) Schema d'authentification post-quantique optimise sans signature, procedes et dispositifs
WO2017077211A1 (fr) Communication entre deux éléments de sécurité insérés dans deux objets communicants
EP3270315B1 (fr) Procédé de mise en relation sécurisée d'un premier dispositif avec un deuxième dispositif
WO2021074527A1 (fr) Procede de gestion d'une base de donnees de cles publiques, procede d'authentification de cles publiques, et dispositifs serveur et client mettant en oeuvre ces procedes
WO2022135952A1 (fr) Procédé et dispositif de génération d'informations d'authentification pour une entité sécurisée et procédé et dispositif de contrôle d'identité associés
WO2020128215A1 (fr) Réinitialisation d'un secret applicatif au moyen du terminal
FR3044847A1 (fr) Procede d'echange de donnees au sein d'un groupe d'entites electroniques
EP3917073A1 (fr) Établissement efficace de sessions sécurisées pour l'anonymat dans les réseaux 5g
Lee KeySlinger and StarSlinger: Secure Key Exchange and Encrypted File Transfer on Smartphones
FR2982724A1 (fr) Communication securisee

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15828743

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15828743

Country of ref document: EP

Kind code of ref document: A1