Data protection

Abstract

The embodiment of the invention relates to data protection. An electronic device receives a software module of a first application, wherein the software includes a public key associated with the first application. Cryptographic circuitry of an electronic device generates an encryption key based on a secret key of the electronic device and one of a public key or an identification value derived from the public key. The cryptographic circuitry then generates one or more protected data items by applying a cryptographic operation to one or more first data items associated with the first application and based on the encryption key. The one or more protected data items are then stored in a first portion of a memory of the electronic device.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of priority of French Patent Application No. 2400497, filed on January 18, 2024, the content of which is incorporated herein by reference in its entirety to the maximum extent permitted by law. Technical Field

[0003] The present disclosure generally relates to the protection of data generated and / or used by applications implemented by an electronic device. Background Art

[0004] It is common practice to use electronic devices and systems configured to perform multiple different functions, which functions are themselves implemented by software applications.

[0005] There is a desire to be able to improve at least in part certain aspects of the software architecture. More specifically, there is a desire to be able to improve at least in part certain aspects of the security of the data manipulated by software applications. For example, it is generally desired that software applications installed in a device cannot access the secrets of other software applications installed in and / or previously installed in that device. Summary of the Invention

[0006] One embodiment provides a method that includes: a) receiving, by an electronic device, a software module of a first application, the software module including a public key associated with the first application; b) generating, by a cryptographic circuit of the electronic device, an encryption key based on a secret key of the electronic device and one of the public key and an identification value derived from the public key; c) generating, by the cryptographic circuit, one or more protected data by applying a cryptographic operation to one or more first data items associated with the first application and based on the encryption key; and d) storing the one or more protected data items in a first portion of a memory of the electronic device.

[0007] According to one embodiment, the cryptographic operation includes encrypting the one or more first data items by using the encryption key.

[0008] According to one embodiment, applying the cryptographic operation includes calculating one or more first signature values associated with the one or more first data items by using the encryption key, and the one or more protected data include the one or more first signature values.

[0009] According to one embodiment, the encryption key corresponds to the secret key, and the secret key is derived by the cryptographic circuit by applying a key derivation function based on the identification value, the identification value being generated from a hash of the public key.

[0010] According to one embodiment, the software module includes executable code and a second signature value associated with the executable code, and the method further includes: authenticating the software module based on verification of the second signature value via a public key before generating one or more protected data items.

[0011] According to one embodiment, the above method further includes storing the executable code in a second part of the memory different from the first part.

[0012] According to one embodiment, steps a) to d) are implemented via a software platform of the electronic device.

[0013] According to one embodiment, the above method further includes, before implementing step b): generating a verification value by applying a hash function to the public key; comparing the verification value with an identification value; and removing the software module when the verification value and the identification value do not match.

[0014] According to one embodiment, the above method further includes generating an identification value by applying a hash function to the public key by a cryptographic circuit.

[0015] According to one embodiment, the secret key of the electronic device is a hardware-unique key or a key derived from a hardware-unique key.

[0016] According to one embodiment, the method further includes modifying the public key during an update of the first application.

[0017] According to one embodiment, the above method further includes executing the first application by a processor of the device, wherein the execution includes retrieving one or more first data items associated with the first application by performing the following operations: extracting the public key, and performing a new generation of an encryption key based on the secret key of the electronic device and one of the public key and the identification value derived from the public key; applying a new cryptographic operation to one or more protected data items stored in the first part of the memory; and retrieving one or more first data items.

[0018] According to one embodiment, retrieving one or more first data items is performed via a software platform of the electronic device.

[0019] One embodiment provides an electronic device configured to: receive a software module of a first application, the software module including a public key, the electronic device including: a cryptographic circuit configured to: generate an encryption key based on one of the public key and an identification value derived from the public key; generate one or more protected data items by applying a cryptographic operation to one or more first data items associated with the first application based on the encryption key; and a memory configured to store one or more protected data items.

[0020] According to one embodiment, the above electronic device further includes a software platform configured to control access to the memory. Description of the Drawings

[0021] The foregoing and other features and advantages will be described in detail with reference to the accompanying drawings in the remainder of the disclosure of the specific embodiments, which are given by way of illustration and not limitation, wherein:

