Identification of errors in executed code

Abstract

The present disclosure includes devices, methods, and systems for error identification of executed code. Embodiments include a memory and a circuit system configured to: read data stored in a secure array of the memory; identify a different memory having an error correction code (ECC) corresponding to the read data of the memory; perform an integrity check to compare the ECC with the read data of the memory; and take an action in response to the comparison of the read data of the memory with the ECC, wherein the comparison indicates that the ECC identifies an error in the read data of the memory.

Description

Technical Field

[0001] The present disclosure relates generally to semiconductor memories and methods, and more particularly to identifying errors in executed code. Background Art

[0002] Memory devices are typically provided as internal semiconductor integrated circuits and / or external removable devices in computers or other electronic devices. There are many different types of memory, including volatile and non-volatile memory. Volatile memory may require power to maintain its data, and may include random access memory (RAM), dynamic random access memory (DRAM), and synchronous dynamic random access memory (SDRAM), among others. Non-volatile memory may provide permanent data by preserving stored data when not powered, and may include NAND flash memory, NOR flash memory, read-only memory (ROM), and resistance variable memory, such as phase change random access memory (PCRAM), resistive random access memory (RRAM), and magnetic random access memory (MRAM), among others.

[0003] Memory devices may be combined together to form solid state drives (SSDs), embedded multimedia cards (e.g., MMCs), and / or universal flash storage (UFS) devices. SSDs, e.MMCs, and / or UFS devices may include non-volatile memory (e.g., NAND flash memory and / or NOR flash memory), and / or may include volatile memory (e.g., DRAM and / or SDRAM), as well as various other types of non-volatile and volatile memory. Non-volatile memory may be used in a wide range of electronic applications, such as personal computers, portable memory sticks, digital cameras, cellular phones, portable music players such as MP3 players, movie players, and the like.

[0004] Flash memory devices may include memory cells that store data in a charge storage structure such as a floating gate. Flash memory devices typically use single-transistor memory cells that allow for high memory density, high reliability, and low power consumption. Resistance variable memory devices may include resistive memory cells that can store data based on the resistance state of a storage element (e.g., a resistive memory element having a variable resistance).

[0005] Memory cells can be arranged in an array, and memory cells in the array architecture can be programmed to a target (e.g., desired) state. For example, charge can be placed on or removed from a charge storage structure (e.g., a floating gate) of a flash memory cell to program the cell to a specific data state. The stored charge on the charge storage structure of the cell can indicate the threshold voltage (Vt) of the cell. The state of a flash memory cell can be determined by sensing the stored charge (e.g., Vt) on the charge storage structure of the cell.

[0006] Errors introduced into the code and threats imposed on the stored code may affect the operation of the memory device and / or the data stored in the memory cells of the memory device. Errors may be introduced by noise and / or during transmission. Threats may include, for example, threats from hackers or other malicious users, including intentional error introduction, man-in-the-middle (MITM) attacks, etc. Such threats may cause significant financial losses, and / or may cause significant safety and / or security issues. Summary of the invention

[0007] In one aspect, the present application provides a device for error identification in executed code, the device comprising: a memory; and a circuit system associated with the memory, the circuit system configured to: read data stored in a secure array of the memory; identify different memories having error correction codes (ECCs) corresponding to the read data of the memory; perform an integrity check to compare the ECC with the read data of the memory; and take action in response to the comparison of the read data of the memory with the ECC, wherein the comparison indicates that the ECC identifies an error in the read data of the memory.

[0008] In another aspect, the present application provides a device for error identification in executed code, the device comprising: a memory; and a circuit system associated with the memory, the circuit system configured to: read an error correction code (ECC) stored in a security array of the memory; identify a different memory having read data corresponding to the ECC of the memory; perform an integrity check to compare the ECC with the read data of the different memory; and take action in response to a comparison of the read data of the different memory with the ECC of the memory, wherein the comparison indicates that the ECC identifies an error in the read data of the different memory.

[0009] In yet another aspect, the present application provides a system for error identification in executed code, the system comprising: a controller; a first memory device that communicates with the controller; a second memory device that communicates with the controller, the controller being configured to: receive read data from the first memory device; receive an error correction code (ECC) corresponding to the read data of the first memory device; perform an integrity check by comparing the read data of the first memory device with the ECC provided by the second memory device; and take action in response to the comparison of the read data of the first memory device with the ECC, wherein the comparison indicates that the ECC identifies an error in the read data of the first memory device.

[0010] In yet another aspect, the present application provides a method for error identification in executed code, the method comprising: receiving read data from a first memory device; receiving an error correction code (ECC) from a second memory device, wherein the ECC corresponds to the read data of the first memory device; comparing the ECC from the second memory device with the read data of the first memory device to determine errors detected by the ECC; determining integrity of the read data of the first memory based on the comparison of the ECC with the read data of the first memory; and taking action in response to the determined integrity of the read data of the first memory. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 A diagram illustrating a portion of a memory array having several physical blocks according to an embodiment of the disclosure.

[0012] Figure 2A An example of a pair of registers for defining a secure memory array according to an embodiment of the present disclosure is described.

[0013] Figure 2B A diagram illustrating a portion of a memory array including a defined secure memory array according to an embodiment of the present disclosure.

[0014] Figure 3 is a block diagram of a computing system including a host and an apparatus in the form of a memory device according to an embodiment of the present disclosure.

[0015] Figure 4 An example block diagram illustrating an example system including a host controller and a device according to an embodiment of the present disclosure.

[0016] Figure 5 An example flow chart illustrating error identification in executed code according to an embodiment of the present disclosure.

[0017] Figure 6 is a block diagram of an example system including a host and a memory device according to an embodiment of the present disclosure.

[0018] Figure 7 is a block diagram of an example process for determining several parameters according to an embodiment of the present disclosure.

[0019] Figure 8 is a block diagram of an example process for determining several parameters according to an embodiment of the present disclosure.

[0020] Fig. 9 is a block diagram of an example process for verifying credentials according to an embodiment of the present disclosure.

[0021] Fig.10 is a block diagram of an example process of verifying a signature according to an embodiment of the present disclosure.

[0022] Fig.11 is a block diagram of an example memory device according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0023] The present disclosure includes apparatus, methods, and systems for error identification in executed code. Error correction operations may be performed on a host computing system and / or on a memory device. Embodiments include a memory and circuitry configured to identify errors in executed code (e.g., read data) by comparing data read by a memory device with an error correction code (ECC) read by a different memory device. The read data of a memory device is compared with the ECC of a different memory device to determine whether there is an error in the read data.

[0024] The memory device may be used to store data in a computing system, and may transfer this data between hosts associated with the computing system. The data stored in the memory device may be code for routines important to the operation of the host. For example, the host device may be a vehicle, and the routine may be the operation of the powertrain or vehicle. The memory device may be used as non-volatile memory for a wide range of electronic applications.

[0025] A host may be communicatively coupled to a plurality of memory devices. In one example, the memory device may include data stored in a security array of the memory device. The memory device may include circuitry for identifying different memory devices having error correction codes (ECCs) corresponding to data read by the memory device. The circuitry may be configured to perform an integrity check. An integrity check refers to a comparison of error correction data with read data. For example, the circuitry may be configured to perform an integrity check to compare the ECC with read data of the memory device, and take action in response to the comparison of the read data with the ECC. When the ECC indicates a correction, the data read by the memory device may include similar errors, and a correction action may be taken to correct the error.

