Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
  • H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
  • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
  • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
  • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
  • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
  • H04L2463/061—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying further key derivation, e.g. deriving traffic keys from a pair-wise master key
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
  • H04L2463/062—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying encryption of the keys
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
  • Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
  • Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
  • Y04S40/20—Information technology specific aspects, e.g. CAD, simulation, modelling, system security

Definitions

• a method of receiving data within an electronic entity A method of receiving data within an electronic entity
• the present invention relates to the secure exchange of data between electronic devices.
• It relates more particularly to a method of receiving data within an electronic entity and an associated electronic entity.
• the invention is particularly advantageous in the case where identical data must be communicated securely to a large number of electronic entities.
• the cryptographic key is a session key derived from a static key known only to the two electronic devices.
• this solution is not adapted to the transmission of the same set of data to a large number of electronic entities (as is the case for example during a campaign to update a part of the system of a large number of secure elements) since it is then necessary to prepare a dedicated encrypted version for each electronic entity concerned.
• the present invention proposes a method of receiving data within an electronic entity, characterized in that it comprises the following steps:
• the first secure channel can thus be diversified in order to securely communicate the second cryptographic key to the electronic entity, for example by using a protocol of the SCP03 type as indicated above.
• the first secure channel is for example based on a SCP03 type protocol in non-predictive mode, while the second secure channel is for example based on a SCP03 type protocol in predictive mode.
• the second cryptographic key is for example included in the first command.
• the method comprises a step of saving the first cryptographic key (and for example further associated contextual data) in a memory (for example a random access memory) of the electronic entity (the first cryptographic key and any associated contextual data forming data for restoring the first secure channel);
• the method comprises a step of switching to the first secure channel
• the switching step comprises a substep of reading the first cryptographic key stored in the memory (live);
• the method comprises a step of invalidating restoration data of the first secure channel; after the switching step, the method comprises a step of waiting for an authorization command in the first secure channel;
• the method may comprise a step of receiving an integrity check code in the first secure channel
• the first cryptographic key is a session key derived from an static key stored in the electronic entity
• the second cryptographic key is a broadcast key used to encrypt a secure channel established by another electronic entity
• the data represents, for example, a part of an operating system, at least part of an application or data that can be used later by the electronic entity;
• the received data are stored in a non-volatile memory of the electronic entity
• the electronic entity is a secure element
• the external electronic device is a mobile terminal or a power supply meter or a connected object or a portable object.
• the invention also proposes an electronic entity characterized in that it comprises a module for establishing, between the electronic entity and an external electronic device, a first encrypted secure channel by means of a first cryptographic key; a reception module, via the first secure channel, of a first command and a second cryptographic key; an implementation module, because of the execution of said first command, a second secure channel by encryption by means of the second cryptographic key; and a data receiving module in the second secure channel.
• the electronic entity comprises a processor
• at least some of the modules may be at least partially realized by means of computer program instructions stored in a memory of the electronic entity and designed to participate in the implementation of the functionality of the affected module when these instructions are executed by the processor.
• the data is sent in broadcast mode and the authorization command can be sent later to trigger the use of the loaded data.
• the server from the supplier or manufacturer
• the server always retains control over the secure element (because before the authorization, there is an integrity check phase that is carried out).
• the use of the diversified channel for this command makes it possible to address terminals individually and to ensure that the operation is carried out in due time and with the desired effect;
• step E18 makes it possible not to repeat the configuration of the diversified mode when switching from one mode to another.
• the context of the diversified mode is saved. In other embodiments, however, it would be possible to provide a context backup for each of the modes used (for example diversified and multi-user) before switching to the other mode.
• FIG. 1 represents an example of a secure element used in the context of the invention
• FIG. 2 is a logic diagram showing an exemplary method implemented within the secure element of FIG. 1;
• FIG. 3 represents a first possible context of use of the method of FIG. 2;
• FIG. 4 represents a second possible context of use of the method of FIG. 2.
• FIG. 5 is a logic diagram showing an exemplary method of updating the operating system of the secure element of FIG. 1.
• FIG 1 shows an example of secure element 2 used in the context of the invention.
• This secure element 2 (or SE for “Secure Element”) is for example made in the form of a microcontroller.
• Such a secure element 2 may optionally be integrated with an electronic device, for example by being welded within the electronic device: the secure element is then of type eSE (for "embedded Secure Element").
• the secure element 2 could be a microcircuit card (for example a universal microcircuit card or UlCC for "Universal Integrated Circuit Card”), or a universal microcircuit card welded or eUICC for "embedded Universal Circuit Card”.
• a microcircuit card for example a universal microcircuit card or UlCC for "Universal Integrated Circuit Card”
• UlCC Universal Integrated Circuit Card
• eUICC embedded Universal Circuit Card
• the secure element 2 comprises a processor 4 (for example a microprocessor), a non-volatile memory 6 (for example a rewritable non-volatile memory) and a random access memory 8.
• a processor 4 for example a microprocessor
• a non-volatile memory 6 for example a rewritable non-volatile memory
• a random access memory 8 for example a random access memory 8.
• the non-volatile memory 6 is for example of Flash or NVRAM type.
• the non-volatile memory 6 stores program instructions that allow the implementation of data processing methods (in particular that described below with reference to FIG. 2) by the secure element 2 when these instructions are executed by the user. processor 4.
• the non-volatile memory 6 also stores data used during the implementation of such methods: the non-volatile memory 6 notably stores cryptographic keys (called static keys) used in the methods described below, in particular a set of static cryptographic keys K.
• static keys used in the methods described below, in particular a set of static cryptographic keys K.
• the RAM 8 stores data manipulated by the methods implemented within the secure element 2.
• the secure element 2 also comprises at least one interface 10 allowing the processor 4 to exchange data with other electronic devices.
• the interface 10 may be formed by one or more pins (s) of the microcontroller.
• the interface comprises at least one of the contacts flush with the upper face of the microcircuit card.
• the interface can also be a port of ISO, SWP or SPI type.
• FIG. 2 represents an example of a method implemented within the secure element 2.
• This method starts in step E2 by the reception, by the processor 4 and on the interface 10, of a launch command IU containing a host challenge (in English: "host challenge”) HCH.
• the launch command IU is for example a command of the type INITIALIZE UPDATE as defined in paragraph 7.1.1 of the document "GlobalPIatform Card Technology - Secure Channel Protocol 03 - Card Specification v 2.2 Amendment D" or in Annex D.4.1 document "GlobalPIatform Card Specification v 2.2".
• processor E4 Upon receipt of the IU launch command, processor E4 implements steps E4 and E6 now described.
• the processor 4 generates in step E4 a card challenge (in English: "card challenge") CCH, for example by random draw or, alternatively, by pseudo-random determination.
• a card challenge in English: "card challenge”
• CCH card challenge
• the pseudo-random determination makes it possible to obtain, by calculation from stored data within the electronic entity 2, an unpredictable CCH card challenge for an unauthorized third party.
• the pseudo-random determination for an authorized third party makes it possible to calculate the map challenge and possibly to pre-generate it.
• the challenge of CCH card is determined according to a sequencer (in English: "sequence counter"), an identifier of the application issuing the launch command UI and a cryptographic key K Of the set of static cryptographic keys K stored in the non-volatile memory 6.
• the processor 4 then generates in step E6 a set of session keys SK, here using the static keys of the set of static cryptographic keys K stored in the non-volatile memory 6.
• the processor 4 generates in particular at this step a key encryption or decryption session SK-ENC on the basis of the K-ENC cryptographic key already mentioned, and here also on the basis of the host challenge HCH and the challenge of CCH card, for example according to what provided in section 6.2.1 of "GlobalPIatform Card Technology - Secure Channel Protocol 03 - Card Specification v 2.2 Amendment D" (v1 .1).
• the secure element 2 could then possibly return the challenge of CCH card generated in step E4 to the electronic device issuing commands.
• the CCH card challenge is obtained by pseudo-random determination as described here, the issuance of the CCH card challenge is not necessary since the issuing electronic device can obtain the CCH card challenge through the same process. pseudo-random determination.
• the processor 4 then receives on the interface 10 an authentication command EA, accompanied by a host cryptogram HAC.
• This HAC host cryptogram has been previously determined within the electronic device issuing the commands by using an S-MAC session key of the session key set, the host challenge HCH (previously issued with the launch command IU as indicated above) and the CCH card challenge (obtained here by pseudo-random determination as indicated above).
• the launch command EA is for example a command of the type EXTERNAL AUTHENTICATE as defined in paragraph 7.1 .2 of the document "GlobalPIatform Card Technology - Secure Channel Protocol 03 - Card Specification v 2.2 Amendment D" (v1 .1) or in the Appendix D.4.2 document "GlobalPIatform Card Specification v 2.2".
• the processor checks in step E10 whether the received host cryptogram HAC corresponds to the expected cryptogram, which makes it possible to authenticate the electronic device that sends the commands.
• step E12 the processor 4 terminates the exchange without establishing a secure channel.
• a secure channel is established between the electronic device issuing commands and the secure element 2. It qualifies this secure channel diversified (see the mention DIVERSIF. in FIG. 2) because the session keys SK used to ensure the confidentiality of the exchanges (in particular the encryption or decryption session key SK-ENC) are known only to the electronic device issuing the commands and the secure element 2 (and would be different for example if the electronic device issuing commands wanted to establish a secure channel with another secure element). It is noted that, in the case of the SCP-03 protocol, three diversified keys are used, under the usual denomination SK-ENC, SK-MAC and SK-RMAC.
• the processor 4 then receives in step E14, via this secure channel, a CHM switchover command, accompanied by a set of broadcast keys BK (as well as, in the example described here, an encryption counter and a verification code chaining value). It is proposed here to introduce such a switching control, for example in the form of a dedicated command, called CHANGE MODE.
• the data appended to the command (here in particular the broadcast keys BK with, for example, additional data enabling the setting up of a second secure channel) are encrypted by the SK-ENC encryption or decryption session key.
• the processor 4 thus proceeds to step E16 to decrypt the BK broadcast keys by means of a decryption cryptographic algorithm (here symmetric) using the encryption or decryption session key SK-ENC (obtained as explained above). in step E6).
• the cryptographic algorithm used is for example of the AES type.
• the processor 4 then proceeds to step E18 to a backup (noted
• BCK.UP in FIG. 2 of the context in a dedicated zone of the random access memory 8 (or, alternatively, in non-volatile memory 6).
• the processor 4 saves in particular in this dedicated area of the RAM 8 SK session keys (including the key encryption session or decryption SK-ENC).
• the processor 4 also stores in the dedicated zone an encryption counter (in English: "broker encryption”) and a verification code chaining value (in English: “MAC chaining value”) associated with the diversified secure channel (and distinct from those received in step E14).
• an encryption counter in English: "broker encryption”
• a verification code chaining value in English: "MAC chaining value”
• the processor 4 then switches to step E20 in a broadcast mode or multiuser mode (see MULTIU in Figure 2), in which the broadcast keys BK are used in place of the SK session keys.
• the encryption counter and the chaining value received in step E14 are also used here.
• the electronic device issuing the commands and the secure element 2 can exchange in a secure channel whose confidentiality is ensured by encryption by means of a broadcast key.
• BK-ENC encryption or decryption used in place of the SK-ENC encryption or decryption session key).
• this "broadcast” or “multiuser” mode of operation is denoted by the fact that the broadcast keys BK are used to process (in particular encrypt) data intended for a plurality (or even a large number). number) of secure elements.
• the processor 4 then receives in step E22 a command CMDi, to which are appended data Di.
• a command CMDi to which are appended data Di.
• the data appended to the received commands are now encrypted by the encryption or decryption broadcast key BK-ENC.
• the processor 4 thus proceeds to step E24 to decrypt the data D1 by applying a decryption cryptographic algorithm (here symmetric) using the encryption or decryption broadcast key BK-ENC received in step E14.
• a decryption cryptographic algorithm here symmetric
• the decrypted Di data can thus be used within the secure element 2 (step E26), here being saved in the nonvolatile memory 6.
• the data Di represent a part at least one application operating system loaded in the secure element 2 from a remote server.
• this data could alternatively represent an application (which is not part of the operating system), cryptographic keys, or data used by an application component outside the operating system.
• the processor 4 receives a CHM switching command (step E28) with a view to returning to the diversified mode, for example the CHANGE MODE type control supra.
• a CHM switching command for example the CHANGE MODE type control supra.
• the same command allows the passage in the broadcast mode (or multiuser) when the processor 4 operates in the diversified mode and the transition to the diversified mode when the processor 4 operates in the broadcast mode.
• two separate commands could be provided to implement these two switches, respectively.
• the processor 4 Upon receipt of this command, the processor 4 reads the session keys SK in the aforementioned area of the RAM 8 (where these session keys have been saved in step E18 as explained above), and here the counter encryption and the chaining value, and switches to step E30 in the diversified mode using these session keys SK.
• the processor 4 can again use the secure channel implemented by the steps E2 to E10. It may possibly be expected then that following this switch to diversified mode, the recovery data are disabled (for example erased) so that it will not be possible to perform such a switch again later.
• the processor 4 then receives at step E32 an ATHZ authorization command to which is appended a MAC integrity check code allowing a verification of the data DI installed (that is to say, stored here in the non memory). -volatile 6) in step E26, possibly during several passes at this step. Examples of obtaining the MAC integrity check code are given below.
• the authorization command is for example a new command that is proposed here to introduce, under the name AUTHORIZE_ACTION.
• the data appended to this command (here the MAC integrity verification code) is encrypted by means of the encryption or decryption session key SK-ENC .
• the processor 4 thus proceeds to step E34 to decrypt the integrity check code MAC, by applying a decrypting (here symmetrical) cryptographic algorithm using the encryption or decryption session key SK-ENC.
• the cryptographic algorithm is here an algorithm of the AES type.
• the processor 4 can then verify in step E36 the integrity of the data Di stored in the non-volatile memory 6 during the passage (s) to the step E26 using the deciphered MAC integrity verification code.
• step E36 If the verification of step E36 fails, processor 4 does not use data Di, but implements error processing in step E38, for example by returning an error message to the electronic device responsible for generating the commands, for example a remote server.
• step E36 If the verification of step E36 is successful, the processor 4 controls, for example, the transmission in step E40, via the interface 10, of a good operation message. During its operation, the processor 4 will then use the data Di stored in the non-volatile memory 6 in step E26. In the examples described below, at least parts of the application operating system represented by the data Di will be executed by the processor 4.
• Figures 3 and 4 show two possible contexts of use of a method as just described.
• a primary LOADER part on the secure element 2 (that is to say, stored in the non-volatile memory 6) is for example here responsible for loading the data sent.
• the data sent can be used by the secure element 2 without the deployment of the primary part LOADER (this is the case for example of a standalone application that can be executed without intervention of the primary part LOADER after loading).
• the LOADER primary portion could further be used to initiate the deployment of the loaded data.
• the application portion DATASEND is available at a design computer system 30.
• This design computer system 30 is for example managed by the manufacturer of the secure element 2.
• the design computer system 30 has a high level of security.
• the DATASEND application part must be sent to the secure element
• the secure element 2 via a management server 20, for example managed by a mobile operator or manufacturer.
• the secure element 2 is precisely associated with this mobile operator or manufacturer. Precisely, the secure element 2 stores data allowing a user terminal carrying the secure element 2 access to at least one mobile telephone network operated by the mobile operator.
• the aforementioned user terminal is not mentioned in FIGS. 3 and 4 for the sake of simplification. However, it will be understood that the data exchanges between the management server 20 and the secure element 2 use telecommunication means of the user terminal (as well as possibly the aforementioned mobile telephone network).
• the management server 20 has an average level of security.
• a security module 25 is provided which is connected (via a secure link) to the management server 20 (for example by means of a wired link, here Ethernet type) and which has a high level of security.
• the security module 25 is for example HSM type (for "Hardware Security Module”).
• the security module 25 stores the set of static keys K associated with the secure element 2 (and also stored in the non-volatile memory 6 of the secure element 2 as already indicated). Note that the security module 25 stores (or can obtain, for example by derivation from an identifier of the secure element and a master key) a specific set of static keys K for any secure element managed by the management server 20.
• the design computer system 30 and the secure element 2 store a symmetric key Kos, here common to a large number of secure elements and used to encrypt the DATASEND application parts to be installed on these elements. secure.
• This common key K 0 s is managed by the manufacturer of the secure elements 2 and remains confined in these secure elements 2 and the design computer system 30.
• the design computer system 30 further stores the set of broadcast keys (or campaign keys) BK, which here includes the encryption or decryption broadcast key BK-ENC already mentioned and a BK-MAC broadcast key designed to generate an integrity check code.
• BK broadcast (or campaign) keys are used for all the secure elements that must receive the DATASEND application part (ie in practice an update of their operating system or an update of an application).
• the design computer system 30 can therefore transmit to the management server 20:
• the management server 20 transmits the broadcast keys BK-ENC, BK-
• This encryption or decryption session key SK-ENC is obtained in parallel within the security module 25 and within the secure element 2 (as already described above) on the basis notably of a static key K- ENC of the set of static keys K (stored in the security module 25 and in the non-volatile memory 6 of the secure element 2).
• BK-ENC, BK-MAC, and MAC integrity verification keys are encrypted in a diversified manner (that is, by producing an encrypted version for each secure element to be updated) and processing at the level of the security module 25 are therefore limited (compared in particular to a situation where an encrypted version of the entire application portion DATASEND should be generated for each secure element to update).
• the broadcast keys BK-ENC, BK-MAC are transmitted doubly encrypted (encrypted by the common key K 0 s and encrypted by the session key SK-ENC).
• the broadcast keys BK-ENC, BK-MAC can then be transmitted from the management server 20 to the secure element 2 according to the step E14 of FIG. 2, after establishment of a secure link in accordance with the steps E2 to E10. of Figure 2.
• the BK-ENC, BK-MAC broadcast keys are decrypted within the secure element 2, on the one hand by using the encryption or decryption session key SK-ENC (as indicated in step E16 of FIG. Figure 2) and here on the other hand using the common key Kos (stored within the non-volatile memory 6 as already mentioned).
• the application part DATASEND can then be transmitted from the management server 20 to the secure element 2 (this application part DATASEND is encrypted by means of the encryption or decryption key BK-ENC as indicated above).
• the secure element 2 can then receive the integrity check code MAC (here encrypted by the symmetric key Kos) of the management server 20 via the secure channel by the encryption or decryption session key SK-ENC, and then check the integrity of the DATASEND application part using the MAC integrity check code and the BK-MAC broadcast key according to steps E32 to E36 of FIG.
• MAC integrity check code
• the design computer system 30 stores a common KMAC integrity key stored in a large number of secure elements and used to verify the integrity of the DATASEND application parts installed on these secure elements.
• This KMAC common integrity key is managed by the manufacturer of secure elements 2 and remains confined within these secure elements 2 and the design computer system 30.
• the design computer system 30 can therefore transmit to the management server 20:
• the MAC integrity check code determined on the basis of the KMAC common integrity key and the DATASEND application part.
• the security module 25 associated with the management server 20 stores (in addition to the set of static keys K) a broadcast key (or campaign) encryption or decryption BK-ENC.
• the security module 25 can therefore establish a secure channel (by encryption by means of an encryption or decryption session key SK-ENC generated on the basis of the static key K-ENC) with the secure element 2 according to the steps E2 to E10 of FIG. 2, then transmit the encryption or decryption broadcast key BK-ENC via this secure channel for reception by the secure element 2 in accordance with the step E14 of FIG. 2.
• the data D 1 obtained after decryption by means of a decryption algorithm using the encryption or decryption diffusion key BK-ENC here represent (at least part of) the application part DATASEND encrypted by means of the common key K 0 s-
• the processor 2 thus proceeds here in addition to the decryption of the application part DATASEND by application of a decryption algorithm using the common key Kos-
• the application part DATASEND is then stored in the non-volatile memory 6 (which corresponds to the step E26 of FIG. 2).
• the secure element 2 finally receives the MAC integrity check code from the management server 20 via the secure channel by the encryption or decryption session key SK-ENC, then verifies the integrity of the application part DATASEND using the integrity check code MAC and the common integrity key K M AC, according to steps E32 to E36 of FIG. Note that, in the example of Figure 3 as in that of Figure 4, the steps of Figure 2 used are implemented due to the execution of instructions of the primary operating system LOADER by the processor 2.
• the encryption or decryption session key SK-ENC is a symmetric key obtained by derivation from a static key K-ENC stored at the element level at the same time.
• secure 2 and at the electronic device here the security module 25 wishing to establish a secure channel with the secure element 2.
• the encryption or decryption session key SK-ENC to be a symmetric key obtained, at the level of the secure element 2, by derivation notably from a private key ksE stored in the element 2, and, at the electronic device, by derivation from including another private key ⁇ ⁇ ⁇ stored in this electronic device, in accordance with a public key based key negotiation technique, as provided by example in the document "Card Secure Channel Protocol ⁇ 1 'Card Specification v2.2 - Amendment F (v1.0)".
• FIG. 5 is a logic diagram showing an example of a method for updating the operating system of the secure element 2.
• This method starts in step E100 by preparing, within the design computer system 30, a set of data PSE to be loaded into the non-volatile memory 6 of the secure element 2.
• This PSE dataset contains here the DATASEND application part of the operating system to be updated.
• the data set PSE is for example formed to do N write commands CMDi each containing a portion of the application part DATASEND, in encrypted form by a key broadcast (or campaign) BK-ENC.
• a CHM command (without an attached cryptographic key), as mentioned in step E28 of FIG. 2, can also be placed at the end of the sequence of the N CMDi write commands.
• the BK-ENC broadcast key is used for a large number of secure elements and the prepared data can be sent (as explained below) with a form identical to all these elements secured for updating their system. exploitation.
• the design computer system 30 proceeds to step E102 to sending the PSE data set to the management server 20.
• the management server 20 receives the set of data PSE in step E104 and here combines in step E106 this set of data PSE with another set of PMOB data to be loaded on the user terminal 15 (for example a mobile phone or cellular phone) carrying the secure element 2.
• the user terminal 15 for example a mobile phone or cellular phone
• the management server 20 proceeds to step E108 when the data sets PSE, PMOB are sent to the user terminal 15 (for example by using in particular the mobile telephone network associated with the management server 20 and with the element secure 2).
• the user terminal 15 receives the data sets PSE, PMOB in the step E1 10.
• the operation of the user terminal 15 switches from a versatile execution environment, or REE for "Rich Execution Environment ", to a trusted execution environment or TEE for" Trusted Execution Environment "(for example implemented due to the execution of a trusted operating system), and that the P S data sets E, PMOB are received as part of the execution of an application (eg "midlet" type) within this trusted execution environment.
• the user terminal 15 extracts the data set PSE from the received data P S E, PMOB in the step E1 12 and proceeds with the processing of said other set of data P M OB in the step E1 14, for example by storing these data in a memory of the user terminal 15.
• the user terminal 15 then sends in step E1 16 (for example at a later time of operation) a REQ update authorization request to the management server 20.
• This REQ request is received by the management server In step E1 18.
• the management server 20 then prepares in step E124 a set of authorization data ⁇ ⁇ ⁇ ⁇ .
• This set of authorization data ⁇ ⁇ ⁇ comprises, for example, the encryption key BK-ENC encrypted by a cryptographic key specifically associated with the secure element 2, for example a session key SK-ENC that only the management server 20 and the secure element 2 can generate.
• the set of authorization data PAUT is here produced in the form of the command sequence IU, EA, CHM, ATHZ presented above in reference to Figure 2.
• the management server 20 transmits the authorization data set PAUT to the user terminal 15 in step E128.
• the user terminal 15 receives the authorization data set PAUT in step E130.
• the user terminal 15 can then combine in step E132 the set of data PSE (received in step E1 10 and extracted in step E1 12) and the set of authorization data PAUT, here by inserting the command the dataset PSE immediately after mode switching control CHM all ⁇ ⁇ authorization data ⁇ -
• the data contained in the commands of the PSE data set are encrypted by means of the BK-ENC broadcast key shared by several secure elements (in practice, a large number of secure elements). and these commands must therefore be received after switching from the secure element 2 to multiuser mode.
• the user terminal 15 sends in step E134 the commands prepared (by combination) in step E132 to the secure element 2.
• step E134 the commands prepared (by combination) in step E132 to the secure element 2.
• step E132 the successive sending of these commands in a single step is represented.
• each step is sent separately from the user terminal 15 to the secure element 2.
• the secure element 2 receives and executes successively each of the commands, as described above with reference to FIG. 2 (represented schematically by the step E136).
• the secure element 2 transmits ST status information (step E138), as explained above with respect to the step E40 of FIG. 2.
• the state information ST is received by the user terminal 15 in step E140 and sent to step E142 to the management server 20.
• the management server 20 receives the state information ST in the step E144 and performs a processing according to the state information ST, for example by allowing the access of the user terminal equipped with the secure element 2 on the mobile telephone network if the state information ST confirms the correct update of the operating system of the secure element 2 and performing other actions (for example: new loading test, prohibition of access to the network for the user terminal 15 concerned) if the status information ST does not confirm the correct update.
• Authorization data ⁇ ⁇ ⁇ allow, for example, the activation of functionalities defined by data sets P S E, PMOB-
• the method which has just been described thus makes it possible to minimize the exchanges at the moment of activation of these data sets. features. Indeed, by preloading the data sets PSE, PMOB steps E100 to E1 14, only the PAUT authorization data are transmitted at the time of activation.

Landscapes

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

Priority Applications (5)

Applications Claiming Priority (2)

Publications (1)

Family

ID=56068982

Family Applications (1)

Country Status (7)

Families Citing this family (5)

Citations (1)

Family Cites Families (12)

• 2015
  • 2015-12-21 FR FR1562996A patent/FR3046000B1/fr active Active
• 2016
  • 2016-12-20 WO PCT/FR2016/053581 patent/WO2017109389A1/fr not_active Ceased
  • 2016-12-20 US US16/064,394 patent/US20190007383A1/en not_active Abandoned
  • 2016-12-20 JP JP2018532423A patent/JP6889161B2/ja active Active
  • 2016-12-20 CN CN201680081592.1A patent/CN108702353B/zh not_active Expired - Fee Related
  • 2016-12-20 KR KR1020187018434A patent/KR102574846B1/ko active Active
  • 2016-12-20 EP EP16826416.6A patent/EP3395040B1/fr active Active

Patent Citations (1)

Also Published As

Similar Documents

Legal Events