[0022] Figure 1 is a block diagram illustrating an electronic device;

[0023] Figure 2 very schematically shows an embodiment of a software system in the form of a block;

[0024] Figure 3 illustrates the structure of a software application module; and

[0025] Figure 4 is a flowchart illustrating the steps of a verification method. Detailed Description of the Embodiments

[0026] In the various drawings, the same features are denoted by the same reference numerals. In particular, the structural and / or functional features common to the various embodiments may have the same reference numerals and may have exactly the same structural attributes, dimensional attributes, and material attributes.

[0027] For clarity, only the steps and elements that contribute to an understanding of the described embodiments are shown and described in detail.

[0028] Unless otherwise stated, when referring to two elements connected together, this means a direct connection without any intermediate element other than a conductor, and when referring to two elements coupled together, this means that the two elements may be connected or they may be coupled via one or more other elements.

[0029] In the following description, when referring to absolute position determiners (such as "front", "rear", "top", "bottom", "left", "right", etc.) or relative position determiners (such as "top", "bottom", "upper", "lower", etc.) or orientation determiners (such as "horizontal", "vertical", etc.), unless otherwise stated, the orientation of the drawings is indicated.

[0030] Unless otherwise stated, the expressions "about", "approximate", "substantially", and "roughly" mean plus or minus 10%, preferably plus or minus 5%.

[0031] Figure 1 is a block diagram very schematically showing an example architecture of an electronic device 100 configured to implement the software system described in conjunction with Figure 2 described, and / or to store and execute such as in conjunction with Figure 3The described software module, and / or the implementation in combination with Figure 4 the described method.

[0032] The electronic device 100 includes a processor 101 (“CPU”) configured to process data items stored in the memory and / or provided by other circuits of the device 100. The processor 101 may also be configured to implement the software architecture of the type in combination with Figure 2 the described software architecture type.

[0033] The electronic device 100 includes, for example, one or more memories 102 (“MEM”), which include, for example, non-volatile memory, volatile memory, and / or read-only memory. Each memory 102 may be configured to store different types of data and may include access rules. In particular, one or more memories 102 may include portions that are accessible only by one or more circuits of the electronic device and / or portions that are accessible only by one or more software programs implemented by the device 100.

[0034] The electronic device 100 also includes, for example, a security element 103 (“SE”) configured to process sensitive and / or secret data. The security element 103 may include its own processor(s), its own one or more memories, etc. The security element 103 may also be configured to implement the software architecture of the type in combination with Figure 2 the described type.

[0035] What is referred to as sensitive data and secret data in the remainder of this disclosure refers to data having content that is not intended to be made public. For example, this data is unknown outside of the electronic device 100 and / or access to this data is restricted to certain specific persons and / or circuits.

[0036] The electronic device 100 may also include one or more interface (or input / output) circuits 104 (“input / output”) configured to send data to the outside of the device 100 and / or receive data from the outside of the device 100. The interface circuit 104 may also be configured to communicate with a data display system (e.g., a screen).

[0037] The electronic device 100 may also include one or more circuits 105 (“FCT1”) configured to perform functions. As an example, the circuit 105 may include a measurement circuit, a data conversion circuit, a circuit for controlling an electronic or electromechanical device, etc. In addition to or instead of the security element 103, the electronic device 100 may also include one or more cryptographic circuits 106 configured to perform cryptographic operations, such as, for example, asymmetric and / or symmetric encryption / decryption operations, calculation of signature values for one or more data items, hash operations (such as SHA256), etc.

[0038] The electronic device 100 includes, for example, one or more data buses 107 that are configured to transfer data between the processor 101 and one or more memories 102, and in some cases also between one or more other components 103, 104, 105, and 106 of the electronic device 100.

[0039] Figure 2 An embodiment of a software architecture or software system 200 is shown very schematically in the form of a block.

[0040] The architecture or system 200 includes, for example: a shared and secure software platform 201 (“platform”); one or more security software applications 202 (“services”); one or more memories 203 (“MEM”); and at least one secure operating system 204 (“secure OS”).

