阅读说明：本技术 所执行代码中的错误识别 (Error identification in executed code ) 是由 A·蒙代洛 A·特罗亚 于 2020-03-12 设计创作，主要内容包括：本公开包含用于对所执行代码进行错误识别的设备、方法和系统。实施例包含存储器和电路系统,所述电路系统配置成：读取存储在所述存储器的安全阵列中的数据；识别具有对应于所述存储器的读取数据的错误校正码(ECC)的不同存储器；执行完整性检查以将所述ECC与所述存储器的所述读取数据进行比较；和响应于所述存储器的所述读取数据与所述ECC的所述比较而采取动作,其中所述比较指示所述ECC识别所述存储器的所述读取数据中的错误。(The present disclosure includes apparatus, methods, and systems for error recognition of executed code. An embodiment includes a memory and circuitry 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 to the read data of the memory; and taking an action in response to the comparison of the read data of the memory to the ECC, wherein the comparison indicates that the ECC identifies an error in the read data of the memory.)

1. An apparatus, comprising:

a memory; and

circuitry associated with the memory, the circuitry 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 to the read data of the memory; and

taking an action in response to the comparison of the read data of the memory to 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 a correction applied to the error identified by the ECC introduces additional errors to 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 of any of claims 1-3, wherein the integrity check is performed by the memory in response to a boot process of the memory.

5. The apparatus of any of claims 1-3, wherein the action taken is to refrain from 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-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 of claims 1-3, wherein the ECC of the different memory and the read data of the memory are associated with powertrain operation of a host device associated with the memory and the different memory; and is

Wherein the circuitry is further configured to:

generating an alert in response to the indication that the ECC identifies the error in the read data of the memory; and

transmitting the alert to the host device associated with the memory and the different memory.

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

9. An apparatus, comprising:

a memory; and

circuitry associated with the memory, the circuitry configured to:

reading an Error Correction Code (ECC) stored in a secure 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 memory; and

taking an action in response to the comparison of the read data of the different memory to 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 the read data is written to the different memory and the ECC is written to the memory when the host is manufactured.

12. The apparatus of any of claims 9-11, wherein the read data of the different memory and the ECC of the memory are read at the boot-up of the memory and the different memory.

13. A system, comprising:

a controller;

a first memory device in communication with the controller;

a second memory device in communication with the controller, the controller 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 to the ECC provided by the second memory device; and

Taking an action in response to the comparison of the read data of the first memory device to 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 stops 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 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.

17. The system of any one of claims 13-15, wherein the error identified in the read data of the first memory device is corrected by the controller.

18. A method, comprising:

receiving read data of 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 to the read data of the second memory device and the first memory device to determine errors detected by the ECC;

determining an integrity of the read data of the first memory based on the comparison of the ECC to the read data of the first memory; and

taking an action 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 indicative of an error in the read data of the first memory device and identified by the integrity check; and

transmitting the warning indicative of the identified error to a controller in communication with the first memory device.

20. The method of any of claims 18-19, wherein receiving the read data of the first memory device includes receiving an instruction to execute a routine to operate a powertrain of a host vehicle; and is

Wherein taking action further comprises:

receiving, by a controller included in the vehicle, an alert in response to an error identified by the determined integrity; and

suspending, by the controller, the powertrain operation of the host vehicle.

Technical Field

The present disclosure relates generally to semiconductor memory and methods, and more particularly to identifying errors in executed code.

Background

Memory devices are typically provided as internal semiconductor integrated circuits and/or as 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 can provide persistent data by preserving stored data when not powered, and can 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.

The memory devices may be combined together to form a Solid State Drive (SSD), an embedded multimedia card (e.g., MMC), and/or a Universal Flash Storage (UFS) device. The SSD, e.mmc 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 telephones, portable music players, such as MP3 players, movie players, and the like.

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

The memory cells can be arranged in an array, and the 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., floating gate) of a flash memory cell to program the cell to a particular data state. The stored charge on the charge storage structure of the cell may be indicative of 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 its charge storage structure.

Errors introduced into the code and threats placed 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. The threats may include, for example, threats from hackers or other malicious users, including intentional false introductions, man-in-the-middle (MITM) attacks, and so forth. Such threats may cause significant financial loss, and/or may cause significant security and/or safety issues.

Drawings

FIG. 1 illustrates a diagram of a portion of a memory array having a number of physical blocks in accordance with an embodiment of the present disclosure.

FIG. 2A illustrates an example of a pair of registers used to define a secure memory array, according to an embodiment of the present disclosure.

Figure 2B illustrates a diagram of a portion of a memory array including a defined secure memory array, in accordance with an embodiment of the present disclosure.

FIG. 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 disclosure.

Fig. 4 illustrates an example block diagram of an example system including a host controller and an apparatus, according to an embodiment of this disclosure.

FIG. 5 illustrates an example flow diagram for error identification in executed code according to an embodiment of this disclosure.

FIG. 6 is a block diagram of an example system including a host and a memory device, according to an embodiment of the disclosure.

Fig. 7 is a block diagram of an example process for determining several parameters in accordance with an embodiment of the present disclosure.