[0026] Errors (e.g., faults) may be introduced into data stored by a memory device (e.g., data stored in a memory cell) in a variety of ways. Errors may be introduced into the code unintentionally by noise and / or damage during transmission. In some cases, errors may be introduced unintentionally into data stored in memory, causing changes in the operation of the memory. Errors may also be intentionally introduced into data stored by memory through threats. For example, a hacker or other malicious user may introduce errors in an attempt to perform activities (e.g., attacks), such as man-in-the-middle (MITM) attacks, to make unauthorized changes to the operation of the memory and / or to the data stored therein for malicious purposes. Another example of a threat and / or consequence of an error introduced into data stored by memory is that a hacker or other malicious user may attempt to skip a portion of a command (e.g., a portion of executable code) referred to herein as a routine, written as a check and / or security protocol to authenticate the command.

[0027] During this attack and / or error, the routine is skipped and / or altered, but the host may receive an indication that the routine has been executed. In other words, the hacker and / or error may tamper with the command and cause the host to receive an indication that the routine has been executed. Important routines written to check the authenticity of the command (authenticating components, authenticating software versions and / or updates, user identification, etc.) may be designed to be executed during the startup (e.g., booting) of the memory device. Hackers and / or introduced errors may change (e.g., mask) external inputs to trigger conditions so that routines written to verify the authenticity of commands may be skipped. An example of this routine may be a portion of executable code written to check the authenticity of a payment before executing a software service (e.g., issuing money and / or transmitting data from an ATM, executing software, etc.). Other examples may include routines for verifying software licenses to authenticate software as genuine before execution (computer system updates, installing software, etc.), important operating routines of the host device (e.g., startup operations, powertrain operations, etc.), and / or routines for checking the authenticity of system components and the configuration of system components (e.g., process plant control, automotive components).

[0028] Detection and correction of errors can be challenging because correction of detected errors may generate additional (e.g., new) errors. This may cause unreliability in the resulting architecture of the code (e.g., routines) and may affect the operation of the memory and the code stored in the memory. Many memory devices employ error checking techniques, such as ECC, that detect bit errors in data. ECC may be associated with a group of cells, such as a memory block, a memory segment, or a memory sector, and may rescue read failures by detecting and possibly correcting bit errors. Examples of ECC codes include Hamming codes, Reed-Solomon (RS) codes, Bose-Chaudhuri-Hochquenghem (BCH) codes, cyclic redundancy check (CRC) codes, Golay codes, Reed-Muller codes, Goppa codes, and Denniston codes, among others. In some methods, these and other error checking techniques are performed on a memory device by a controller including a circuit system coupled to the memory device. As mentioned, while identifying and correcting errors, the ECC may inadvertently introduce new errors into important routines (eg, commands).

[0029] Thus, to ensure that errors indicated by the ECC are identified, but new errors are not introduced when correcting the identified errors, a warning may be generated when such errors are detected. A host may be associated with multiple memory devices to detect these errors. For example, a host device may include a host controller communicatively coupled to multiple memory devices (e.g., ECC memory devices and non-ECC memory devices). The multiple memory devices may be respectively provided with data (e.g., commands and / or routines) and / or ECC corresponding to the data.

[0030] In some examples, the ECC and corresponding routines may be securely provided to the memory device during the manufacturing stage, and / or securely verified using exchanged public / private keys (discussed further herein). An ECC memory device containing an ECC and a memory device containing corresponding data (e.g., a routine) may be read in parallel by the respective memory devices. The executed ECC and data may be compared by a host device and / or a controller associated with the host device. When an error is identified by an ECC running on a memory device having an ECC, the data executed by the data memory device may be identified as containing a potential error. In other words, because the data in the memory device corresponds to the ECC in another memory device, the error identified by the ECC indicates an error in the data of the memory device. In this case, in order to avoid unintentional errors introduced by implementing automatic correction, actions may be taken to alert the host and / or controller that an error in the data of the memory device has been identified. At this point, multiple decisions may be made about how to correct the error without changing the architecture of the important routine.

[0031] Embodiments of the present disclosure may utilize cryptographic primitive solutions (e.g., ECC and or calculated digests) in important routines for error detection by combining ECC and data comparisons performed in parallel by different memory devices communicatively coupled to a host device. Such solutions may identify errors introduced into the code unintentionally and / or intentionally. This may prevent bad operations of important routines written to avoid financial losses, security protocols, and / or provide security checks on the operation of the host device. In addition, when errors are identified, the introduction of new errors may be avoided by avoiding automatic correction. Alternatively, an action (e.g., a warning, alarm, and / or termination of a routine) may be determined by the host and / or a memory device associated with the host.

[0032] As used herein, "a / an" or "several" may refer to one or more of something, and "multiple" may refer to two or more of such things. For example, a memory device may refer to one or more memory devices, and multiple memory devices may refer to two or more memory devices. In addition, the designators "M", "P", "R", "B", "S", and "N" as used herein, particularly with respect to the reference numerals in the drawings, indicate that several specific features so designated may be included with several embodiments of the present disclosure. The numbers between the designations may be the same or different.

[0033] The figures herein follow a numbering convention in which the first one or more digits correspond to the figure number and the remaining digits identify the element or component in the figure. Similar elements or components between different figures may be identified by using similar numerals. For example, 101 may represent Figure 1 2 , and similar elements may be represented as 201 in FIG. 2 .

[0034] Figure 1 A diagram illustrating a portion of a memory array 101 having several physical blocks according to an embodiment of the present disclosure. The memory array 101 can be, for example, a flash memory array, such as a NAND flash memory array. As an additional example, the memory array 101 can be a resistance variable memory array, such as a PCRAM, RRAM, MMRAM, or a spin torque transfer (STT) array, among others. However, embodiments of the present disclosure are not limited to a particular type of memory array. In addition, the memory array 101 (e.g., a subset of the array 101 or the entire array 201) can be a secure memory array, as will be further described herein. In addition, although Figure 1 1. Although not shown in FIG. 1, memory array 101 may be located on a particular semiconductor die along with various peripheral circuitry associated with its operation.

[0035] like Figure 1 As shown, memory array 101 has a number of physical blocks 107-0 (block 0), 107-1 (block 1), ..., 107-B (block B) of memory cells. The memory cells may be single-level cells and / or multi-level cells, such as two-level cells, three-level cells (TLC), or quad-level cells (QLC). As examples, the number of physical blocks in memory array 101 may be 128 blocks, 512 blocks, or 1,024 blocks, but embodiments are not limited to a specific power of two or any specific number of physical blocks in memory array 101.

[0036] A memory cell plane may include several physical blocks of memory cells (e.g., blocks 107-0, 107-1, ..., 107-B), and a die may include several memory cell planes. Figure 1 In the example shown, each physical block 107-0, 107-1, ..., 107-B may be part of a single die. Figure 1 The portion of the memory array 101 illustrated in may be a die of memory cells.