[0041] The shared software platform 201 is software for implementing the application(s) 202. More specifically, the platform 201 is configured to communicate with the application, that is, to receive and send data to the application. According to one embodiment, the platform 201 is configured to manage the storage of data used by the software application(s) 202. According to one example, the software platform 201 is designed by an original equipment manufacturer (OEM) or a manufacturer different from the OEM of the electronic device (such as a processor or a security element) that implements it.

[0042] What is referred to here as the original equipment manufacturer or simply the manufacturer means the initial designer of elements such as circuits, devices, or software.

[0043] The security software application(s) 202 (“services”) are security software configured to implement one or more functions. Each application 202 may also be referred to as a software service, or simply a service. According to one embodiment, the application 202 is implemented based on its execution code and may generate and / or use data associated with the application (hereinafter also referred to as digital assets (“assets”)).

[0044] What is referred to here as the execution code means a collection of data and instructions that form the program(s) implemented by the application. When the application is updated, its execution code is modified.

[0045] In addition, what is referred to here as digital assets are one or more data items generated by an application during its operation and / or used by the application for its operation during the application. These data items can be collected, generated, and / or processed by the said application. Digital assets can be data items temporarily stored by the application or data items more persistently stored by the application. When the application is updated, the digital assets are not modified. In fact, it is desirable for the updated version of the application to be able to access and be able to use the data associated with the (multiple) previous versions. Digital assets are generally considered sensitive and / or secret data items.

[0046] According to one embodiment, each software application 202 can be designed by a manufacturer different from the designer of the software platform 201 and the manufacturer of the electronic device (such as the processor or security element that implements them). Similarly, different applications can have different manufacturers.

[0047] Each application 202 is configured to communicate with the platform 201 and, more generally, is configured to be implemented or executed by the platform 201.

[0048] The memory 203 represents access to the various memories of the device implementing the system 200. Among these memories, for example, there is at least a portion of the memory whose access is strictly reserved for the platform 201 and at least a portion of the memory for storing the digital assets of the application 202. For example, the platform 201 can be configured to manage memory access. For example, the application 202 cannot directly access the memory 203.

[0049] The secure operating system 204 is, for example, the operating system of the electronic device (such as a processor or security element) implementing the system 200. The operating system 204 is configured, for example, to communicate with the platform 201, but according to an example not shown, also with the memory 203 and the application 202.

[0050] The embodiments described below relate to the security of software applications (such as application 202), and more specifically, to the security of the digital assets of such software applications. More specifically, it aims to prevent a software application from accessing digital assets not intended for it, such as the digital assets of another software application or the digital assets of an older version of the same software application from another application provider (such as another original equipment manufacturer, another circuit manufacturer, and / or a third party). In particular, the embodiments described below are able to overcome application replacement attacks, in which a pirated application replaces the application by pretending to be the installed application during an update, with the aim of gaining access to the digital assets of the application.

[0051] Figure 3 The structure of a software module 300 of a software application according to an embodiment of the present disclosure is illustrated.

[0052] The software module 300 is a module of a software application received, for example, by the device 100 via the interface circuit 104. As an example, the software module 300 is a module of an application not yet installed in the device 100. In another example, the software module 300 is a module that enables the update of a pre-existing application in the device 100 (e.g., update of the application 202).

[0053] The software module 300 includes a header 302 ("header"), and the header 302 includes information related to, for example, the image format of the application, its installation location in the memory for execution, the size of the execution code, etc.

[0054] The software module 300 further includes an execution code 304 ("code"). As an example, the execution code is encrypted, for example, encrypted via a symmetric key known only to the sender of the software module 300. As an example, the symmetric key is encrypted by means of a pair of asymmetric keys. In particular, the public key of the pair of asymmetric keys is used to encrypt the symmetric key. The private key is stored, for example, in the device 100, and the private key is used to decrypt the symmetric key. As an example, the symmetric key is included in the image format of the application. Thus, the private key is known only to the device 100, and the private key can also be used to encrypt other software applications (e.g., software applications from different institutions). To make the private key unknown to the original device manufacturer or a third party, the private key is stored, for example, in the device 100 when manufacturing the device 100. As an example, the private key is prepared, for example, by the manufacturer or institution of the device 100 (such as the manufacturer of the components of the device 100) in the device 100, independent of the software application.

