Secure element for securely processing digital information

Abstract

The invention relates to a secure element (100) having a secure processor (110) for securely processing digital information stored in a memory (200) external to the secure element, and a loading and preprocessing system configured to load the digital information from the external memory (200) into the secure element (100) and to preprocess the digital information by performing a cryptographic algorithm before the digital information is processed by the secure processor (110). The system reads a version number of the loaded digital information from an internal memory (122) of the secure element (100) and uses the version number when performing the cryptographic algorithm.

Description

Technical Field

[0001] This disclosure relates to the field of computer security, and more specifically to the secure handling of digital information, such as code (applications) and / or data. Background Technology

[0002] Generally speaking, a processing device capable of securely handling digital information (also known as a secure element, such as a smart card or chip) includes hardware resources such as one or more processors (e.g., a host processor and a security processor) and one or more memories (volatile memory, cache memory, and non-volatile memory). The processing device typically operates under the control of an operating system and executes program instructions using one or more software components or applications. When an application is executed, the digital information (code and data) required by the application and the data generated by the application can be stored in non-volatile memory, and the digital information can be loaded into volatile memory or cache memory when it needs to be executed or processed.

[0003] Security elements can be embedded in a SoC (System-on-a-Chip) that has several processing modules, several memories, and several functional accessories. The SoC can be integrated into a larger module, such as an IoT device (Internet of Things device).

[0004] In constrained environments such as IoT systems, secure elements may only have small non-volatile memory, such as OTP (One-Time Programmable) memory, used to store a limited amount of information, typically counters and / or keys. Secure elements are not used to store digital information (e.g., code and / or data). To keep the cost of secure elements low, digital information is stored in external non-volatile memory located outside the secure element (e.g., flash memory stored in the SoC or in a module outside the SoC). This external memory has a much larger storage capacity than the internal storage capacity of the secure element, such as several megabytes. The digital information stored in external memory is protected with a high level of security equivalent to the security level of the secure processor. More precisely, it should be protected in terms of privacy, integrity, authenticity, and freshness. Regarding freshness, this means that digital information should be protected against replay attacks (also known as rewind attacks), a form of cyberattack where valid data transmission is maliciously or deceptively repeated or delayed.

[0005] It is necessary to protect the secure element from malicious attacks, especially replay attacks. A replay attack (also known as a rewind attack) is a malicious attack in which a hacker eavesdrops on valid data transmission, intercepts valid data transmission, and then deceptively delays or repeats valid data transmission to mislead the receiver (in this case, the secure element) into doing what the hacker wants.

[0006] The secure element has a loader that securely imports external digital information into internal memory such as RAM (Random Access Memory). When importing a digital information segment, it should be verified that it has not been replaced by a previous version of the digital information segment that is no longer valid.

[0007] EP 2 860 660 discloses a data processing system including a System-on-a-Chip (SoC) having a host processor (HCPU) and associated host memory, a secure processor (SCPU) and associated secure memory, a secure cache memory storing multiple cache lines, and a cache controller controlling the loading of cache lines from the host processor to the secure processor. The cache memory stores an integrity table containing a fingerprint of each cache line computed using a hash function. When a cache line is loaded into the secure processor, its integrity is verified by successfully comparing the fingerprint of the cache line computed by the secure processor with the corresponding fingerprint extracted from the integrity table.

[0008] Such solutions require loading the integrity table into the secure element's internal memory (e.g., RAM). For example, if 1MB of digital information is stored in external memory and that information is segmented into 1KB fragments, each with a 32B fingerprint or tag, the integrity table to be stored in the secure element's internal RAM would require 32KB of storage capacity. For processing devices with limited storage capacity, such as IoT devices, this solution may be unsuitable because it requires too much storage within the secure element.

[0009] This disclosure aims to improve this situation. Summary of the Invention

[0010] This disclosure relates to a secure element for securely processing digital information, wherein the digital information is segmented and stored in multiple M segments in a memory external to the secure element, the secure element comprising: - A security processor for securely processing multiple M segments of digital information; - A system configured to load digital information segments from external memory into a secure element and preprocess the digital information segments by executing a cryptographic algorithm before the digital information segments are processed by a secure processor; The system is configured to determine the identification information of a loaded digital information segment, the determination of which includes obtaining the version number of the digital information segment and executing a cryptographic algorithm using the identification information. The system is characterized in that it is configured to load a version table containing the corresponding version numbers of multiple M segments of digital information from external memory into the internal memory of the security element, and to read the version number of each digital information segment loaded into the version table stored in the internal memory.