Fig. 8 is a block diagram of an example process for determining several parameters in accordance with an embodiment of the present disclosure.

Fig. 9 is a block diagram of an example process of verifying a certificate according to an embodiment of the disclosure.

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

FIG. 11 is a block diagram of an example memory device, according to an embodiment of the disclosure.

Detailed Description

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

The memory device may be used to store data in the computing system, and such data may be transferred 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 operation of the powertrain or the vehicle. Memory devices may be used as non-volatile memory for a wide range of electronic applications.

A host may be communicatively coupled to a plurality of memory devices. In one example, a memory device may include data stored in a secure 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. Integrity check refers to a comparison of error correction data to read data. For example, the circuitry may be configured to perform an integrity check to compare the ECC to read data of the memory device, and to take an action in response to the comparison of the read data to the ECC. When ECC indicates correction, the data read by the memory device may include similar errors, and corrective action may be taken to correct the errors.

Errors (e.g., faults) may be introduced into data stored by a memory device (e.g., data stored in memory cells) in a variety of ways. During transmission, errors may be inadvertently introduced into the code through noise and/or impairments. In some cases, errors may be inadvertently introduced to data stored in memory, causing changes in the operation of the memory. Errors may also be intentionally introduced into data stored by memory by threat. For example, a hacker or other malicious user may introduce errors in an attempt to perform an activity (e.g., an attack), such as a man-in-the-middle (MITM) attack, to make unauthorized changes to the operation of memory and/or to the data stored therein for malicious purposes. Another example of a threat and/or consequence to errors 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 to as a check and/or a security protocol to authenticate the command.

During such an attack and/or error, the routine is skipped and/or altered, but the host may receive an indication that the routine has executed. In other words, a hacker and/or error may tamper with the command and cause the host to receive an indication that the routine has executed. Important routines written to check the authenticity of a command (authenticate components, authenticate software versions and/or updates, user identification, etc.) may be designed to execute during boot-up (e.g., booting) of the memory device. A hacker and/or an introduced error may change (e.g., mask) the external input to trigger a condition so that a routine written to verify the authenticity of the command may be skipped. One example of such a routine may be part of executable code written to check the authenticity of the payment prior to executing a software service (e.g., issuing money and/or transferring data from an automated teller machine, executing software, etc.). Other examples may include routines for verifying software licenses to authenticate the software as genuine prior to execution (computer system updates, installation of software, etc.), critical operating routines of the host device (e.g., startup operations, powertrain operations, etc.), and/or routines for checking the authenticity of system components and configuration of system components (e.g., process plant control, automotive components).

Detection and correction of errors can be challenging, as correction of detected errors can produce additional (e.g., new) errors. This may cause unreliability in the resulting architecture (e.g., routine) of the code 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 the data. An ECC may be associated with a group of cells, such as a memory block, memory segment, or memory sector, and may save read failures by detecting and possibly correcting bit errors. Examples of ECC codes include Hamming codes (Hamming codes), Reed-Solomon (RS) codes, Bose-Chaudhuri-Hochquenghem (BCH) codes, Cyclic Redundancy Check (CRC) codes, gray (Golay) codes, Reed-Muller (Reed-Muller) codes, gopa (Goppa) codes, danniston (denriston) codes, and so forth. In some approaches, these and other error checking techniques are performed on a memory device by a controller that includes circuitry coupled to the memory device. As mentioned, when an error is identified and corrected, the ECC may inadvertently introduce a new error to an important routine (e.g., a command).

Thus, to ensure that errors indicated by the ECC are identified, but that no new errors are introduced when the identified errors are corrected, a warning may be generated when such errors are detected. The 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 a plurality of memory devices (e.g., ECC memory devices and ECC-free memory devices). Multiple memory devices may be provided with data (e.g., commands and/or routines) and/or ECCs corresponding to the data, respectively.

In some examples, the ECC and corresponding routines may be securely provided onto the memory device during the manufacturing phase and/or securely verified using the exchanged public/private key (discussed further herein). An ECC memory device including an ECC and a memory device including 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 the 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, data executed by the data memory device may be identified as including a potential error. In other words, because the data in the memory device corresponds to the ECC in another memory device, the errors identified by the ECC indicate errors in the data of the memory device. In this case, to avoid inadvertent errors introduced by implementing automatic correction, action 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, a number of decisions may be made regarding how to correct the error without altering the architecture of the important routines.

Embodiments of the present disclosure may utilize cryptographic primitive solutions (e.g., ECC and or computed digest) in important routines for error detection in conjunction with comparisons of ECC and data performed in parallel by different memory devices communicatively coupled to a host device. Such solutions may identify errors that have been inadvertently and/or intentionally introduced to the code. This may prevent bad operations written to important routines that avoid financial loss, security protocols, and/or provide security checks on the operation of the host device. Furthermore, when an error is identified, the introduction of a new error can be avoided by avoiding automatic correction. Alternatively, an action (e.g., an alert, alarm, and/or abort of a routine) may be determined by the host and/or a memory device associated with the host.