[0055] The software module 300 further includes information 305, and the information 305 includes, for example, an indication 306 of the version of the application ("version"). The information 305 further includes, for example, an indication 308 of the software dependencies of the application ("dependencies"). As an example, the indication 308 indicates to the device 100 the software and / or hardware components for the correct operation of the application. As an example, the information 305 includes an identification value 310 ("signing party ID"). In one example, the device 100 is a connected object, and the identification value is used, for example, to play the role of a token for implementing an initial proof token service, enabling the delivery of information related to the state of the software, for example, to a remote server.

[0056] According to one embodiment, when installing software module 300, an encryption key for encrypting and / or decrypting an asset is generated (e.g., by cryptographic circuit 106) based on an identifier value and a secret key specific to device 100. As an example, the secret key is a hardware unique key (HUK) or a key derived from the hardware unique key (“derived hardware unique key” - DHUK). As an example, the encryption key is obtained by deriving the secret key according to identification value 310. According to one embodiment, one or more digital assets associated with an application are encrypted using the generated encryption key. According to another embodiment, one or more signature values associated with one or more assets are calculated using the received encryption key. One or more assets (e.g., one or more assets encrypted or signed via the encryption key) are stored in the non-volatile memory of the device. As an example, device 100 has received one or more assets during the execution of the software. As an example, the software is configured to drive a keyboard and / or a screen and request a user to input a password. In another example, the software is configured to control the connection to a server, and as a result of the execution of an authentication process based on identification value 310, the server will deliver an asset to the software. Thus, identification value 310 is included in the software image and is also used, for example, in a function for calculating the encryption key.

[0057] The software module 300 also includes data 311 associated with, for example, a third party, where the third party is an entity different from the original equipment manufacturer. In some cases, the third party is, for example, the manufacturer of the device 100. In some other cases, the third party is an entity completely different from the manufacturer of the device 100. Generally, the third party represents an entity that has, for example, designed the software module 300 (especially the code 304). The data 311 includes, for example, one or more signature values 312 ("signatures"). As an example, the (multiple) signatures 312 include a signature of the code 304 (for example, generated by the third party based on a private key unknown to the device 100). The data 311 also includes a public key 314 ("public key"). The public key 314 is a key that enables the device 100 to verify the signature value 312, for example. As an example, when the software module is an update module, the public key of the updated software module is different from the public key of the previous version of the applied software module. In fact, if the update module is signed, for example, by a party different from the supplier of the newer version, the symmetric key and the identification value 310 are different from those of the newer version. Therefore, the calculated encryption key will also be different from the encryption key calculated for the newer version. Then, the assets associated with the newer version stored in the non-volatile memory will no longer be able to be decrypted by means of the encryption key and, accordingly, will no longer be able to be used. As an example, the verification of the signature value enables the device 100 to ensure the credibility of the software module 300 and to authenticate the entity that has constructed the software module 300.

[0058] According to one embodiment, the identification value 310 corresponds to the public key to which a cryptographic operation is applied. As an example, the identification value 310 is a hash of the public key 314. The identification value 310 is obtained, for example, by applying a hashing operation (such as SHA256) to the public key 314.

[0059] The software module 300 also includes information 315 associated with the original equipment manufacturer. As an example, the information 315 includes another signature value 316 ("OEM signature"). As an example, this other signature is associated with the original equipment manufacturer. As an example, this other signature enables the original equipment manufacturer to control the installation of the application module originating from the third party. As an example, the application module is installed only if the value of this other signature is correct. As an example, when the application module originates from the original equipment manufacturer, the identification value is omitted or aligned with the public key of the original equipment manufacturer. The identification value 310 is, for example, a hash of the public key of the original equipment manufacturer. In this example, the public key of the original equipment manufacturer is prepared during the manufacture of the device 100.

[0060] Figure 4 is a flowchart illustrating the steps of a verification method according to an embodiment of the present disclosure.