[0037] like Figure 1 As shown, each physical block 107-0, 107-1, ..., 107-B includes a number of physical rows (e.g., 103-0, 103-1, ..., 103-R) of memory cells coupled to access lines (e.g., word lines). The number of rows (e.g., word lines) in each physical block can be 32, but embodiments are not limited to a particular number of rows 103-0, 103-1, ..., 103-R per physical block. In addition, although Figure 1 Not shown in , but memory cells can be coupled to columns of sense lines (eg, data lines and / or digit lines).

[0038] As will be appreciated by those skilled in the art, each row 103-0, 103-1, ..., 103-R may include several pages (e.g., physical pages) of memory cells. A physical page refers to cells that are programmed and / or sensed (e.g., several memory cells that are programmed and / or sensed together as a functional group). Figure 1 In the embodiment shown in , each row 103-0, 103-1, ..., 103-R includes one physical page of memory cells. However, the embodiments of the present disclosure are not limited thereto. For example, in an embodiment, each row may include multiple physical pages of memory cells (e.g., one or more even memory cell pages coupled to even-numbered data lines, and one or more odd memory cell pages coupled to odd-numbered data lines). In addition, for embodiments including multi-level cells, a physical page of memory cells may store multiple data pages (e.g., logical pages) (e.g., an upper data page and a lower data page, where each cell in the physical page stores one or more bits toward the upper data page and one or more bits toward the lower data page).

[0039] like Figure 1 As shown, a page of memory cells may include a number of physical sectors 105-0, 105-1, ..., 105-S (e.g., a subset of memory cells). Each physical sector 105-0, 105-1, ..., 105-S of a cell may store a number of logical sectors of data. In addition, each logical sector of data may correspond to a portion of a particular page of data. As an example, a first logical sector of data stored in a particular physical sector may correspond to a logical sector corresponding to a first page of data, and a second logical sector of data stored in a particular physical sector may correspond to a second page of data. Each physical sector 105-0, 105-1, ..., 105-S may store system and / or user data, and / or may include overhead data, such as error correction code (ECC) data, logical block address (LBA) data, and metadata.

[0040] Logical block addressing is a scheme by which a host can identify logical sectors of data. For example, each logical sector may correspond to a unique logical block address (LBA). Additionally, an LBA may also correspond to (e.g., dynamically map to) a physical address, such as a physical block address (PBA), that may indicate the physical location of a logical sector of data in memory. A logical sector of data may be a number of bytes of data (e.g., 256 bytes, 512 bytes, 1,024 bytes, or 4,096 bytes). However, embodiments are not limited to these examples.

[0041] It should be noted that other configurations for physical blocks 107-0, 107-1, ..., 107-B, rows 103-0, 103-1, ..., 103-R, sectors 105-0, 105-1, ..., 105-S, and pages are possible. For example, rows 103-0, 103-1, ..., 103-R of physical blocks 107-0, 107-1, ..., 107-B may each store data corresponding to a single logical sector, which may include, for example, more or less than 512 bytes of data.

[0042] Figure 2A An example of a pair of registers 214-1 and 214-2 for defining a secure memory array according to an embodiment of the present disclosure is described, and Figure 2B A diagram illustrating a portion of a memory array 201 including a secure memory array defined using registers 214-1 and 214-2 according to an embodiment of the present disclosure. Although embodiments are not limited thereto, one or more registers and / or one or more pairs of registers may be used. Figure 2B As shown in Figure 1 With the manner in which the memory array 101 is described, the secure memory array 201 may include a number of physical blocks 207-0, 207-1, ..., 207-B of memory cells, each physical block including a number of physical rows 203-0, 203-1, ..., 203-R having a number of memory cell sectors.

[0043] like Figure 2A As shown in , register 214-1 can define the address of the security array (e.g., the address of the different parts of the security array), and register 214-2 can define the size of the security array (e.g., the size of the different parts of the security array). The address of the security array defined by register 214-1 can correspond to, for example, a starting point (e.g., a starting LBA) of the security array (e.g., the starting point of the different parts of the security array), and the size of the security array defined by register 214-2 can correspond to, for example, an ending point (e.g., an ending LBA) of the security array (e.g., the ending point of the different parts of the security array).

[0044] For example, if Figure 2A As shown in , registers 214-1 and 214-2 may define N pairs of values, where each respective pair includes an address value (e.g., addr) defined by register 214-1 and a size value (e.g., size) defined by register 214-2. Figure 2AIn the example described in , Pair0 includes an address value addr0 and a size value size0 (e.g., Pair0= [addr0, size0]), Pair1 includes an address value addr1 and a size value size1 (e.g., Pair1= [addr1, size1]), etc., where Pair N Including address value addr N and size value size N (For example, Pair N = [addr N , size N ]). The address value of a pair may correspond to a starting point of a portion of the security array (e.g., a starting LBA), and the sum of the address value and the size value of the pair may correspond to an ending point of the portion of the security array (e.g., an ending LBA). Thus, the entire security array (e.g., a portion including the entire security array) may be given by the following formula: [addr0, addr0+ size0] ∪[addr1, addr1+ size1] ∪ … ∪ [addr N , addr N + size N ].

[0045] The first pair of zeros defined by register 214-2 may stop the definition of the security array. Figure 2A In the example illustrated in , if the size value of Pair2 is zero, then the secure array will be given by the following formula: [addr0, addr0+ size0] ∪ [addr1, addr1+ size1].

[0046] exist Figure 2B An example of a security array defined by registers 214-1 and 214-2 is illustrated in FIG. 214-1 and 214-2 (eg, all size values ​​defined by register 214-2 are non-zero). For example, Figure 2B As shown in FIG. 1 , the address (e.g., LBA) associated with sector 205-0 of the memory array 201 is addr0, the address associated with sector 205-1 of the memory array 201 is addr0+size0, the address associated with sector 205-2 of the memory array 201 is addr1, the address associated with sector 205-3 of the memory array 201 is addr1+size1, and the address associated with sector 205-4 of the memory array 201 is addr0. N , and the address associated with sector 205-5 of memory array 201 is addr N + size NThus, the security array includes sectors (e.g., data stored in the sectors) 205-0 to 205-1, sectors 205-2 to 205-3, and 205-4 to 205-5. However, sectors of the memory array 201 that are located before sector 205-0 and sectors 205-1 to 205-2 of the memory array 201 are not part of the security array (e.g., the security array includes a subset of the array 201).

[0047] Figure 3 3 is a block diagram of a computing system 300 including a host 302 and an apparatus in the form of a memory device 306 according to an embodiment of the present disclosure. As used herein, an "apparatus" may refer to, but is not limited to, any of a variety of structures or combinations of structures, such as a circuit or circuit system, one or more dies, one or more modules, one or more devices, or one or more systems. In addition, in an embodiment, computing system 300 may include several memory devices similar to memory device 306.

[0048] exist Figure 3 In the embodiment illustrated in FIG. 1 , the memory device 306 may include a memory 316 having a memory array 301. The memory array 301 may be similar to a memory array 316 in combination with a memory array 301. Figure 1 The memory array 101 described herein is combined with Figure 2B Depicted memory array 201. Additionally, in embodiments, memory array 301 (eg, a subset of array 301, or the entire array 301) may be a secure array (eg, an area of ​​memory 316 that is to remain controlled).