As used herein, "a" or "an" may refer to one or more of something, and "a plurality" 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. Additionally, the designators "M," "P," "R," "B," "S," and "N," as used herein, particularly with respect to reference numerals in the drawings, indicate that several particular features so designated may be included with several embodiments of the present disclosure. The numbers between designations may be the same or different.

The figures herein follow a numbering convention in which the first one or more digits correspond to the drawing figure number and the remaining digits identify an element or component in the drawing. Similar elements or components between different figures may be identified by the use of similar digits. For example, 101 may represent element "01" in fig. 1, and a similar element may be represented as 201 in fig. 2.

FIG. 1 illustrates a diagram of a portion of a memory array 101 having a number of physical blocks in accordance with an embodiment of the present disclosure. The memory array 101 may be, for example, a flash memory array, such as a NAND flash memory array. As additional examples, the memory array 101 may be a resistance variable memory array, such as a PCRAM, RRAM, MMRAM, or Spin Torque Transfer (STT) array, among others. However, embodiments of the present disclosure are not limited to a particular type of memory array. Moreover, memory array 101 (e.g., a subset of array 101 or the entire array 201) may be a secure memory array, as will be further described herein. Further, although not shown in FIG. 1, the memory array 101 may be located on a particular semiconductor die with various peripheral circuitry associated with its operation.

As shown in FIG. 1, the 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 four-level cells (QLC). As examples, the number of physical blocks in the memory array 101 may be 128 blocks, 512 blocks, or 1,024 blocks, but embodiments are not limited to a particular power of two or any particular number of physical blocks in the memory array 101.

A number of physical blocks of memory cells (e.g., blocks 107-0, 107-1, … …, 107-B) may be included in a plane of memory cells, and a number of planes of memory cells may be included on a die. For example, in the example shown in FIG. 1, each physical block 107-0, 107-1, … …, 107-B may be part of a single die. That is, the portion of memory array 101 illustrated in FIG. 1 may be a die of memory cells.

As shown in FIG. 1, 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 may be 32, but embodiments are not limited to a particular number of rows 103-0, 103-1, … …, 103-R per physical block. Further, although not shown in FIG. 1, the memory cells can be coupled to columns of sense lines (e.g., data lines and/or digit lines).

As will be appreciated by those skilled in the art, each row 103-0, 103-1, … …, 103-R may include a number of pages (e.g., physical pages) of memory cells. A physical page refers to a cell that is programmed and/or sensed (e.g., a number of memory cells that are programmed and/or sensed together as a functional group). In the embodiment shown in FIG. 1, each row 103-0, 103-1, … …, 103-R includes one physical page of memory cells. However, 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 pages of memory cells coupled to even-numbered data lines, and one or more odd pages of memory cells coupled to odd-numbered data lines). Additionally, for embodiments including multi-level cells, a physical page of memory cells may store multiple pages (e.g., logical pages) of data (e.g., an upper page of data and a lower page of data, with each cell in the physical page storing one or more bits toward the upper page of data and one or more bits toward the lower page of data).

As shown in FIG. 1, 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 several 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 the 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.

Logical block addressing is a scheme that a host can use to identify logical sectors of data. For example, each logical sector may correspond to a unique Logical Block Address (LBA). In addition, the LBAs may also correspond to (e.g., dynamically map to) physical addresses, such as Physical Block Addresses (PBAs), that may indicate the physical orientation of logical sectors 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.

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.

FIG. 2A illustrates an example of a pair of registers 214-1 and 214-2 used to define a secure memory array in accordance with an embodiment of the disclosure, and FIG. 2B illustrates a diagram of a portion of a memory array 201 containing a secure memory array defined using registers 214-1 and 214-2 in accordance with an embodiment of the disclosure. Although embodiments are not so limited and one or more registers and/or one or more pairs of registers may be used. As shown in FIG. 2B, in a manner similar to memory array 101 described in connection with FIG. 1, 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 sectors of memory cells.

As illustrated in fig. 2A, register 214-1 may define an address of a secure array (e.g., an address of a different portion of the secure array), and register 214-2 may define a size of the secure array (e.g., a size of a different portion of the secure array). The address of the secure array defined by register 214-1 may correspond to, for example, a starting point (e.g., a starting LBA) of the secure array (e.g., a starting point of a different portion of the secure array), and the size of the secure array defined by register 214-2 may correspond to, for example, an ending point (e.g., an ending LBA) of the secure array (e.g., an ending point of a different portion of the secure array).

For example, as shown in FIG. 2A, registers 214-1 and 214-2 may define N pairs of values, with each respective pair including an address value (e.g., addr) defined by register 214-1 and a size value (e.g., size) defined by register 214-2. For example, in the example illustrated in fig. 2A, Pair₀Including the address value addr₀And size value size₀(e.g., Pair₀＝[addr₀,size₀])，Pair₁Including the address value addr₁And size value size₁(e.g., Pair₁＝[addr₁,size₁]) Etc., wherein Pair_NIncluding the address value addr_NAnd size value size_N(e.g., Pair_N＝[addr_N,size_N]). The address value of a pair may correspond to a starting point (e.g., a starting LBA) of a portion of the secure array, and a sum of the address value and the size value of the pair may correspond to an ending point (e.g., an ending LBA) of the portion of the secure array. Thus, the entire security array (e.g., including portions of the entire security array) may be given by the following equation: [ addr ₀,addr₀+size₀]∪[addr₁,addr₁+size₁]∪…∪[addr_N,addr_N+size_N]。