[0011] Therefore, the cryptographic algorithm uses the version number of digital information (or a fragment of digital information stored in external memory) as input. The version number of the digital information is used in cryptographic form to preprocess the digital information (or the fragment of digital information). It is associated with the digital information (or the fragment of digital information) in external memory and loaded into the secure element. The version number may have an initial value (e.g., zero) and is incremented each time the digital information (or the fragment of digital information) is modified, for example, during processing by the secure element. The digital information (or the fragment of digital information) is cryptographically bound to its version number. The secure element stores this version number internally, which requires low storage capacity. Therefore, high-capacity storage is not required to protect the secure element from malicious replay attacks. Therefore, this disclosure is applicable to low-end devices requiring a good level of security.

[0012] Advantageously, the system is configured to determine identification information for a digital information segment, the determination of which further includes obtaining a segment identifier for the digital information segment and executing a cryptographic algorithm using the identification information, wherein the segment identifier is an index assigned to the corresponding digital information segment in external memory or an identifier present in the header of the corresponding digital information segment.

[0013] In addition to its version number, it is also possible to preprocess digital information by using identifiers of digital information (or fragments of digital information) in cryptographic form.

[0014] An identifier is a short piece of information, such as an index to a digital information segment in external memory. Typically, digital information is divided into several segments, which are indexed and stored in external memory. These segments may be stacked or, more generally, arranged at a given location in external memory. The index assigned to these segments may depend on their location in external memory.

[0015] Advantageously, the secure element stores at least one unique cryptographic key, which is uniquely generated for the secure element and used by the system when executing cryptographic algorithms.

[0016] The use of version numbers prevents digital information (or fragments of digital information) from being replaced by an earlier version of the digital information. The use of identifiers for digital information (or fragments of digital information) prevents the digital information from being replaced by another valid digital information loaded into a secure element. The use of unique keys prevents the digital information from being replaced by digital information from another secure element or device. The combined use of version numbers, identifiers, and unique keys allows for solutions with TAG solutions equivalent to those in the prior art, implicitly protected against many different attacks, but without requiring high storage capacity.

[0017] The system may include a key derivation function to generate at least one cryptographic key that will be used by a cryptographic algorithm by using at least one unique cryptographic key and identification information of digital information as input.

[0018] The cryptographic algorithm may include an authentication algorithm for authenticating the loaded digital information segment. Alternatively or additionally, the cryptographic algorithm may include a decryption algorithm for decrypting the loaded digital information. Therefore, the version number and / or identifier of the digital information (or digital information segment) can be used not only for authentication but also for decryption, which enhances security.

[0019] For example, the system is configured to generate an initialization vector that will be used by the decryption algorithm by using the identification information of the digital information segment as input.

[0020] Digital information stored in external memory can be protected by a certified encryption mechanism, such as an "Encrypt-then-MAC" method. In this case, authentication and subsequent decryption of the digital information are required before it can be securely processed within the secure element. This configuration provides the highest level of security by using a version number and an identifier for the digital information as input for authentication. In practice, if authentication fails, the digital information will not be decrypted.

[0021] Advantageously, the system is further configured to verify the freshness information of the version table by comparing the freshness information of the version table with a freshness counter stored in the internal non-volatile memory of the secure element.

[0022] The freshness or consistency of all digital information fragments is certified by a version table. Using version numbers instead of their TAGs (fingerprints) saves internal storage resources in the secure element. For example, if 1MB of digital information is stored in external storage, and that 1MB of digital information is stored in 1KB fragments or sections, each with a TAG (such as a 32B MAC), the size of the integrity table containing all the TAGs of the digital information fragments would be 32KB. In this disclosure, if we assume that the version number is a few bytes in size, such as 3B, then the size of the version table that needs to be stored in the secure element is only 3KB. Therefore, this disclosure can spare 29KB of internal storage capacity.

[0023] The verification of freshness information in the version table ensures security by establishing a trust chain of freshness (anti-replay).

[0024] The internal non-volatile memory can be an OTP (One-Time Programmable) memory.

[0025] The system can be configured to load the version table during the startup process of the security element.

[0026] Advantageously, the system is configured to authenticate and decrypt the loaded version table.

[0027] The system can be configured to read freshness information from the header of the version table.

[0028] Advantageously, the security element includes an update module configured to control the following operations in the event that a digital segment (or digital information fragment) is modified while being processed by the security processor: writing the modified digital segment and the updated version table to external memory and incrementing a freshness counter in internal non-volatile memory.

[0029] The second aspect of this disclosure relates to a system comprising a security element as previously defined and an external memory for storing digital information.

[0030] A third aspect of this disclosure relates to a method for securely processing digital information by a secure element, the digital information being segmented and stored in multiple M segments in a memory external to the secure element, the method comprising the following steps performed by the secure element: - Load digital information segments from external memory into the secure element; - The identification information of the loaded digital information segment is determined by obtaining the version number of the digital information segment; - The digital information segment is preprocessed by executing a cryptographic algorithm using the identification information before it is processed by the security processor of the security element; - Digital information segments are securely processed by a secure processor; The method is characterized by further comprising: The steps include loading a version table containing the corresponding version numbers of multiple M segments of digital information from external memory into the internal memory of the security element, and reading the version number of each digital information segment from the version table loaded into the internal memory.