[0049] Figure 3 A pair of registers 314-1 and 314-2 is illustrated, but embodiments are not limited thereto and one or more registers and / or one or more pairs of registers may be used. Registers 314-1 and 314-2 may be, for example, a combination of Figure 2A The registers 214-1 and 214-2 described above and the secure memory array 301 may be, for example, combined with Figure 2B 306. The data stored in the memory array 301 (e.g., data 333) may include sensitive (e.g., non-user) data, such as device firmware and / or code to be executed for sensitive applications (e.g., routines). In some examples, the memory device 306 may include an ECC corresponding to the data 333, wherein the ECC and / or a digest of the data calculated by the memory device 306 is stored by the memory 316 in a manner similar to that of the memory device 316. Figure 3 The same method as described for data 333 (this embodiment is combined with Figure 4 Discussion) storage.

[0050] In such embodiments, the pair of non-volatile registers 314-1 and 314-2 may be used to define a security array to store data 333 (and / or ECC, corresponding data and / or digest). Figure 3 In the embodiment illustrated in , circuit system 310 includes registers 314-1 and 314-2 that can be used to define a security array. For example, register 314-1 can define the address of the security array (e.g., the starting LBA of the data), and register 314-2 can define the size of the security array (e.g., the ending LBA of the data). Using this approach, data 333 can be stored and protected by memory device 306.

[0051] like Figure 3 , host 302 may be coupled to memory device 306 via interface 304. Host 302 and memory device 306 may communicate (e.g., send commands and / or data) over interface 304. Host 302 and / or memory device 306 may be or may be part of a computing device, a laptop computer, a personal computer, a digital camera, a digital recording and playback device, a mobile phone, a PDA, a memory card reader, an interface hub, or an Internet of Things (IoT) enabled device, such as an automotive (e.g., vehicle and / or transportation infrastructure) IoT enabled device or a medical (e.g., implantable and / or health monitoring) IoT enabled device, as well as other host systems, and may include a memory access device (e.g., a processor). One of ordinary skill in the art will appreciate that a "processor" may be one or more processors, such as a parallel processing system, a number of coprocessors, and the like.

[0052] The interface 304 may be in the form of a standardized physical interface. For example, when the memory device 306 is used for information storage in the computing system 300, the interface 304 may be a Serial Advanced Technology Attachment (SATA) physical interface, a Peripheral Component Interconnect Express (PCIe) physical interface, a Universal Serial Bus (USB) physical interface, or a Small Computer System Interface (SCSI), among other physical connectors and / or interfaces. However, in general, the interface 304 may provide an interface for passing control, address, information (e.g., data), and other signals between the memory device 306 and a host (e.g., host 302) having a compatible receiver for the interface 304.

[0053] The memory device 306 includes a controller 308 that communicates with the host 302 and the memory 316 (e.g., the memory array 301). For example, the controller 308 can send commands to perform operations on the memory array 301, including operations to sense (e.g., read), program (e.g., write), move and / or erase data, among other operations.

[0054] The controller 308 may be included on the same physical device (e.g., the same die) as the memory 316. Alternatively, the controller 308 may be included on a separate physical device that is communicatively coupled to the physical device that includes the memory 316. In an embodiment, the components of the controller 308 may be spread across multiple physical devices as a distributed controller (e.g., some components on the same die as the memory and some components on different dies, modules, or boards).

[0055] The host 302 may include a host controller 321 that communicates with the memory device 306. The host controller 321 may be included on the same physical host 302. Alternatively, the host controller 321 may be a physical device that is communicatively coupled to the memory device 306 and / or multiple memory devices (in combination). Figure 4 306). The host controller 321 can send commands to the memory device 306 via the interface 304. The host controller 321 can communicate with the memory device 306 and / or the controller 308 on the memory device 306 to read, write and / or erase data, as well as perform other operations. In addition, in an embodiment, the host 302 can be an IoT-enabled device with IoT communication capabilities as described herein.

[0056] The controller 308 on the memory device 306 and / or the host controller 321 on the host 302 may include control circuitry and / or logic (e.g., hardware and firmware). In an embodiment, the controller 308 on the memory device 306 and / or the host controller 321 may be an application specific integrated circuit (ASIC) coupled to a printed circuit board that includes a physical interface. In addition, the memory device 306, the host controller 321, and / or the host 302 may include a buffer of volatile and / or non-volatile memory and a number of registers (e.g., registers 314-1 and 314-2).

[0057] For example, if Figure 3 As shown in , memory device 306 may include circuitry 310. Figure 3 In the embodiment illustrated in , the circuit system 310 is included in the controller 308. However, the embodiments of the present disclosure are not limited thereto. For example, in an embodiment, the circuit system 310 may be included in the memory 316 (e.g., on the same die) (e.g., instead of the controller 308). The circuit system 310 may include, for example, hardware, firmware, and / or software.

[0058] The computing system 300 (e.g., the host 302 and the memory device 306) may utilize the error identification in the executed code to determine whether an error has been identified in the data 333. For example, the circuit system 310 may read the data 333 stored in the array 301 of the memory 316. The circuit system 310 may identify different memories that may include ECCs corresponding to the data 333 read by the circuit system 310. As mentioned, the automatic correction of errors introduced to the data 333 may introduce additional errors. The memory device 306 may perform an integrity check to compare the ECC with the data 333 read by the memory device 306. The memory device 306 may take action in response to the comparison of the read data of the memory 316 with the ECC, wherein the comparison indicates that the ECC identifies an error in the data 333 read by the memory 316. In this way, the memory device 306, the host controller 321, and / or the host 302 may determine how to correct the error identified by the ECC.

[0059] For example, circuit system 310 may be configured to determine whether an error identified by the ECC affects the operation of host 302 associated with data 333 read by memory 316. For example, data 333 may be code for a routine related to powertrain operation of host 302 in the form of a vehicle. During manufacturing and / or another safety instance, the powertrain routine may be provided to memory 316 as data 333 and to a different memory as the ECC. Memory device 306 may be a boot memory device that executes the powertrain routine (e.g., data 333).

[0060] The host controller 321, the circuit system 310, and / or the memory 316 may perform an integrity check in response to a boot process of the memory 316 and / or other indication of the execution data 333. The integrity check may include comparing, by the host controller 321, the circuit system 310, and / or the memory 316, the ECC read by different memories included on different memory devices in parallel with the data 333 read by the memory 316. The integrity check may include determining, by the circuit system 310 and / or the host 302, that the correction applied to the error identified by the ECC introduces additional errors into the ECC. In other words, the automatic correction of the identified error by the ECC may have introduced new errors into the ECC, and applying a similar correction to the data 333 may introduce additional errors into the data 333. The introduction of other errors may cause routines to be skipped, altered, and / or other operational problems. Based on the integrity check, host 302, host controller 321, and / or circuitry 310 may take action in response to errors identified by the ECC to avoid correcting errors corresponding to memory read data 333, and / or may determine an alternative correction method.