The first pair of stoppable secure arrays whose size value defined by register 214-2 is zero. For example, in the example illustrated in FIG. 2A, if Pair₂Is zero, the security array will be given by the following equation: [ addr₀,addr₀+size₀]∪[addr₁,addr₁+size₁]。

An example of a security array defined by registers 214-1 and 214-2 is illustrated in FIG. 2B (e.g., all size values defined by register 214-2 are non-zero). For example, as shown in FIG. 2B, the address (e.g., LBA) associated with sector 205-0 of memory array 201 is addr₀The address associated with sector 205-1 of memory array 201 is addr₀+size₀The address associated with sector 205-2 of memory array 201 is addr₁The address associated with sector 205-3 of memory array 201 is addr₁+size₁The address associated with sector 205-4 of memory array 201 is addr_NAnd the address associated with sector 205-5 of memory array 201 is addr_N+size_N. Thus, the secure array includes sectors (e.g., data stored in sectors) 205-0 through 205-1, sectors 205-2 through 205-3, and sectors 205-4 through 205-5. However, the sectors of memory array 201 that precede sector 205-0 and sectors 205-1 through 205-2 of memory array 201 are not part of the security array (e.g., the security array includes a subset of array 201).

Fig. 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 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 circuitry, one or more dies, one or more modules, one or more devices, or one or more systems. Further, in an embodiment, computing system 300 may include several memory devices similar to memory device 306.

In the embodiment illustrated in FIG. 3, memory device 306 may include a memory 316 having a memory array 301. The memory array 301 may be similar to the memory array 101 described in connection with FIG. 1 and the memory array 201 described in connection with FIG. 2B. Further, in an embodiment, memory array 301 (e.g., a subset of array 301, or the entire array 301) may be a secure array (e.g., an area of memory 316 that is to remain controlled).

FIG. 3 illustrates a pair of registers 314-1 and 314-2, but embodiments are not so limited 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, registers 214-1 and 214-2 described in conjunction with FIG. 2A, and secure memory array 301 may be, for example, memory array 201 described in conjunction with FIG. 2B. Data (e.g., data 333) stored in the memory array 301 may include sensitive (e.g., non-user) data, such as device firmware and/or code to be executed for a sensitive application (e.g., routine). In some examples, memory device 306 may include an ECC corresponding to data 333, where the ECC and/or a digest of the data calculated by memory device 306 are stored by memory 316 in the same manner as data 333 illustrated in fig. 3 (this embodiment is discussed in connection with fig. 4).

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

As illustrated in FIG. 3, a host 302 may be coupled to a memory device 306 via an interface 304. The host 302 and the memory device 306 may communicate (e.g., send commands and/or data) over the interface 304. Host 302 and/or memory device 306 may be or be part of: computing devices, laptops, personal computers, digital cameras, digital recording and playback devices, mobile phones, PDAs, memory card readers, interface hubs, or internet of things (IoT) enabled devices, such as automotive (e.g., vehicle and/or transportation infrastructure) IoT enabled devices or medical (e.g., implantable and/or health monitoring) IoT enabled devices, as well as other host systems, and may include memory access devices (e.g., processors). 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.

The interface 304 may be in the form of a standardized physical interface. For example, when memory device 306 is used for information storage in computing system 300, 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. In general, however, 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.

The memory device 306 includes a controller 308 in communication with a host 302 and a memory 316 (e.g., memory array 301). For example, the controller 308 may 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.

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).

The host 302 may include a host controller 321 in communication with the memory device 306. The host controller 321 may be included on the same physical host device 302. Alternatively, the host controller 321 may be a separate physical device communicatively coupled to the memory device 306 and/or a plurality of memory devices (discussed further in connection with FIG. 4). The host controller 321 may send commands to the memory device 306 via the interface 304. Host controller 321 may communicate with memory device 306 and/or controller 308 on memory device 306 to read, write, and/or erase data, among other operations. Further, in embodiments, host 302 may be an IoT-enabled device with IoT communication capabilities as described herein.

Controller 308 on memory device 306 and/or host controller 321 on host 302 may include control circuitry and/or logic (e.g., hardware and firmware). In an embodiment, controller 308 and/or host controller 321 on memory device 306 may be an Application Specific Integrated Circuit (ASIC) coupled to a printed circuit board including a physical interface. Further, 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).

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

Computing system 300 (e.g., host 302 and memory device 306) may utilize the identification of errors in executed code to determine whether an error has been identified in data 333. For example, the circuitry 310 may read data 333 stored in the array 301 of the memory 316. Circuitry 310 may identify a different memory that may contain an ECC corresponding to data 333 read by circuitry 310. As mentioned, automatic correction of errors introduced to data 333 may introduce additional errors. Memory device 306 may perform an integrity check to compare the ECC to data 333 read by memory device 306. Memory device 306 may take action in response to a comparison of read data of memory 316 to an ECC, where the comparison indicates that the ECC identifies an error in data 333 read by memory 316. In this way, the memory device 306, the host controller 321, and/or the host 302 can determine how to correct the errors identified by the ECC.

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