[0031] The method further includes the step of verifying the freshness information of the version table by comparing the freshness information of the version table with a freshness counter stored in the internal non-volatile memory of the secure element. Attached Figure Description

[0032] Other features, objects, and advantages of this disclosure will become clearer from the detailed description of the non-limiting embodiments with reference to the accompanying drawings.

[0033] Figure 1 A security element embedded in a SoC (System-on-Chip) according to a first embodiment is shown.

[0034] Figure 2 The safety element and external memory operating during the startup process according to the first embodiment are shown in a simplified manner.

[0035] Figure 3 The secure element and external memory operating during the process of loading and preprocessing (or reading) digital information from an external memory, according to the first embodiment, are shown in a simplified manner.

[0036] Figure 4 The security element and external memory operating during the process of writing the modified digital information fragment and the updated version table to external memory according to the first embodiment are illustrated in a simplified manner.

[0037] Figure 5 A flowchart is shown of a method for securely processing digital information, which is stored in an external memory and performed by a secure element according to a first embodiment.

[0038] Figure 6 A flowchart is shown of an update process performed according to a first embodiment when a digital information fragment has been modified by a security element.

[0039] Figure 7 The safety element is schematically represented according to the first embodiment. Detailed Implementation

[0040] Figure 1A system according to a first embodiment is shown, comprising a secure element 100 and external memory 200 (i.e., memory external to the secure element 100). The secure element 100 is, for example, a smart card or a chip. It may be embedded in a SoC (System-on-a-Chip) 300 having several processing units, several memories, and several functional accessories (not shown). The SoC 300 may be integrated into a larger module 400. The external memory 200 is external to the secure element 100. It may be built on a different silicon substrate than the secure processor of the secure element 100. For example, the external memory may be arranged in module 400, external to the SoC 300. However, the external memory 200 may be located within the SoC 300. For example, the larger module 400 may be an IoT device (typically having a unique identifier and the ability to transmit data over a network), a telecommunications device, a positioning system, a vehicle (such as a car or airplane), etc. Examples of IoT devices include smart meters, smart cameras, sensors, trackers, tags, detectors, monitors, wearable items and clothing, smart home devices, medical and healthcare devices, life science devices, set-top boxes, and edge devices in telecommunications networks such as 5G networks.

[0041] The following are different exemplary (non-limiting) use cases of safety element 100.

[0042] In the first use case, the secure element 100 can be integrated into the modem of a telecommunications system or device. In this case, the secure element 100 can handle network authentication and download security applications.

[0043] In the second use case, the safety element 100 can be integrated into the driving recorder and securely process location data.

[0044] In the third use case, the security element 100 can be integrated into a vehicle (e.g., a car or an airplane) to protect and manage secure data transmission.

[0045] External memory 200 stores digital information. The term "digital information" refers to data that is easily loaded into secure element 100, such as executable code or information generated by or used by executable code, or any other data that will be used or processed by secure element 100.

[0046] The security element 100 is designed to load, preprocess (or read) and securely process digital information stored in the external memory 200, which will be explained later in the specification.

[0047] External memory 200 can be non-volatile memory.

[0048] In this embodiment, memory segments are used in the external memory 200. This means that digital information is segmented and stored in segments (also called “blocks”). A digital information segment is a fragment of digital information generated through segmentation. Segmentation is used for storing, transmitting, and preprocessing digital information.

[0049] For example, external memory 200 stores M digital information segments called "Si", among which The M segments Si may include M1 code segments and M2 data segments, where and Depending on the specific implementation, the digital information segments may have the same size or may have correspondingly different sizes. In some implementations, the security element 100 has a cache implementation. In this case, the security element 100 may have a cache controller (typically a cache hardware component) configured to load and store cache lines (corresponding to digital information segments) of a predetermined size. In other implementations, the digital information segments may be fragments of digital information requested by the security processor when executing software components or applications. In this case, the segments may have different corresponding sizes.

[0050] The digital information segment Si is protected by an authentication encryption algorithm to ensure security during storage to external memory 200 and during transfer from external memory 200 to secure element 100. In the first embodiment, the authentication encryption for protecting the digital information is based on the well-known "encryption-then-MAC" (EtM) method. The EtM method is considered a very reliable method for authentication encryption. For each digital information segment Si, external memory 200 stores element [Si] | MAC [Si] It contains an authentication element MAC that is encrypted with an encryption key (described later) and computed with an authentication key (also described later) to form an encrypted segment [Si]. [Si] Cascaded segment Si. The MAC of the authentication element can be calculated using the MAC function. [Si] .

[0051] In this disclosure, brackets “[]” indicate the encryption form of an element, and the symbol “|” indicates the cascading of two elements.