[0061] Figure 44 is a block diagram illustrating an example system 409 including a host controller 421 and example memory devices 406-1 and 406-2 according to an embodiment of the present disclosure. Figure 3 The host 302 of FIG. 4 may include a host controller 421, wherein the host controller 421 may be communicatively coupled to at least one memory device (e.g., memory device 406-1) and at least one other memory device (e.g., memory device 406-2). For example, Figure 4 The system 409 illustrated in includes a host controller 421 communicatively coupled to a memory device 406-1 having a memory 416-1 and an array 401-1 via an interface 404-1. The host controller 421 is illustrated as being communicatively coupled to another memory device 406-2 having a memory 416-2 and an array 401-2 via an interface 404-2.

[0062] Memory device 406-1 may include data 433-1, 433-2, and 433-N (e.g., Figure 3 Data 433-1, 433-2, and 433-N may be code streams corresponding to routines. Data 433-1, 433-2, and 433-N for routines may be encoded and securely provided to memory device 406-1 using a public / private key exchange between a host associated with host controller 421 and memory device 406-1. ECC 432-1, 432-2, and 432-M may correspond to data 433-1, 433-2, and 433-N and may be securely provided to memory device 406-2 using a public / private key exchange between a host associated with host controller 421 and memory device 406-1. Figures 6 to 11 The generation and verification of public and private keys is further discussed.

[0063] In some examples, the data 433-1, 433-2, and 433-N constituting the code stream for the routine may be fixed data units (e.g., 5 to 8 double words, but examples are not limited thereto). The routine may be a runtime executable code that may be important to the operation of the host corresponding to the host controller 421. In order to detect errors in the data 433-1, 433-2, 433-N and determine actions to correct the errors, the host controller 421 may be associated with a different memory device 406-2, wherein the different memory device 406-2 is equipped with a routine (e.g., a code stream for the routine encoded in the data 433-1, 433-2, and 433-N) and an error correction / detection capability.

[0064] For example, memory device 406-2 may include ECC 432-1, 432-2, 432-M corresponding to a routine and / or digest 435-1, 435-2, 435-P corresponding to a routine. ECC 432-1, 432-2, 432-M may include a code corresponding to data 433-1, 433-2, and 433-N of memory device 406-1, where the ECC is a bit parity concatenated therewith. For example, ECC 432-1 may include a code for data 433-1 concatenated with an error correction portion, ECC 432-2 may include a code for data 433-2 concatenated with an error correction portion, and ECC 432-M may include a code for data 433-N concatenated with an error correction portion.

[0065] Abstracts 435-1, 435-2, and 435-P are provided by circuit systems (e.g., Figure 3 The digests 435-1, 435-2, and 435-P are products of hash functions applied by the circuitry 310 of the routine to the code (e.g., data 433-1, 433-2, 433-N). For example, digests 435-1, 435-2, and 435-P may be cryptographic primitives (e.g., hashes) generated from corresponding data (e.g., data 433-1, 433-2, 433-N), where changes to the data may produce different digests. In other words, when there is an error in data 433-1, the digest calculated by the circuitry of data 433-1 will change.

[0066] For example, digest 435-1 may be a hash of data 433-1, digest 435-2 may be a hash of data 433-2, and digest 435-P may be a hash of data 433-N. The ECCs (432-1, 432-2, 432-M) and digests (435-1, 435-2, 435-P), used alone or together, may be configured by a host (e.g., Figure 3 host 302), host controller 421 and / or circuit system (e.g., Figure 3 The circuit system 310) is used to determine the integrity of the code of the routine (e.g., data 433-1, 433-2, and 433-N) when executed by the memory device 406-1.

[0067] The data 433-1, 433-2, 433-N may be executed in parallel with the ECC 432-1, 432-2, 432-M and / or digests 435-1, 435-2, 435-P to identify errors in the executed code (e.g., data 433-1, 433-2, 433-N). Specifically, the memory device 406-2 may include circuitry (e.g., Figure 3The circuitry 310 of the host controller 421 is configured to read the ECCs (e.g., 432-1, 432-2, and 432-M) stored in the array 401-2 of the memory 416-2 and identify the different memory device 406-1 having the read data 433-1, 433-2, 433-N corresponding to the ECCs (e.g., 432-1, 432-2, and 432M) of the memory 416-2. The circuitry of the memory device 406-2 and / or the host controller 421 may perform an integrity check to compare the ECCs (e.g., 432-1, 432-2, and 432-M) with the read data 433-1, 433-2, and 433-N of the different memory device 406-1. The integrity check may determine and / or monitor errors of the read data 433 - 1 , 433 - 2 , and 433 -N based on comparison with the ECC 432 - 1 , 432 - 2 , and 432 -M.

[0068] In response to the comparison of the read data 433-1, 433-2, 433-N with the ECC 432-1, 432-2, and 432-M, the host controller 421 and / or circuitry may take action, wherein the comparison indicates that the ECC identifies an error in the read data 433-1, 433-2, and / or 433-N of the memory device 406-1. Because correction of the error may introduce new errors into the data to be executed, the host controller 421 and / or circuitry associated with the memory device 406-1 may take action to avoid correcting the error identified by the ECC 432-1, 432-2, and 432-M. Alternatively and / or in addition, the host controller 421 and / or circuitry associated with the memory device 406-1 may determine how errors and / or corrections to errors may affect routines encoded by the data 433-1, 433-2, and 433-N, and determine to correct errors identified by comparing the ECC 432-1, 432-2, and 432-M to the data 433-1, 433-2, 433-N. In this way, unintentional errors introduced by corrective actions may be monitored and / or identified.

[0069] Figure 5 An example flow chart illustrating error identification in executed code according to an embodiment of the present disclosure is provided. A host device (e.g., Figure 3 A host 302 may establish at least one memory device to perform routines for the operation of the host device. The host device may define routines. The host device may securely communicate with one or more memory devices (e.g., Figure 4 The host device and / or circuitry associated with the memory device (e.g., memory devices 406-1 and 406-2) communicate to exchange encrypted data (e.g., data 433-1, 433-2, 433-N) to encode the routine. Figure 3 The circuit system 310 of the embodiment may provide ECC (e.g., ECC 432-1, 432-2, 432-M) for at least one memory device and / or may calculate a digest based on the ECC and / or data (e.g., Figure 4 435-1, 435-2 and 435-P).

[0070] As mentioned, the host device may be a vehicle, and the host controller may be included in the vehicle or external to the vehicle. The host controller may communicate with a plurality of memory devices, which may store data strings encoding important routines of the vehicle (e.g., the host device), such as powertrain operations. The memory devices may be populated with data and corresponding ECCs, and / or may calculate digests at a secure location and / or secure time. For example, the memory devices may be populated with data, ECCs, and digests during manufacture of the host and / or host controller.

[0071] The host device may include a host controller (e.g., Figure 4 The host controller 421 of FIG. 4 is communicatively coupled to the memory device to identify errors in the executed code. The circuitry of the host controller and / or the corresponding memory device can execute the data stream and the corresponding ECC in parallel. For example, the first memory device can be a boot memory device having a memory and a circuitry and communicating with the host controller. The second memory device can be an error correction memory device having a memory and a circuitry and also communicating with the host controller. The system (e.g., Figure 4 The system 409 of the embodiment can be started, and the first memory device can read the data stream of the routine in parallel with the second memory device reading the ECC corresponding to the routine. The first memory device can read the data stream of the routine in parallel with the second memory device reading the ECC corresponding to the routine. Figure 3 The second memory device may transmit the read data to the host controller via the circuit system (e.g., Figure 3 The circuit system 310) transmits the read ECC to the host controller.

[0072] At 518, the host controller may receive executed (e.g., read) data transmitted from the circuitry of the first memory device. At 544, the host controller may receive an ECC from the second memory device, wherein the ECC corresponds to the data from the circuitry of the second memory device (e.g., data read by the first memory device). In some examples, the circuitry of the second memory device may be configured to transmit a calculated digest (e.g., a calculated hash) corresponding to the data stream transmitted by the first memory device. The digest may be transmitted by the circuitry of the second memory device alone or together with the ECC data so that the host device can perform an integrity check.

[0073] For example, at 546, the host controller may compare the received ECC and / or digest corresponding to the data (and calculated by the circuitry of the second memory device) with the read data from the first memory device to determine errors detected by the ECC. At 548, the host controller may determine the integrity of the data read by the first memory based on the comparison of the ECC and the data read by the first memory. If the ECC of the second memory device does not match the read data of the first memory device, then there may be errors in the read data. In other words, the ECC may automatically correct one or more errors so that it no longer corresponds to the data of the first memory device. In this example, at 550, the host controller and / or circuitry associated with the first memory device may take action in response to the comparison of the ECC identifying errors in the read data of the first memory device (e.g., the integrity of the read data).

[0074] In some examples, comparing the read data of the first memory device to the ECC provided by the second memory device includes comparing a hash function corresponding to the data to a digest corresponding to the ECC. The calculated digest may not match the expected read data of the first memory device (e.g., or a hash of the expected read data). Each digest (e.g., Figure 4 435-1, 435-2, 435-P) can be based on data (e.g., Figure 4 The digest may be calculated as 433-1, 433-2, 433-N) of the first memory device, where any change to the data may change the value of the digest. When an error occurs in the data, the digest output by the second memory device may change, thereby indicating an error. At 546, the host controller and / or the circuitry of the first memory device may compare the received digest with the read data. If the digest and the read data do not match, an error has occurred, and the host controller and / or the circuitry of the memory device may take the action at 550.

[0075] For example, the circuitry of the first and / or second memory device may determine where in the routine an error occurred and what effect the error may have on the routine. The circuitry of the first and / or second memory device may suspend (e.g., pause) operation of the host device based on identification of the error by the ECC and / or digest. Alternatively and / or in addition, the host controller may correct the error in the read data based on identification by the ECC and / or digest. In another example, the action taken may be a warning indicating the error, where the warning is generated by the circuitry of the first memory device and / or the second memory device and transmitted to the host device.

[0076] During the integrity check comparison at 546, the host controller and / or the circuitry of the first memory device and / or the second memory device can determine that the read data received from the first memory device matches the ECC and / or digest of the second memory device. Matching read data and ECC and / or digest indicates that there are no errors in the read data from the first memory device. In this example, the circuitry of the first and / or second memory device can continue to operate by the data encoding routine.

[0077] Figure 6 6 is a block diagram of an example system including a memory device 606 and a host 602 according to an embodiment of the present disclosure. The memory device 606 and the host 602 may be, for example, a combination of Figure 3 A host 302 and a memory device 306 are depicted.

[0078] A computing device can be booted in stages using layers, where each layer authenticates and loads subsequent layers and provides increasingly complex runtime services at each layer. One layer can be served by the previous layer and serve subsequent layers, thereby creating an interconnected network of layers that build on lower layers and serve higher layers. Figure 6 , layer 0 ("L0") 651 and layer 1 ("L1") 653 are within the memory device 606. Layer 0 651 can provide a firmware derived secret (FDS) key 652 to layer 1 653. The FDS key 652 can describe the identity of the code of layer 1 653 and other security-related data. In an example, a specific protocol (such as a solid Internet of Things (RIOT) core protocol) can use FDS 652 to verify the code of layer 1 653 that it loads. In an example, the specific protocol can include a device identification combination engine (DICE) and / or a RIOT core protocol. As an example, the FDS can include the layer 1 firmware image itself, a list that cryptographically identifies authorized layer 1 firmware, a firmware version number of the firmware signed in the context of a secure boot implementation, and / or security-critical configuration settings of the device. Device secrets 658 can be used to create FDS 652 and stored in a memory associated with the memory device 606.

[0079] As illustrated by arrow 654, the memory device may transmit data to the host 602. The transmitted data may include a disclosed external identification, a certificate (e.g., an external identification certificate), and / or an external public key. Layer 2 ("L2") 655 of the host 602 may receive the transmitted data and execute the data in operation of an operating system ("OS") 657 and on a first application 659-1 and a second application 659-2.

[0080] In an example operation, the memory device 606 may read the device secret 658, hash the identity of layer 1 653, and perform a calculation including:

[0081] K L1 = KDF [Fs(s), Hash(“unchanging information”)]

[0082] Where K L1 is the external public key, KDF (e.g., the KDF defined in National Institute of Standards and Technology (NIST) Specific Publication 800-108) is a key derivation function (e.g., HMAC-SHA256), and Fs(s) is the device secret 658. FDS 652 may be determined by performing the following calculation:

[0083] FDS = HMAC-SHA256 [ Fs(s), SHA256("unchanged information")]

[0084] Host 602 may transfer data to memory device 606 , as illustrated by arrow 656 .

[0085] Figure 7 is a block diagram of an example process for determining several parameters according to an embodiment of the present disclosure. Figure 7 is an example of determining parameters including an external public identification, an external certificate, and an external public key, as indicated by arrow 754, which are then sent to a host device (e.g., Figure 6 602) of layer 2 (e.g., layer 2 655). Figure 7 Layer 0 ("L0") 751 in corresponds to Figure 6 Layer 0 651 in , and likewise FDS 752 corresponds to FDS 652 , layer 1 753 corresponds to layer 1 653 , and arrows 754 and 756 correspond to arrows 654 and 656 , respectively.

[0086] The FDS 752 from Layer 0 751 is sent to Layer 1 753 and is used by the Asymmetric ID Generator 761 to generate a Public Identification (“ID lk public ”) 765 and private identification 767. In the abbreviation “ID lk public ”, “lk” indicates layer k (layer 1 in this example), and “public” indicates that the identification is publicly shared. The public identification 765 is illustrated as being shared by the arrow extending to the right and beyond layer 1 753 of the memory device. The generated private identification 767 is used as a key input into the encryptor 773. The encryptor 773 can be any processor, computing device, etc. for encrypting data.

[0087] Layer 1 753 of the memory device may include an asymmetric key generator 763. In at least one example, a random number generator (RND) 736 may optionally input a random number into the asymmetric key generator 763. The asymmetric key generator 763 may generate a random number associated with the memory device (e.g., Figure 6 The public key (“K Lk public ”) 769 (called the external public key) and the private key (“K LK private ”) 771 (referred to as an external private key). The external public key 769 may be an input (as “data”) into an encryptor 773. The encryptor 773 may use the input of the external private identification 767 and the external public key 769 to generate a result K′ 775. The external private key 771 and the result K′ 775 may be input to an additional encryptor 777, thereby producing an output K′ 779. The output K′ 779 is transmitted to layer 2 ( Figure 6 655) of the external certificate ("ID L1 The external certificate 781 may provide the ability to verify and / or authenticate the source of data sent from the device. As an example, by verifying the certificate, data sent from the memory device may be associated with the identity of the memory device, such as by combining Fig. 9 Further description. In addition, the external public key (“K L1 public key ”) 783 can be transmitted to Layer 2. Therefore, the public identification 765, certificate 781 and external public key 783 of the memory device can be transmitted to Layer 2 of the host device.

[0088] Figure 8 is a block diagram of an example process for determining several parameters according to an embodiment of the present disclosure. Figure 8 The device identification (“ID L2 866. Device Certificate (“ID L2 Certificate”) 882 and the device public key (“K L2public key ”) 884 host (for example, Figure 6 Layer 2 855 of host 602).

[0089] like Figure 7 As described above, an external public key (“K L1 public key ”) 883 is used by the host’s asymmetric ID generator 862 to generate the host’s public identification (“ID lk public ”) 866 and private identification 868. In the abbreviation “ID lk public”, “lk” indicates layer k (layer 2 in this example), and “public” indicates that the identification is publicly shared. The public identification 866 is illustrated as being shared by the arrow extending to the right and beyond layer 2 855. The generated private identification 868 is used as a key input into the encryptor 874.

[0090] like Figure 8 As shown in FIG. 8 , the certificate verifier 824 uses the external certificate 881 and the external identification 865 and the external public key 883. The certificate verifier 824 can verify the external certificate 881 received by the memory device (e.g., the memory device 606), and determine whether to accept or discard the data received from the memory device in response to the external certificate 881 being verified or not verified. Fig. 9 Describes further details of verifying external certificate 881.

[0091] The host's layer 2 855 may include an asymmetric key generator 864. In at least one example, a random number generator (RND) 838 may optionally input a random number into the asymmetric key generator 864. The asymmetric key generator 864 may generate a random number that is consistent with a host device (e.g., Figure 6 The public key (“K Lk public ”) 870 (referred to as the device public key) and the private key (“K LK private ”) 872 (referred to as the device private key). The device public key 870 may be an input (as “data”) into an encryptor 874. The encryptor 874 may use the input of the device private identification 868 and the device public key 870 to generate a result K′ 876. The device private key 872 and the result K′ 876 may be input to an additional encryptor 878, thereby producing an output K″ 880. The output K″ 880 is transmitted back to layer 1 ( Figure 6 Device Certificate ("ID L2 Device certificate 882 may provide the ability to verify and / or authenticate the source of data sent from the device. As an example, by verifying the certificate, data sent from the host may be associated with the host's identity, such as by combining Fig. 9 Further description. In addition, the device public key (“K L2public key ”) 884 can be transmitted to Layer 1. Therefore, the host's public identification 866, certificate 882 and device public key 884 can be transmitted to Layer 1 of the memory device.

[0092] In an example, in response to the memory device receiving a public key from the host, the memory device may encrypt data to be sent to the host using the device public key. Vice versa, the host may encrypt data to be sent to the memory device using the external public key. In response to the host receiving data encrypted using the device public key, the host may decrypt the data using its own device private key. Likewise, in response to the memory device receiving data encrypted using the external public key, the memory device may decrypt the data using its own external private key. Since the device private key is not shared with another device external to the host, and the external private key is not shared with another device external to the memory device, the data sent to the host and the memory device remains secure.

[0093] Fig. 9 is a block diagram of an example process of verifying a certificate according to an embodiment of the present disclosure. Fig. 9 In the illustrated example, from a memory device (e.g., from Figure 6 Layer 1 653 of the memory device 606 in ) provides an external public key 983, a certificate 981 and a public identification 965. The data of the certificate 981 and the external public key 983 can be used as input to enter the decryptor 985. The decryptor 985 can be any processor, computing device, etc. for decrypting data. The decryption result of the certificate 981 and the external public key 983 can be used together with the public identification as input to enter the secondary decryptor 987, thereby generating an output. As illustrated at 989, the external public key 983 and the output from the decryptor 987 can indicate whether the certificate is verified by comparison, thereby generating a yes or no 991 as an output. In response to the certificate being verified, the data received from the verified device can be accepted, decrypted and / or processed. In response to the certificate not being verified, the data received from the verified device can be discarded, removed and / or ignored. In this way, an illegal device that sends illegal data can be detected and avoided. As an example, a hacker that sends data to be processed can be identified and the hacker data is not processed.

[0094] Fig.10 is a block diagram of an example process for verifying a signature according to an embodiment of the present disclosure. In the case where a device is sending data that can be verified to avoid subsequent repudiation, a signature can be generated and sent with the data. As an example, a first device can make a request to a second device, and once the second device performs the request, the first device can indicate that the first device never made such a request. Anti-repudiation methods, such as using a signature, can avoid repudiation by the first device and ensure that the second device can perform the requested task without subsequent difficulty.

[0095] Memory device 1006 (e.g., Figure 3 The memory device 306 in the embodiment may send data 1090 to the host (e.g., Figure 31094, the memory device 1006 may generate a signature 1096 using the device private key 1071. The signature 1096 may be transmitted to the host 1002. The host 1002 may verify the signature using the previously received data 1092 and the external public key 1069 at 1098. In this way, the signature is generated using the private key and verified using the public key. In this way, the private key used to generate the unique signature may remain private to the device sending the signature while allowing the receiving device to be able to decrypt the signature using the public key of the sending device for verification. This is in contrast to encryption / decryption of data, which is encrypted by the sending device using the public key of the receiving device and decrypted by the receiving device using the private key of the receiver. In at least one example, the device may verify the digital signature by using an internal cryptographic process, such as an elliptic curve digital signature (ECDSA) or similar process.

[0096] Fig.11 1 is a block diagram of an example memory device 1106 according to an embodiment of the present disclosure. The memory device 1106 may be, for example, a memory device 1106 as previously described in conjunction with Figure 3 A memory device 306 is depicted.

[0097] like Fig.11 As shown in FIG. 1 , the memory device 1106 may include a number of memory arrays 1101-1 to 1101-7. The memory arrays 1101-1 to 1101-7 may be similar to those previously described in conjunction with Figure 1 The memory array 101 is described. In addition, Fig.11 In the illustrated example, memory array 1101-3 is a security array, subset 1111 of memory array 1101-6 includes a security array, and subsets 1113 and 1115 of memory array 1101-7 include security arrays. Subsets 1111, 1113, and 1115 may each contain, for example, 4 kilobytes of data. However, embodiments of the present disclosure are not limited to a particular number or arrangement of memory arrays or security arrays.

[0098] like Fig.11 , the memory device 1106 may include a repair (e.g., recovery) block 1117. The repair block 1117 may be used as a data source in the event of an error (e.g., a mismatch) that may occur during operation of the memory device 1106. The repair block 1117 may be located outside of an area of ​​the memory device 1106 that is addressable by the host.

[0099] like Fig.11 , the memory device 1106 may include a serial peripheral interface (SPI) 1104 and a controller 1108. The memory device 1106 may communicate with a host and memory arrays 1101-1 to 1101-7 using the SPI 1104 and the controller 1108, as previously described herein (e.g., in conjunction with Figure 3 ).

[0100] like Fig.11 As shown in FIG. 1 , the memory device 1106 may include a security register 1119 for managing the security of the memory device 1106. For example, the security register 1119 may configure the application controller and communicate externally with the application controller. In addition, the security register 1119 may be modified by an authentication command.

[0101] like Fig.11 , the memory device 1106 may include a key 1121. For example, the memory device 1106 may include eight different slots to store keys, such as a root key, a DICE-RIOT key, and / or other external session keys.

[0102] like Fig.11 , the memory device 1106 may include an electronically erasable programmable read-only memory (EEPROM) 1123. The EEPROM 1123 may provide a secure non-volatile area available to the host where individual bytes of data may be erased and programmed.

[0103] like Fig.11 , memory device 1106 may include a counter (e.g., a monotonic counter) 1125. Counter 1125 may be used as an anti-replay mechanism (e.g., a freshness generator) for commands received from and / or sent to a host (e.g., a signed command set or sequence). For example, memory device 1106 may include six different monotonic counters, two of which may be used by memory device 1106 to authenticate commands, and four of which may be used by the host.

[0104] like Fig.11 , the memory device 1106 may include a SHA-256 cryptographic hash function 1127 and / or an HMAC-SHA256 cryptographic hash function 1129. The memory device 1106 may use the SHA-256 and / or HMAC-SHA256 cryptographic hash functions 1127 and 1129 to generate cryptographic hashes, for example, as previously described herein in conjunction with Figure 3 The cryptographic hash of the described update 220 , and / or the golden hash used to verify the data stored in the memory arrays 1101 - 1 to 1101 - 7 as previously described herein. In addition, the memory device 1106 may support L0 and L1 of the DICE-RIOT 1131 .

[0105] Although specific embodiments have been illustrated and described herein, it will be appreciated by those skilled in the art that arrangements calculated to achieve the same results may replace the specific embodiments shown. The present disclosure is intended to cover modifications or variations of several embodiments of the present disclosure. It should be understood that the above description is provided in an illustrative and non-restrictive manner. Upon reviewing the above description, the combination of the above embodiments and other embodiments not specifically described herein will be apparent to those skilled in the art. The scope of several embodiments of the present disclosure includes other applications in which the above structures and methods are used. Therefore, the scope of several embodiments of the present disclosure should be determined with reference to the attached claims together with the full scope of equivalents authorized by such claims.

[0106] In the foregoing detailed description, some features are grouped together in a single embodiment for the purpose of simplifying the disclosure. This approach to the disclosure should not be interpreted as reflecting an intention that the disclosed embodiments of the disclosure must use more features than those explicitly stated in each claim. In fact, as reflected in the appended claims, the subject matter of the present invention lies in less than all of the features of a single disclosed embodiment. Therefore, the appended claims are hereby incorporated into the detailed description, with each claim standing on its own as a separate embodiment.

Claims

1. An apparatus for error identification in executed code, comprising: Memory; and a circuit system associated with the memory, the circuit system being configured to: reading data stored in a secure array of the memory; identifying a different memory having an error correction code (ECC) corresponding to read data of the memory; performing an integrity check to compare the ECC with the read data of the memory; and An action is taken in response to the comparison of the read data of the memory and the ECC, wherein the comparison indicates that the ECC identifies an error in the read data of the memory.

2. The apparatus of claim 1, wherein the circuitry is further configured to determine that correction applied to the error identified by the ECC introduces additional errors into the ECC.

3. The apparatus of claim 1, wherein the ECC is read by the different memory in parallel with the read data of the memory.

4. The apparatus according to any one of claims 1 to 3, wherein the integrity check is performed by the memory in response to a boot process of the memory.

5. The apparatus of any one of claims 1 to 3, wherein the action taken is to avoid correcting the error in the read data of the memory in response to the error identified by the ECC.

6. The apparatus of any one of claims 1 to 3, wherein the circuitry is further configured to determine whether the error identified by the ECC affects operation of a host device associated with the read data of the memory.

7. The apparatus of any one of claims 1 to 3, wherein the ECC of the different memory and the read data of the memory are associated with a powertrain operation of a host device associated with the memory and the different memory; and Wherein the circuit system is further configured to: generating a warning in response to the ECC identifying the indication of the error in the read data of the memory; and The alert is transmitted to the host device associated with the memory and the different memory.

8. The apparatus of any one of claims 1 to 3, wherein the memory avoids applying correction to the read data of the memory based on the error identified by the ECC of the different memory.

9. An apparatus for error identification in executed code, comprising: Memory; and a circuit system associated with the memory, the circuit system being configured to: Reading an error correction code (ECC) stored in a security array of the memory; identifying a different memory having read data corresponding to the ECC of the memory; performing an integrity check to compare the ECC with the read data of the different memories; and An action is taken in response to the comparison of the read data of the different memory and the ECC of the memory, wherein the comparison indicates that the ECC identifies an error in the read data of the different memory.

10. The apparatus of claim 9, wherein the memory includes the ECC to monitor errors introduced to the read data of the different memory when the data is read by the different memory.

11. The apparatus of claim 9, wherein the memory and the different memory are associated with a host, and wherein when the host is manufactured, the read data is written to the different memory and the ECC is written to the memory.

12. The apparatus according to any one of claims 9 to 11, wherein the read data of the different memory and the ECC of the memory are read at startup of the memory and the different memory.

13. A system for identifying errors in executed code, comprising: Controller; a first memory device in communication with the controller; a second memory device in communication with the controller, the controller being configured to: receiving read data from the first memory device; receiving an error correction code (ECC) corresponding to the read data of the first memory device; performing an integrity check by comparing the read data of the first memory device with the ECC provided by the second memory device; and An action is taken in response to the comparison of the read data of the first memory device and the ECC, wherein the comparison indicates that the ECC identifies an error in the read data of the first memory device.

14. The system of claim 13, wherein the controller is associated with a vehicle and the read data of the first memory device is data associated with powertrain operation of the vehicle.

15. The system of claim 14, wherein operation of the vehicle is stopped in response to the error identified by the ECC.

16. The system of any one of claims 13-15, wherein comparing the read data of the first memory device with the ECC provided by the second memory device includes comparing a hash function corresponding to the data with a digest corresponding to the ECC.

17. The system of any one of claims 13 to 15, wherein the errors identified in the read data of the first memory device are corrected by the controller.

18. A method for error identification in executed code, comprising: receiving read data from a first memory device; receiving an error correction code (ECC) from a second memory device, wherein the ECC corresponds to the read data of the first memory device; comparing the ECC from the second memory device to the read data of the first memory device to determine errors detected by the ECC; determining integrity of the read data of the first memory based on the comparison of the ECC and the read data of the first memory; and An action is taken in response to the determined integrity of the read data of the first memory.

19. The method of claim 18, wherein taking action further comprises: generating, by the first memory device, an alert indicating an error in the read data of the first memory device and identified by the integrity check; and The warning indicative of the identified error is transmitted to a controller in communication with the first memory device.

20. The method of any one of claims 18-19, wherein receiving the read data of the first memory device comprises receiving instructions to execute a routine to operate a powertrain of a host vehicle; and The actions taken further include: receiving, by a controller included in the vehicle, a warning in response to an error identified by the determined integrity; and Powertrain operation of the host vehicle is discontinued by the controller.

Images