The host controller 321, circuitry 310, and/or memory 316 may perform integrity checks 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, circuitry 310, and/or 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 a determination by circuitry 310 and/or host 302 that the correction applied to the error identified by the ECC introduces additional errors to the ECC. In other words, automatic correction of the identified errors by the ECC may have introduced new errors to the ECC, and applying similar correction to the data 333 may introduce additional error data 333. The introduction of other errors may cause routines to be skipped, altered, and/or otherwise operationally problematic. Based on the integrity check, the host 302, host controller 321, and/or circuitry 310 may take action in response to the error identified by the ECC to avoid correcting the error corresponding to the read data 333 of the memory, and/or may determine an alternative correction method.

FIG. 4 illustrates a block diagram of an example system 409 including a host controller 421 and example memory devices 406-1 and 406-2, according to an embodiment of the disclosure. A host (e.g., host 302 of fig. 3) may include host controller 421, where 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, the system 409 illustrated in FIG. 4 includes a host controller 421 communicatively coupled via an interface 404-1 to a memory device 406-1 having a memory 416-1 and an array 401-1. The host controller 421 is illustrated as being communicatively coupled to another memory device 406-2 having memory 416-2 and an array 401-2 via an interface 404-2.

Memory device 406-1 may be provided with data 433-1, 433-2, and 433-N (e.g., data 333 of FIG. 3). The data 433-1, 433-2, and 433-N may be code streams corresponding to routines. Data 433-1, 433-2, and 433-N encodings for routines may be securely provided onto the memory device 406-1 using public/private key exchanges between a host associated with the host controller 421 and the memory device 406-1. ECCs 432-1, 432-2, and 432-M may correspond to data 433-1, 433-2, and 433-N, and are securely provided onto memory device 406-2 using a public/private key exchange between a host associated with host controller 421 and memory device 406-1. The generation and verification of public and private keys will be discussed further in connection with fig. 6-11.

In some examples, the data 433-1, 433-2, and 433-N that make up the codestream for the routine may be fixed units of data (e.g., 5 to 8 doublewords, but examples are not so limited). The routines may be runtime executable code that may be important to the operation of the host corresponding to the host controller 421. 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 provided with routines (e.g., a code stream for routines encoded in the data 433-1, 433-2, 433-N) and error correction/detection capabilities.

For example, the memory device 406-2 may include ECCs 432-1, 432-2, 432-M corresponding to routines and/or digests 435-1, 435-2, 435-P corresponding to routines. ECCs 432-1, 432-2, 432-M may include codes corresponding to data 433-1, 433-2, and 433-N of memory device 406-1, where the ECCs are concatenated bit parities therewith. For example, ECC 432-1 may include code for data 433-1 concatenated with an error correction portion, ECC 432-2 may include code for data 433-2 concatenated with an error correction portion, and ECC 432-M may include code for data 433-N concatenated with an error correction portion.

Digests 435-1, 435-2, and 435-P are products of hash functions applied by circuitry (e.g., circuitry 310 of fig. 3) to code (e.g., data 433-1, 433-2, 433-N) for a routine. For example, digests 435-1, 435-2, and 435-P may be cryptographic primitives (e.g., hashes) generated by corresponding data (e.g., data 433-1, 433-2, 433-N), where changes to the data may result in different digests. In other words, when there is an error in the data 433-1, the digest computed by the circuitry of the data 433-1 will change.

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 separately or together, may be used by a host (e.g., host 302 of FIG. 3), host controller 421, and/or circuitry (e.g., circuitry 310 of FIG. 3) to determine the integrity of the code (e.g., data 433-1, 433-2, and 433-N) of the routine in execution by the memory device 406-1.