[0052] Version number Vi is assigned to each digital information segment Si, and the version number increments when the digital information segment Si is modified by the security element 100. The size of the version number Vi of a digital information segment Si can be very small, generally a few bytes, such as 3 bytes. Initially, when the digital information is stored in the external memory 200, it has... The version number Vi of all segments Si of the digital information can be set to an initial value, such as zero (but it can be one or any other value). Then, each time a specific segment (here called "Sj") of the M segments Si is modified, its version number Vj is incremented, for example, by 1 (i.e., Vj = Vj + 1).

[0053] Furthermore, in the first embodiment, each digital information segment has an ID. Si The associated segment identifier. This segment identifier ID Si It is a short message segment that identifies a segment. Segment Identifier ID Si These can be indexes of segment Si in external memory 200. Typically, indexes are assigned to digital information segments Si in external memory 200, for example, depending on the corresponding location of the segment Si stored in external memory 200. These indexes can be used by the security element 100 as segment identifier IDs. Si They can also be used to index the version number Vi of segment Si in the version table. In the case of a cache implementation in the secure element 100, the cache block address is given by the address used to fetch code or load data and can be used as a segment (or block) identifier ID. Si These cache block addresses correspond to the indices of blocks (segments) in external memory 200. The same cache block addresses can be used to index version numbers in the version table.

[0054] In this embodiment, each digital information segment Si stored in the external memory 200 contains a version number Vi and an identifier ID. Si Used as input in authentication encryption algorithms. For example, authentication algorithms such as the MAC algorithm used to authenticate segment Si use the version number Vi and identifier ID of segment Si. Si The Key Derivation Function (KDF) that takes the input as input derives the authentication key k1_Si from the master key k1 (or source key k1), with the following expression: k1_Si = KDF(k1,Vi, ID Si ) In addition, to enhance security, the version number Vi and identifier ID of segment Si are... Si It can also be used to encrypt digital information segments Si. For example, the encryption algorithm uses the version number Vi and identifier ID of the segment Si. Si The key derivation function (KDF) takes as input the encryption key k2_Si derived from the master key k2 (or source key k2): k2_Si = KDF(k2,Vi, ID Si ) Keys k1 and k2 can be secret keys. Advantageously, these keys k1 and k2 are generated uniquely for the secure element 100. They can be generated by the secure element 100 itself. Keys k1 and k2 are different in the first embodiment. However, they can be the same key in other embodiments.