[0061] As an example, via the electronic device 100 and, for example, by Figure 2 the software platform 201 to implement all or part of the steps described in connection with Figure 4 In other words, for example, all or part of the actions performed by the electronic device 100 (such as cryptographic operations performed by the (one or more) circuits 116, writing to or reading from the memory 203, etc.) are controlled by the software platform 201.

[0062] In step 400 (“module reception”), the device 100 receives a software module of an application similar to the software module 300 described in connection with Figure 3 As an example, as a result of wireless communication (such as communication of types such as Wifi, Bluetooth, 4G, or 5G, etc.), the software module of the application is received. In another example, the software module is received via wired communication. As an example, the reception of the software module of the application is initiated by the manufacturer of the device 100. In another example, the reception of the software module of the application is initiated by the user of the device 100. In one example, the received software module of the application is an update to an application already installed in the device 100. In another example, the received software module of the application can install a new application in the device 100.

[0063] In step 401 (“authenticity verification”), the device 100 (specifically, via the processor 101 and the (one or more) cryptographic circuits 106) verifies the authenticity and / or integrity of the software module. As an example, the verification is performed by verifying the signatures 312 and / or 316 and, for example, based on the public key 314. Step 401 is performed, for example, during the startup phase of the device 100.

[0064] According to one embodiment, for example, when the software module is from a third party and includes the identification value 310, step 401 further includes generating a verification value by, for example, applying a cryptographic operation (such as a hash operation (such as SHA256)) to the public key 314 via the (one or more) circuits 106. In another example, when the application module is from the original equipment manufacturer, a cryptographic operation is performed on the public key associated with the original equipment manufacturer that was prepared in the device 100 during the manufacture of the device 100. Step 401 then includes verifying the verification value using the identification value 310. As an example, in the case where the two values do not match, the software module of the application is not installed and, for example, removed from the device 100.

[0065] In the alternative case where the software module does not include the identification value 310, step 402 (“signer ID”) includes generating the identification value 310 by the (one or more) circuits 106. For example, the identification value is directly generated from the public key 314 or the public key associated with the original equipment manufacturer.

[0066] In step 403 ("key generation"), an encryption key is generated based on the identification value 310 included in the software module or generated in step 402 and the secret key of the device 100. As an example, the encryption key is generated by, for example, applying a cryptographic operation (e.g., a symmetric encryption operation such as AES, DES, etc.) to the identification value 310 and using the secret key. As an example, the secret key is a hardware-unique key or a key derived from a hardware-unique key. In other words, the secret key is unique to the device 100, and thus the generated encryption key is also unique and specific to the device 100. For the same software module of an application, the generated encryption key varies depending on the device 100. Similarly, for the same device 100, the encryption keys generated for two software modules sourced from different suppliers (e.g., sourced from a third party and an original equipment manufacturer) are different.

[0067] In step 404 ("secret generation"), the generated encryption key is used to generate one or more protected data or secrets associated with the application.

[0068] In one example, the generated encryption key is used to encrypt one or more digital assets of the application, for example, according to a symmetric cryptographic algorithm. In another example, the generated encryption key is used to calculate one or more signature values of one or more digital assets. Thus, the encryption key depends on the software module and the device receiving it, and the secrets generated in step 404 are also specific to the application and the device 100.

[0069] In step 405, the protected data or secrets generated in step 404 are stored in the first part of the memory 203. As an example, the execution code of the software module is stored, for example, in a second part of the memory different from the first part in step 405, and the protected data associated therewith is stored in the first part. As an example, the execution code of the module is encrypted, and the software platform 201 controls its decryption, for example, through a cryptographic circuit, and then stores the decrypted code.

[0070] As an example, in an optional step 406 ("execution"), the execution code installed in the second part of the memory is executed. As an example, during execution, the platform 201 controls the retrieval of digital assets stored in the first part of the memory 203. For this purpose, the platform 201 controls, for example, the retrieval of the identification value 310 or the symmetric key 314 from the execution code. As an example, as a result of the authentication of the code, the area containing the identification value 310 and / or the public key 314 is prohibited. The encryption key is regenerated so that, for example, the decryption of the protected data can be performed to obtain the digital assets. In another example, the regenerated encryption key is used to verify the (multiple) signature values associated with the assets.