The data 433-1, 433-2, 433-N may be executed in parallel with the ECCs 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., circuitry 310 of FIG. 3) configured to read ECCs (e.g., 432-1, 432-2, and 432-M) stored in the array 401-2 of the memory 416-2 and identify different memory devices 406-1 having 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 ECC (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 read data 433-1, 433-2, and 433-N for errors based on a comparison with ECCs 432-1, 432-2, and 432-M.

In response to a comparison of the read data 433-1, 433-2, 433-N to the ECCs 432-1, 432-2, and 432-M, which 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, the host controller 421 and/or circuitry may take action. Because correction of errors may introduce new errors into the data to be performed, the host controller 421 and/or circuitry associated with the memory device 406-1 may take action to avoid correcting errors identified by the ECCs 432-1, 432-2, and 432-M. Alternatively and/or additionally, 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 the routines encoded by the data 433-1, 433-2, and 433-N, and determine to correct errors identified by comparing the ECCs 432-1, 432-2, and 432-M with the data 433-1, 433-2, 433-N. In this manner, inadvertent errors introduced by the corrective action may be monitored and/or identified.

FIG. 5 illustrates an example flow diagram for error identification in executed code according to an embodiment of this disclosure. At 522, a host device (e.g., host 302 of fig. 3) can establish at least one memory device to perform routines for operation of the host device. For example, at 541, the host device may define a routine. The host device may securely communicate with one or more memory devices (e.g., memory devices 406-1 and 406-2 of fig. 4) by exchanging public/private keys to exchange encrypted data (e.g., data 433-1, 433-2, 433-N) to encode the routine. The host device and/or circuitry associated with the memory device (e.g., circuitry 310 of FIG. 3) may provide an ECC (e.g., ECC 432-1, 432-2, 432-M) for at least one memory device and/or may calculate a digest (e.g., 435-1, 435-2, and 435-P of FIG. 4) based on the ECC and/or data.

As mentioned, the host device may be a vehicle, and the host controller may be contained in or external to the vehicle. The host controller may communicate with a plurality of memory devices, which may store data strings encoding important routines (e.g., powertrain operation) of the vehicle (e.g., host device). The memory device may be provided with data and corresponding ECC and/or the digest may be calculated at a secure location and/or a secure time. For example, a memory device may be provided with data, ECC, and digest during manufacture of the host and/or host controller.

The host device may include a host controller (e.g., host controller 421 of fig. 4) communicatively coupled to the memory device to identify errors in executed code. At 542, the host controller and/or circuitry of the respective memory device may execute the data stream and the corresponding ECC in parallel. For example, the first memory device may be a boot memory device having memory and circuitry and communicating with a host controller. The second memory device may be an error correction memory device having memory and circuitry and also in communication with the host controller. A system (e.g., system 409 of fig. 4) may start up and a first memory device may read a data stream of a routine in parallel with a second memory device reading an ECC corresponding to the routine. The first memory device may transmit read data to the host controller via circuitry (e.g., circuitry 310 of fig. 3). The second memory device may transmit the read ECC to the host controller via circuitry (e.g., circuitry 310 of fig. 3).

At 543, the host controller can receive the executed (e.g., read) data transferred from the circuitry of the first memory device and the ECC corresponding to the data from the circuitry of the second memory device. In some examples, circuitry of the second memory device may be configured to transmit a computed digest (e.g., a computed hash) corresponding to a data stream transmitted by the first memory device. The digest may be transmitted by the circuitry of the second memory device, either alone or with the ECC data, so that the host device may perform an integrity check.

For example, at 544, the host controller may perform an integrity check by comparing the received ECC and/or a digest corresponding to the data (and computed by circuitry of the second memory device) with the read data from the first memory device. If the ECC of the second memory device does not match the read data of the first memory device ("NO" of 545), then there may be an error in the read data. In other words, the ECC may automatically correct one or more errors, thereby no longer corresponding to the data of the first memory device. In this example, at 547, the host controller and/or circuitry associated with the first memory device can take action in response to a comparison that the ECC identifies an error in the read data of the first memory device.

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 computed digest may not match the expected read data (e.g., or a hash of the expected read data) of the first memory device. Each digest (e.g., 435-1, 435-2, 435-P of FIG. 4) may be computed based on data (e.g., 433-1, 433-2, 433-N of FIG. 4), 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, indicating the error. At 544, the host controller and/or circuitry of the first memory device may compare the received digest to the read data. If the digest and the read data do not match (e.g., "NO" of 546), an error has occurred and the host controller and/or the circuitry of the memory device can take action at 547.

For example, circuitry of the first and/or second memory devices may determine where in the routine the error occurred, and determine what impact the error may have on the routine. Circuitry of the first and/or second memory devices may suspend (e.g., pause) operation of the host device based on the identification of the error by the ECC and/or digest. Alternatively and/or additionally, the host controller may correct errors in the read data based on the identification by the ECC and/or the digest. In another example, the action taken may be an alert indicating an error, where the alert is generated by circuitry of the first memory device and/or the second memory device and communicated to the host device.

During the integrity check comparison at 544, the host controller and/or circuitry of the first memory device and/or the second memory device may determine that the read data received from the first memory device matches the ECC and/or digest of the second memory device ("yes" at 548). Matching the read data with the ECC and/or digest indicates that there are no errors in the read data from the first memory device. In this example, at 549 circuitry of the first and/or second memory devices may proceed with operations by the data encoding routine.

FIG. 6 is a block diagram of an example system including a memory device 606 and a host 602, according to an embodiment of the disclosure. Memory device 606 and host 602 may be host 302 and memory device 306, respectively, such as described in connection with fig. 3.

The computing device may boot in stages at the usage layer, with each layer authenticating and loading subsequent layers and providing increasingly complex runtime services at each layer. One layer may be served by a previous layer and serve subsequent layers, creating an interconnection network of layers built on a lower layer and serving higher-level layers. As illustrated in FIG. 6, layer 0 ("L₀") 651 and layer 1 (" L ₁") 653 within the memory device 606. Layer 0651 may provide a Firmware Derived Secret (FDS) key 652 to layer 1653. FDS key 652 may describe the identity of the code of layer 1653 and other security-related data. In an example, a particular protocol, such as the firm internet of things (RIOT) core protocol, may use the FDS 652 to verify the code of the layer 1653 that it loads. In an example, the particular protocol may include a Device Identification Combining Engine (DICE) and/or a RIOT core protocol. As an example, the FDS may include the layer 1 firmware image itself, a manifest that cryptographically identifies authorized layer 1 firmware, a firmware version number of firmware that is signed in the context of a secure boot implementation, and/or a security critical configuration setting of the device. The device secret 658 may be used to create the FDS 652 and stored in a memory associated with the memory device 606.

The memory device may transmit data to the host 602 as illustrated by arrow 654. The transmitted data may include public external identification, certificates (e.g., external identification certificates), and/or external public keys. Layer 2 ("L") of host 602₂") 655 may receive the transmitted data and execute the data in operation of an operating system (" OS ") 657 and on the first application 659-1 and the second application 659-2.

In an example operation, the memory device 606 may read the device secret 658, hash the identity of the layer 1653, and perform a calculation that includes:

K_L1KDF [ fs(s); hash () "Invariable information')]

Wherein K_L1Is an external public key, KDF (e.g., 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 a device secret 658. The FDS 652 may be determined by performing the following calculations:

FDS HMAC-SHA256[ fs(s), SHA256 ("invariant information") ]

Host 602 may transfer data to memory device 606 as illustrated by arrow 656.

Fig. 7 is a block diagram of an example process for determining several parameters in accordance with an embodiment of the present disclosure. Fig. 7 is an example of determining parameters including an external public identity, an external certificate, and an external public key, which are then sent to layer 2 (e.g., layer 2655) of a host device (e.g., 602 in fig. 6), as shown by arrow 754. Layer 0 ("L") in FIG. 7₀") 751 corresponds to tier 0651 in fig. 6, and likewise FDS 752 corresponds to FDS 652, tier 1753 corresponds to tier 1653, and arrows 754 and 756 correspond to arrows 654 and 656, respectively.

FDS 752 from layer 0751 is sent to layer 1753 and used by asymmetric ID generator 761 to generate a common identification ("ID_{lk public}") 765 and private identity 767. In the abbreviation "ID_{lk public}"in," lk "indicates layer k (layer 1 in this example), and" public "indicates that the identification is publicly shared. The common identification 765 is illustrated as shared by the arrow extending to the right and out of the layer 1753 of the memory device. The generated private identification 767 is used as a key input into the encryptor 773. Encryptor 773 may be any processor, computing device, etc. for encrypting data.

The layer 1753 of the memory device can include an asymmetric key generator 763. In at least one example, random number generator (RND)736 can optionally input a random number into asymmetric key generator 763. Asymmetric key generator 763 may generate a public key ("K") associated with a memory device (e.g., memory device 606 in FIG. 6)_{Lk public}") 769 (referred to as the external public key) and a private key (" K_{LK private}”)771 (referred to as the external private key). The external public key 769 may be the input (as "data") into the encryptor 773. The encryptor 773 may generate the result K'775 using the input of the external private identification 767 and the external public key 769. The external private key 771 and the result K'775 may be input to the extra encryptor 777, producing the output K "779. The output K "779 is the external certificate (" ID ") transmitted to layer 2 (655 of FIG. 6) _L1Certificate ") 781. 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, the data sent from the memory device may be associated with an identity of the memory device, as will be further described in connection with fig. 9. In addition, an external public key ("K)_{L1 public key}") 783 may be transmitted to layer 2. Thus, the public identity 765, certificate 781 and external public key 783 of the memory device may be transmitted to layer 2 of the host device.

Fig. 8 is a block diagram of an example process for determining several parameters in accordance with an embodiment of the present disclosure. FIG. 8 illustrates generating a device identification ("ID)_L2Public ") 866, device certificate (" ID ")_L2Certificate ") 882 and device public key (" K ″)_{L2 public key}") 884 (e.g., host 602 in FIG. 6).