[0055] All encrypted and authenticated segments [Si] | MAC [Si] (in They are stored in external memory 200. They can be stacked (and ordered) in the storage area of ​​external memory 200.

[0056] External storage 200 also stores a version table, in Figures 2 to 4 This is referred to as "CtrlObj". The version table CtrlObj contains the corresponding current (valid) version number Vi of all digital information segments Si stored in external memory 200. The version number Vi contained in the version table CtrlObj can be arranged in the same order as the segments Si arranged in external memory 200. More generally, the version number Vi in the version table CtrlObj can be indexed in the same way as the corresponding segment Si is indexed in external memory 200. This allows segments to be identified by their sequence number or index. Alternatively, numeric information segments may have segment identifiers within the segment. These segment identifiers, present in the segment header, can be associated with the version number Vi in the version table CtrlObj.

[0057] In addition, freshness information is assigned to the version table CtrlObj. Typically, this freshness information is the version number of the version table, referred to as "CtrlObj_Version". This freshness information has an initial value, such as zero, which is assigned to the version table CtrlObj when the numeric information is initially stored in a segment in external memory 200. It can be incremented each time the contents of the version table CtrlObj are modified, which will be explained later. The freshness information CtrlObj_Version of the version table CtrlObj is stored in external memory 200, for example, in the header of the version table CtrlObj.

[0058] The storage of the version table CtrlObj in external memory 200 and its transfer between the secure element 100 and external memory 200 can also be protected, for example, by using an authentication encryption algorithm. For instance, the version table CtrlObj is encrypted with key k1, and then the authentication element of the version table CtrlObj (in encrypted form herein) is computed using key k2 via an authentication algorithm such as a MAC algorithm. External memory 200 stores the encrypted version table [CtrlObj]. k1 and its certification component MAC [CtrlObj]Any other authentication encryption algorithm can be used.

[0059] The security element 100 includes a security central processing unit (CPU or security processor) 110, multiple internal memories 121, 122, and 130, and a loading and preprocessing system 140.

[0060] The Secure CPU 110, also known as a Secure Processor, features high-assurance-level certified security characteristics for security-critical applications. It can be an integrated hardware intellectual property core (IP core).

[0061] The first internal memory 121 is used to store digital information segments Si before they are processed by the central processing unit 110. For example, it is a cache memory.

[0062] The second internal memory 122 is used to store the version table CtrlObj of the digital information segment requested by the security CPU 110. It can be volatile memory, such as RAM.

[0063] The first internal memory 121 and the second internal memory 122 are part of the internal volatile memory system 120. They can be separate memories or different regions of a single memory.

[0064] The third internal memory 130 is a permanent (non-volatile) memory used to store data such as keys and counters. More precisely, internal memory 130 may store keys, such as master keys k1 and k2, to be used in cryptographic algorithms executed by loading and preprocessing system 140 or by security processor 110, and a freshness counter "FC" associated with version table CtrlObj. The permanent internal memory 130 may be an OTP (One-Time Programmable) non-volatile memory.

[0065] The loading and preprocessing system 140 has several functions, including: - The function to load the version table CtrlObj from external storage 200 into secure element 100. - The function of loading digital information fragments (segments) from external memory 200 into secure element 100. - The function to preprocess the version table CtrlObj to be stored in the second internal memory 122 (RAM). - The function of preprocessing digital information segments (segments) to be stored in the first internal memory 121 (cache memory) and to be processed by the security processor 110, and - A function to check the freshness of the loaded version table CtrlObj.

[0066] These functions of the loading and preprocessing system 140 are implemented by components 141 to 145, described below. These can be hardware components, software components, or a combination of both. The security processor 110 is arranged to execute the software components. Figure 7 In the diagram, components 141 to 145 are shown as being located outside the security processor 110, but they may be arranged at least partially inside the security processor 110 (specifically, software components).

[0067] The loading and preprocessing system 140 has a first loader 141, a second loader 142, an authentication and verification module 143, a decryption module 144, and a freshness check module 145 (or a replay prevention check module).

[0068] The first loader 141 is used to load the version table CtrlObj from external memory 200. The second loader 142 is used to load the digital information segment Si from external memory 200.

[0069] The authentication module 143 is configured to authenticate loaded data, such as the version table CtrlObj and the digital information segment Si. In this embodiment, it implements a MAC function and a key derivation function KDF to derive a key from the master key k1 using the version number and identifier of these segments as input, which is then used as the authentication key to authenticate the digital information segment.

[0070] The decryption module 144 is configured to decrypt loaded data, such as the version table CtrlObj and the digital information segment Si. In this embodiment, it implements a decryption algorithm and a key derivation function KDF to derive a key from the master key k2 using the version number and identifier of these segments as input, which is then used as the decryption key to decrypt the digital information segment.

[0071] Alternatively, the key derivation function can be used by both the authentication module 143 and the decryption module 144 in a separate component 146 (by... Figure 7 Implemented in (represented by dashed blocks in the text).

[0072] The freshness check module 145 is configured to check the freshness of the version table CtrlObj relative to the internal freshness counter FC in the internal memory 130 when the version table CtrlObj is loaded from the external memory 200, which will be described later in the description of the method for securely processing digital information.

[0073] The security element 100 may also include an update module 150 for updating the external memory 200 when one or more segments of digital information have been modified by the security processor 110, which will be explained later in the specification.

[0074] A host processor or CPU (not shown) may be provided outside the secure element 100 (e.g., in the SoC 300) to perform operations under the control of the secure element 100, such as loading version tables or segments. Thus, loading can be performed via the system bus or the host CPU upon request from the secure element 100.

[0075] Secure element 100 has other cryptographic functions, including cryptographic encryption functions and authentication functions such as MAC functions, which allow secure CPU 110 to encrypt and authenticate data (typically digital data pieces and version tables CtrlObj), which will be explained later. The cryptographic encryption and authentication functions are implemented by components 148 and 149. The latter are software components or hardware components, or a combination of hardware and software components.

[0076] A secure processor or secure central processing unit (CPU) 110 is configured to securely process or use digital information segments loaded into internal (cache) memory 121. It is designed to perform security-critical applications. The secure processor 110 is also configured to control the operation of secure elements, such as authenticated decryption and authenticated encryption. Furthermore, when a digital information segment has been modified during processing, the secure CPU 110 can control the updating of the version table CtrlObj in internal memory 122, as well as the updates to external memory 200 and internal memory 130 that must be performed by atomic transactions (i.e., updates to the modified segment and version table CtrlObj in external memory 200 and updates to the freshness counter FC in internal memory 130).

[0077] The update module 150 has the following function: under the control of the security processor 110, when a digital information segment has been modified during processing, it increments the freshness counter in the internal memory 130 and updates the external memory 200, as will be explained later below. It can be primarily software-based. For functional reasons, the actions of incrementing the freshness counter in the internal memory 130 and updating the external memory 200 by writing the modified digital information segment and the updated version table to the external memory 200 are advantageously performed together by a single atomic transaction.

[0078] The security element 100 also has a hardware interface 160 for direct access to the external memory 200.

[0079] The components of safety element 100 are advantageously reliable, meaning they cannot be manipulated to induce malfunction.

[0080] Now refer to Figures 2 to 6 This describes a method for securely processing digital information stored in external memory 200 by a secure element 100. The method can be divided into three processes: - The startup process is executed after the safety element 100 is turned on. Figure 2 and Figure 5 ); - A reading or preprocessing process that is performed after the startup process and before the digital information is securely processed by the security processor 110. Figure 3 and Figure 5 );as well as - The update process is performed when a digital information fragment is modified during processing by a security processor. Figure 4 and Figure 6 ).