[0071] One advantage of the described embodiments is that a first application cannot know the value of a digital asset associated with another application different from the first application.

[0072] Another advantage of the described method is that the encryption key used to encrypt or sign the asset is not stored in the memory. In fact, the encryption key is computed, for example, at each startup phase of the device 100.

[0073] Various embodiments and variations have been described. Those skilled in the art will understand that certain features of these various embodiments and variations can be combined, and other variations will occur to those skilled in the art. In particular, the generation of the encryption key based on the public key can vary.

[0074] Finally, based on the functional indications given above, the actual implementation of the described embodiments and variations is within the capabilities of those skilled in the art. In particular, with respect to the implementation of the software platform.

Claims

1. A method, comprising: a) receiving, by an electronic device, a software module of a first application, the software module including a public key associated with the first application; b) generating, by a cryptographic circuit of the electronic device, an encryption key based on both a secret key of the electronic device and one of the public key or an identification value derived from the public key; c) generating, by the cryptographic circuit, one or more protected data items by applying a cryptographic operation to one or more first data items associated with the first application based on the encryption key; and d) storing the one or more protected data items in a first portion of a memory of the electronic device.

2. The method according to claim 1, wherein the cryptographic operation: includes encrypting the one or more first data items by using the encryption key.

3. The method according to claim 1, wherein the cryptographic operation comprises: Calculating, by using the encryption key, one or more first signature values associated with the one or more first data items, the one or more protected data items including the one or more first signature values.

4. The method according to claim 1, wherein the encryption key corresponds to a secret key, the secret key being derived by the cryptographic circuit by applying a key derivation function based on the identification value, the identification value being generated by hashing the public key.

5. The method according to claim 1, wherein the software module includes executable code and a second signature value associated with the executable code, and the method further includes: Before generating the one or more protected data items, authenticating the software module based on verification of the second signature value via the public key.

6. The method according to claim 5 further comprises: Storing the executable code in a second portion of the memory different from the first portion.

7. The method according to claim 1, wherein steps a) to d) are implemented via a software platform of the electronic device.

8. The method according to claim 1 further comprises: Before implementing step b): Generating a verification value by applying a hash function to the public key; Comparing the verification value with the identification value; and When the verification value and the identification value do not match, removing the software module.

9. The method according to claim 1, further comprising: Generating, by the cryptographic circuit, the identification value by applying a hash function to the public key.

10. The method according to claim 1, wherein the secret key of the electronic device is one of the following: a hardware-unique key, or a key derived from a hardware-unique key.

11. The method according to claim 1, further comprising modifying the public key during an update of the first application.

12. The method according to claim 1 further comprises: Executing, by a processor of the device, the first application by retrieving the one or more first data items associated with the first application, retrieving the one or more first data items by: Extracting the public key and performing a new generation of the encryption key based on both a secret key of the electronic device and one of the public key or an identification value derived from the public key; Applying a new cryptographic operation to the one or more protected data items stored in the first portion of the memory; and Retrieving the one or more first data items.

13. The method according to claim 12, wherein retrieving the one or more first data items is performed via a software platform of the electronic device.

14. An electronic device configured to receive a software module from a first application, the software module including a public key, the electronic device comprising: A cryptographic circuit configured to: Generate an encryption key based on one of the public key or an identification value derived from the public key; Generate one or more protected data items by applying a cryptographic operation to one or more first data items associated with the first application based on the encryption key; And A memory configured to store the one or more protected data items.

15. The electronic device according to claim 14, further comprising a software platform configured to control access to the memory.

16. The electronic device according to claim 14, wherein the password operation includes: By using the encryption key to encrypt the one or more first data items.

17. The electronic device according to claim 14, wherein the password operation includes: By using the encryption key to calculate one or more first signature values associated with the one or more first data items, the one or more protected data items including the one or more first signature values.

18. The electronic device according to claim 14, wherein the secret key of the electronic device is one of the following: a hardware-unique key or a key derived from a hardware-unique key.

Images