As depicted in FIG. 7, the external public key ("K") is transferred from layer 1 of the memory device to layer 2855 of the host_{L1 public key}") 883 is used by the asymmetric ID generator 862 of the host to generate a common identification (" ID ") of the host_{lk public}") 866 and private identification 868. In the abbreviation "ID_{lk public}"in," lk "indicates layer k (layer 2 in this example), and" public "indicates that the identification is publicly shared. Public identity 866 is illustrated as shared by the arrow extending to the right and out of layer 2855. The generated private identification 868 is used as a key input into encryptor 874.

As shown in fig. 8, the certificate verifier 824 uses an external certificate 881 and an external identification 865, and an external public key 883. The credential verifier 824 may verify an external credential 881 received by a memory device (e.g., the memory device 606) and determine whether to accept or discard data received from the memory device in response to the external credential 881 being verified or unverified. Further details of verifying external certificate 881 are described in connection with fig. 9.

The layer 2855 of the host may contain 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 public key ("K") associated with a host device (e.g., host 602 in fig. 6)_{Lk public}") 870 (referred to as the device public key) and a private key (" K_{LK private}") 872 (referred to as the device private key). The device 870 may be an input (as "data") into the encryptor 874. The encryptor 874 may use the device private identification 868 and the input of the device public key 870 to generate the result K' 876. The device private key 872 and the result K'876 can be input to an additional encryptor 878, producing an output K "880. The output K "880 is the device certificate (" ID ") that is transmitted back to layer 1 (653 of FIG. 6) _L2Certificate ") 882. The 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, the data sent from the host may be associated with an identity of the host, as will be further described in connection with fig. 9. In addition, the device public key ("K)_{L2 public key}") 884 may be transmitted to layer 1. Thus, the public identity 866 of the host, the certificate 882, and the device public key 884 may be transmitted to layer 1 of the memory device.

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, data sent to the host and the memory device remains secure.