[0081] Startup process ( Figure 2 and Figure 5 )

[0082] Initially, secure element 100 is activated. Subsequently, a boot or startup process is executed by secure element 100. During this startup process, secure element 100 may execute security protocols that protect the boot process (e.g., secure boot). During the startup process, in step S50, the first loader 141 loads the version table CtrlObj read from external memory 200. More precisely, this is encrypted and linked to its MAC address and [CtrlObj]. k1 MAC [CtrlObj] The cascaded version table CtrlObj is loaded from external memory 200 into secure element 100. Then, in step S51, authentication module 143 authenticates the version table CtrlObj. To do this, authentication module 143 uses key k2 to calculate the loaded encrypted version table [CtrlObj]. k1 The calculated MAC address is compared with the MAC address loaded with the version table. [CtrlObj] The MAC addresses are compared. If authentication is successful, in step S52, the decryption module 144 uses key k1 to decrypt the encrypted version table [CtrlObj]. k1 Decryption is then performed. If authentication fails, an error step S70 is executed after step S51. For example, in error step S70, the method for processing digital information is aborted (interrupted).

[0083] After authentication using key k2 of version table CtrlObj and decryption using key k1 of version table, in step S53, the freshness of version table CtrlObj is checked by freshness check module 145. To do this, the freshness information CtrlObj_Version included in the header of version table CtrlObj is compared with the freshness counter FC stored in internal memory 130.

[0084] If the freshness information CtrlObj_Version of the version table CtrlObj matches the freshness counter FC stored in the internal memory 130, the freshness check of the version table CtrlObj is successful, and the method continues with steps S54 to S59 of loading and preprocessing the digital information segment Si. If the freshness check of the loaded version table is unsuccessful, the method proceeds to error step S71. For example, in error step S71, the method for processing the digital information is aborted (interrupted).

[0085] Reading or preprocessing process ( Figure 3 and Figure 5 )

[0086] Following the startup process is a read or preprocessing process performed by the security element 100, used to read or preprocess digital information segments from the external memory 200.

[0087] The loading and preprocessing process includes steps S54 to S59 (described below), which are iteratively repeated for each of the multiple digital information segments Si, wherein During the loading and preprocessing process, index "i" indicates the order in which several digital information segments are sequentially retrieved from external memory 200 and then preprocessed by secure element 100 over time. This retrieval order (or loading order) does not necessarily correspond to the order in which the digital information segments are stacked in external memory 200. In other words, assuming Si is the digital information segment currently being loaded and preprocessed by secure element 100, Si+1 is the next digital information segment to be loaded and preprocessed. However, Si and Si+1 may not be consecutively stacked segments in external memory.

[0088] In step S54, a digital information segment Si in a protected form is loaded. More precisely, the second loader 142 loads an authentication element MAC containing an encrypted segment [Si] encrypted with key k1_Si and calculated with key k2_Si. [si] Cascaded digital information segment Si element [Si]|MAC [Si] .

[0089] In step S55, the authentication module 143 obtains the version number Vi from the version table CrtlObj stored in the internal memory 122. It also obtains the segment identifier ID from the version table CtrlObj. Si Because of the ID Si This corresponds to the index of version number Vi in the version table CtrlObj. Then, in step S56, the authentication verification module 143 calculates the MAC of [Si] and compares it with the MAC loaded with [Si]. [Si]The encrypted segment [Si] is authenticated by comparison. To calculate this MAC, module 143 derives the key k2_Si from the master key k2 read from internal memory 130 and uses the version number Vi and identifier ID of segment Si. Si (Read in step S55) as input to the key derivation function. If authentication is successfully achieved (i.e., the calculated MAC matches the loaded MAC), then in step S58, the encrypted segment [Si] is decrypted by the decryption module 144. Decryption uses the key k1_Si calculated from the master key k1 (read from internal memory 130) and the version number Vi and identifier ID of segment Si obtained from the version table CtrlObj stored in memory 122 in step S57. Si This serves as input to the Key Derivation Function (KDF). If authentication fails, an error step S72 is executed after step S56. For example, in error step S72, the method for processing the digital information is aborted (interrupted). Instead, the digital information segment Si can be deleted.

[0090] During the preprocessing process, in steps S55 and S57, the loading and preprocessing system 140 obtains the version number Vi and identifier ID of the digital information segment Si from the internal memory 122 (e.g., RAM). Si The identification information of segment Si is provided as input to the cryptographic algorithms used for authentication and decryption of preprocessed segment Si. Alternatively, the identification information of segment Si from the version table CtrlObj stored in internal memory 122 can be used by only one of the two cryptographic algorithms, preferably by the authentication algorithm. However, if the identification information of segment Si is also used for decryption, security is improved.

[0091] Instead of using the segment version number and segment identifier as input to generate the decryption key, use the version number Vi and segment identifier ID. Si It can be used to generate the initialization vector IV that the decryption module 144 will use to decrypt the digital information segment [Si].

[0092] After authenticating and decrypting the digital information segment Si, in step S59, segment Si is loaded into the cache memory 121 of the security processor 110.

[0093] Then, in step S60, the digital information segment Si becomes accessible to and can be securely processed by the security processor 110. For example, the security processor performs security (or security-critical) applications by processing the digital information segment Si.

[0094] For the digital information segments Si continuously loaded from external memory 200 into security element 100, steps S54 to S59 are repeated iteratively unless the process is prematurely terminated due to an error.

[0095] Update process ( Figure 4 and Figure 6 )

[0096] When the digital information segment (here referred to as "Sj", where...) When the digital information segment Sj is processed by the security processor 110, in step S80, it can be modified during its processing. The modified version of the digital information segment Sj is referred to as Sj'. In this case, the update process is implemented, and will now be referred to Figure 4 and Figure 6 Describe the update process.

[0097] When the initial segment Sj becomes the modified segment Sj', in step S81, the security processor 110 updates the version table CtrlObj stored in internal memory 122 by incrementing the version number of the modified segment Sj' in the version table CtrlObj stored in internal memory 122. If we assume the version number of the initial segment Sj is Vj, then the new version number of the modified segment Sj' is Vj+1. In step S81 of updating the version table CtrlObj in internal memory 122, the security processor 110 also updates the version number CtrlObj_Version of the version table CtrlObj, which is here in the header of the version table CtrlObj stored in internal memory 122. The version number CtrlObj_Version of the version table CtrlObj is incremented by 1 (CtrlObj_Version = CtrlObj_Version + 1). The updated version table (stored in internal memory 122) is referred to as "CtrlObj".