Fig. 9 is a block diagram of an example process of verifying a certificate according to an embodiment of the disclosure. In the illustrated example of fig. 9, public key 983, certificate 981, and public identification 965 are provided from a memory device (e.g., from layer 1653 of memory device 606 in fig. 6). The data of the certificate 981 and the external public key 983 may be used as input into the decryptor 985. Decryptor 985 may be any processor, computing device, etc. for decrypting data. The result of the decryption of the certificate 981 and the external public key 983 may be used as input to a secondary decryptor 987, along with a public identification, to produce an output. As illustrated at 989, the external public key 983 and the output from the decryptor 987 may indicate whether the certificate was verified by the comparison, producing yes or no 991 as an output. In response to the certificate being authenticated, data received from the authenticated device may be accepted, decrypted, and/or processed. In response to the certificate not being authenticated, data received from the authenticated device may be discarded, removed, and/or ignored. In this way, rogue devices that send rogue data may be detected and avoided. As an example, a hacker sending pending data may be identified and the hacker data not processed.

Fig. 10 is a block diagram of an example process of verifying a signature according to an embodiment of the disclosure. In instances where the 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 may make a request to a second device, and once the second device executes the request, the first device may indicate that the first device never made such a request. A denial-resistant approach, such as using a signature, may avoid denial by the first device and ensure that the second device can perform the requested task without subsequent difficulty.

Memory device 1006 (e.g., memory device 306 in fig. 3) can send data 1090 to a host (e.g., host 302 in fig. 3). At 1094, 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. Host 1002 may verify the signature using previously received data 1092 and external public key 1069 at 1098. In this way, a 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 Elliptic Curve Digital Signature (ECDSA) or similar process.

FIG. 11 is a block diagram of an example memory device 1106, according to an embodiment of the disclosure. Memory device 1106 may be, for example, memory device 306 previously described in connection with fig. 3.

As shown in FIG. 11, memory device 1106 may include a number of memory arrays 1101-1 through 1101-7. Memory arrays 1101-1 through 1101-7 may be similar to memory array 101 previously described in connection with FIG. 1. Further, in the example illustrated in FIG. 11, memory array 1101-3 is a secure array, subset 1111 of memory array 1101-6 includes the secure array, and subsets 1113 and 1115 of memory array 1101-7 include the secure array. 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.

As shown in fig. 11, memory device 1106 may include a repair (e.g., restore) block 1117. The repair block 1117 may serve 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 the area of the memory device 1106 that is addressable by the host.

As shown in fig. 11, memory device 1106 may include a Serial Peripheral Interface (SPI)1104 and a controller 1108. Memory device 1106 can communicate with a host and memory arrays 1101-1 to 1101-7 using SPI 1104 and controller 1108, as previously described herein (e.g., in connection with fig. 3).

As shown in fig. 11, the memory device 1106 may include security registers 1119 for managing security of the memory device 1106. For example, the secure register 1119 may configure the application controller and communicate externally with the application controller. In addition, the secure register 1119 may be modified by an authentication command.

As shown in fig. 11, the memory device 1106 may include a key 1121. For example, 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.

As shown in fig. 11, the memory device 1106 may include an Electrically Erasable Programmable Read Only Memory (EEPROM) 1123. EEPROM 1123 may provide a secure non-volatile area available to the host where individual bytes of data may be erased and programmed.

As shown in fig. 11, memory device 1106 may include a counter (e.g., monotonic counter) 1125. Counter 1125 can be used as a replay-resistant mechanism (e.g., freshness generator) for commands (e.g., signed command sets or sequences) received from and/or sent to a host. 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.

As shown in 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, e.g., cryptographic hashes of the update 220 as previously described herein in connection with fig. 3, and/or golden hashes for verifying data stored in the memory arrays 1101-1 through 1101-7 as previously described herein. Further, the memory device 1106 may support L0 and L1 of DICE-RIOT 1131.

Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that an arrangement calculated to achieve the same results can be substituted for the specific embodiments shown. This disclosure is intended to cover adaptations or variations of several embodiments of the present disclosure. It is to be understood that the above description has been made in an illustrative fashion, and not a restrictive one. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of ordinary skill in the art upon reviewing the above description. The scope of the several embodiments of the present disclosure includes other applications in which the above structures and methods are used. The scope of several embodiments of the disclosure should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

In the foregoing detailed description, certain features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the disclosed embodiments of the disclosure have to use more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the detailed description, with each claim standing on its own as a separate embodiment.