[0098] The secure element 100 also needs to update the external memory 200. More precisely, it needs to write the modified digital information segment Sj' and the updated version table CtrlObj' into the external memory 200. To this end, in step S82, before the control transfers the modified segment Sj' and the updated version table CtrlObj' to the external memory 200, the secure processor 110 submits the updated version table CtrlObj' and the modified segment Sj' to the authentication encryption algorithm. The same authentication encryption algorithm used is employed to prepare the data stored in the external memory. In this embodiment, the authentication encryption algorithm follows an encryption-then-MAC method. The encryption of the version table CtrlObj' uses a key k1 and is applied to [CtrlObj']. k1 The MAC function uses key k2. The encryption of the modified digital information segment Sj' uses the derived key k1_Vj+1, where k1_Vj+1 = KDF(k1, Vj+1, ID). SjIt should be noted that the segment identifier of the modified segment Sj' is the same as the segment identifier of the corresponding segment Sj (before modification). Authentication of the encrypted modified digital information segment [Sj'] uses the derived key k2_Vj+1, where k2_Vj+1 = KDF(k2,Vj+1,ID). Sj’ ).

[0099] Then, in step S83, under the control of the security processor 110, the update module 150 increments the freshness counter FC of the version table in the internal memory 130 and writes the new version table CtrlObj' and the modified digital information segment Sj' into the external memory 200. The freshness counter FC is incremented by 1 here. All these actions (incrementing FC in the internal memory 130 and writing CtrlObj' and Sj' into the external memory 200) are performed together by a single atomic transaction. This type of operation has only two persistent states: an unmodified initial state and a modified final state. The operation can be fast or take a long time.

[0100] A process similar to the update process described above can be initially performed by the secure element 100 to store the digital information segment in encrypted and authenticated form in the external memory 200. The secure element 100 may have a firmware security loader configured to securely load the digital information to be stored in the external memory from a digital information provider, for example, via a communication network or via a local connection to another machine. The secure element can be configured to...

[0101] - The loaded digital information is segmented into digital information segments, these segments are authenticated and encrypted (using the same method as described in the update process for the modified segment Sj'), and then written to external memory. - Generate a version table CtrlObj, authenticate and encrypt the version table (in the same way as described in the update process), and then write it to external storage.

[0102] The second implementation scheme is based on the first implementation scheme, differing only in the authentication encryption algorithm. In the second exemplary implementation scheme, the authentication encryption follows a method of type "MAC-then-Encrypt-then-MAC". For each digital information segment Si, the method includes: calculating the first MAC "MACi1" of segment Si using a first key k0_Vi (derived from the master key k0 and using the version number Vi as input), then encrypting segment Si and the concatenated first MAC (i.e., Si|MACi1) using a second key k1_Si (derived from the master key k1 and using the version number Vi as input), and then calculating the second MAC "MACi2" of the encryption result (i.e., [Si]|[MACi1]) using a third key k2_Si (derived from the master key k2 and using the version number Vi as input) to obtain the protected segment [Si]|[MACi1]|MACi2.

[0103] The third implementation scheme is based on the first or second implementation scheme, differing only in that the identification information of the digital information segment used as input in the authentication and / or decryption operations contains only the version number of the digital information segment. This type of implementation scheme is suitable, for example, when the secure element loads only a segment or fragment of digital information.

[0104] Different types of MAC functions can be used. For example, the CMAC function (Cryptographic Message Authentication Code) (which is a block cipher-based message authentication code algorithm) or the HMAC algorithm (Hash-based Message Authentication Code) (which is a specific type of message authentication code (MAC) involving a cryptographic hash function and a secret key) can be used. Any other authentication function can be used instead of the MAC function.

Claims

1. A secure element (100) for securely processing digital information, the digital information being segmented and stored in multiple segments of number M in a memory (200) external to the secure element (100), the secure element comprising: - A security processor (110) for securely processing the plurality of segments of digital information, the number of which is M; -System (140), the system is configured to load digital information segment Si from the external memory (200) into the secure element (100), and preprocess the digital information segment by executing a cryptographic algorithm before it is processed by the secure processor (110); The system (140) is configured to determine identification information of the loaded digital information segment, the determination of the identification information including obtaining the version number of the digital information segment and executing the cryptographic algorithm by using the identification information; The system (140) is characterized in that it is configured to load a version table CtrlObj containing M segments of digital information, with corresponding version numbers, from the external memory (200) into the internal memory (122) of the security element (100), and to read the version number of each digital information segment loaded into the version table CtrlObj stored in the internal memory (122).

2. The security element of claim 1, wherein the system (140) is configured to determine the identification information of the digital information segment, the determination of the identification information further comprising obtaining a segment identifier of the digital information segment and performing the cryptographic algorithm by using the identification information, the segment identifier being an index assigned to a corresponding digital information segment in the external memory or an identifier present in the header of the corresponding digital information segment.

3. The security element according to any one of claims 1 and 2, wherein the security element stores at least one unique cryptographic key, the at least one unique cryptographic key being uniquely generated for the security element and used by the system when executing the cryptographic algorithm.

4. The security element of claim 3, wherein the system (140) includes a key derivation function to generate at least one cryptographic key to be used by the cryptographic algorithm by using the at least one unique cryptographic key and the identification information of the digital information segment Si as input.

5. The security element according to any one of claims 1 to 2, wherein the cryptographic algorithm includes an authentication algorithm MAC for authenticating the loaded digital information segment Si.

6. The security element according to any one of claims 1 to 2, wherein the cryptographic algorithm includes a decryption algorithm for decrypting the loaded digital information segment Si.

7. The security element according to claim 6, wherein the system (140) is configured to generate an initialization vector IV to be used by the decryption module (144) by using the identification information of the digital information segment Si as input.

8. The security element according to any one of claims 1 to 2, wherein the system (140) is further configured to verify the freshness information CtrlObj_Version of the version table CtrlObj by comparing the freshness information CtrlObj_Version of the version table CtrlObj with a freshness counter FC stored in the internal non-volatile memory (130) of the security element (100).

9. The security element according to any one of claims 1 to 2, wherein the system (140) is configured to load the version table CtrlObj during the startup process of the security element (100).

10. The security element according to any one of claims 1 to 2, wherein the system (140) is configured to authenticate and decrypt the loaded version table CtrlObj.

11. The security element according to claim 8 further includes an update module (150) configured to control the following operations when the digital information segment Sj is modified while being processed by the security processor (110): writing the modified digital information segment Sj' and the updated version table CtrlObj' into the external memory (200) and incrementing the freshness counter in the internal non-volatile memory (130).

12. A system comprising a security element (100) according to any one of claims 1 to 11 and an external memory (200) for storing the digital information.

13. A method for securely processing digital information by a secure element (100), the digital information being segmented and stored in a plurality of segments of number M in a memory (200) external to the secure element (100), the method comprising the following steps performed by the secure element (100): - Load the digital information segment Si from the external memory (200) into the secure element (100); - The identification information of the loaded digital information segment is determined by obtaining the version number Vi of the digital information segment; - The digital information segment Si is preprocessed by performing a cryptographic algorithm using the identification information before being processed by the security processor (110) of the security element (100); The digital information segment Si is securely processed by the security processor (110); Its features are, The method also includes The steps of loading a version table CtrlObj containing M segments of digital information, with corresponding version numbers, from the external memory (200) into the internal memory (122) of the security element (100), and reading the version number Vi of each digital information segment loaded into the version table CtrlObj stored in the internal memory (122).

14. The method of claim 13, further comprising the step of verifying the freshness information CtrlObj_Version of the version table CtrlObj by comparing it with a freshness counter FC stored in the internal non-volatile memory (130) of the security element (100).

Images