Local ledger blockchain for secure updates

Abstract

The present disclosure includes devices, methods, and systems for secure updates using a local ledger block chain. One embodiment includes a memory and a circuit system configured to receive a global block to be added to a local ledger block chain for verifying updates to data stored in the memory, wherein the global block to be added to the local ledger block chain includes a cryptographic hash of a current local block in the local ledger block chain, a cryptographic hash of the data to be updated stored in the memory, wherein the current local block in the local ledger block chain has a digital signature associated therewith, the digital signature indicating that the global block is from an authorized entity.

Description

Technical Field

[0001] The present disclosure relates generally to semiconductor memories and methods, and more particularly to using memories as local blocks in a local ledger blockchain. 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), etc. Non-volatile memory can provide permanent data by saving 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), etc.

[0003] Memory devices may be combined together to form solid state drives (SSDs), embedded multimedia cards (e.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 SRAM), 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, etc.

[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 a 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] Many threats can affect the data stored in the memory cells of the memory device. For example, such threats may include failures occurring in the memory device and / or threats from hackers or other malicious users. 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 relates to a device using a memory as a local block in a local ledger block chain, comprising: a memory; and a circuit system configured to receive a global block to be added to the local ledger block chain for verifying updates to data stored in the memory, wherein: the global block to be added to the local ledger block chain contains: a cryptographic hash of a current local block in the local ledger block chain; and a cryptographic hash of the data to be updated stored in the memory; and the current local block in the local ledger block chain has a digital signature associated with it, the digital signature indicating that the global block is from an authorized entity.

[0008] On the other hand, the present application relates to a device using a memory as a local block in a local ledger block chain, comprising: a memory; and a circuit system configured to: receive a global block from a global ledger block chain; determine whether the global block is related to the device; add the global block to the local ledger block chain for verifying updates to data stored in the memory, wherein: the global block to be added to the local ledger block chain contains: a cryptographic hash of a current local block in the local ledger block chain; and a cryptographic hash of the data to be updated stored in the memory; and the current local block of the local ledger block chain has a digital signature associated with it, the digital signature indicating that the global block is from an authorized entity.

[0009] In another aspect, the present application relates to a system (200) for using a memory as a local block in a local ledger block chain, comprising: a memory; and a circuit system that generates a local ledger block chain for verifying updates to data stored in the memory, wherein the local ledger block chain is composed of global blocks from a global ledger block chain, wherein the global block contains: a cryptographic hash of a current local block in the local ledger block chain; and a cryptographic hash of the data to be updated stored in the memory; and the current local block of the local ledger block chain has a digital signature associated with it, the digital signature indicating that the global block is from an authorized entity; and a host, wherein the host is configured to: receive the local ledger block chain from the memory; and verify the update to the data stored in the memory using the received local ledger block chain.

[0010] In another aspect, the present application relates to a system for using a memory as a local block in a local ledger block chain, comprising: a host including a memory; and a circuit system configured to: generate a local ledger block chain for verifying updates to data stored in the memory; receive a global block from a global ledger block chain, wherein the local ledger block chain is composed of global blocks from the global ledger block chain; when a digital signature associated with each of the global blocks in a first part of the global block is verified by the circuit system as being related to the host, add the first part to the local ledger block chain; and when a second part of the received global block is not related to the host, discard the second part of the global block. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0012] Figure 2A 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.

[0013] Figure 2B is a block diagram of a computing system network according to an embodiment of the present disclosure, which may include many computing nodes in a public and / or private network connected in a wired and / or wireless manner using wireless protocols such as point-to-point and Internet Protocol (IP) according to an embodiment of the present disclosure.

[0014] Figure 3 An example of an exchange between a global ledger blockchain and a local ledger blockchain according to an embodiment of the present disclosure is shown, which can be operated by a circuit system and stored in a memory for secure updates stored in the memory.

[0015] Figure 4An example of a local ledger blockchain for secure updates stored in memory according to an embodiment of the present disclosure is shown.

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

[0017] Figure 5B A diagram showing a portion of a memory array including a defined secure memory array according to an embodiment of the disclosure.

[0018] 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.

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

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

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

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

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

[0024] The present disclosure includes devices, methods, and systems for using a memory as a local block in a local ledger block chain. An embodiment includes a memory and a circuit system configured to generate a local ledger block chain, the local ledger block chain including blocks received from a global ledger block chain. The global ledger block chain includes blocks containing update-related data (e.g., transactions, software updates, hardware updates, or data that may otherwise modify software, hardware, code, or portions of code, etc.). Each block of the global ledger block chain may be associated with a single host or multiple hosts. As described herein, the memory and circuit system may be configured to receive multiple global blocks from the global ledger block chain to generate a local ledger block chain, wherein the local ledger block chain only includes blocks associated with the host and / or memory associated with the circuit system. The memory and circuit system may determine which of the received global blocks are associated with the host and / or memory, and may discard global blocks determined to be irrelevant. Blocks in the local ledger block chain can be used to verify data stored in memory, which can be updated by data in the payload of the local block, where the local block contains a cryptographic hash of a previous local block in the local ledger block chain and a cryptographic hash of the data stored in memory to be updated. The global block has a digital signature associated with it, which indicates that the global block is related to the host and is added to the local ledger block chain. In some embodiments, as Figure 1 Specific and / or concrete physical memory blocks in the described memory may be used as local blocks in a local ledger blockchain.

[0025] Many threats may affect data stored in memory (e.g., stored in a memory device). For example, a fault may occur in the array and / or circuit system of the memory, which may cause errors in the data. As an additional example, a hacker or other malicious user may attempt to perform activities to make unauthorized changes to the data for malicious purposes. Such activities performed by hackers may include providing fraudulent updates to the software or hardware of the host device. For example, a malicious user may attempt to change the data stored in the memory through updates to adversely affect commercial transactions (e.g., transfer transaction flows) performed using the memory (e.g., by skipping the code that verifies the payment to falsely indicate that the service provided has been paid), software license checks performed on the memory (e.g., by skipping the code that verifies the license to falsely indicate that the software of the memory has been properly licensed), or automotive control performed using the memory (e.g., skipping part authenticity checks, environmental checks, or fault alarm checks), as well as other types of hacker activities. Such hacker activities (e.g., attacks) may cause significant financial losses, and / or may cause significant safety and / or security issues.

[0026] Thus, to ensure a secure memory system and secure updates to the memory system, it is important to verify (e.g., validate and / or prove) that updates to the data stored in the memory are authentic (e.g., are correct and come from a trusted / authorized entity) and have not been altered and / or fraudulently provided due to hacker activity or other unauthorized and / or unexpected changes. Embodiments of the present disclosure may use the memory as a local block in a local ledger blockchain data structure (e.g., using the memory as a storage component of a local ledger blockchain) to effectively verify updates to be applied to the data stored in the memory, thereby ensuring a secure memory system. For example, embodiments of the present disclosure may modify, utilize, and / or operate in a different manner an existing circuit system of the memory (e.g., an existing firmware of a memory device) to use the memory as a local block in a local ledger blockchain, so that the memory can be used as a local block in a local ledger blockchain without adding additional (e.g., new) components or circuit systems to the memory.

[0027] As used herein, "a" 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 "R", "B", "S", and "N" as used herein, particularly with respect to the reference numerals in the drawings, indicate that several of the particular features so designated may be included with several embodiments of the present disclosure. The numbers between the designations may be the same or different.

[0028] 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 Component "01" in the , and similar components can be found in Figure 2A It is represented as 201 in Chinese.

[0029] Figure 1 A diagram showing a portion of a memory array 101 having several physical blocks according to an embodiment of the present disclosure is shown. The memory array 101 can be, for example, a flash memory array, such as a NAND and / or NOR flash memory array. In an example embodiment, the memory array 101 is a NOR flash memory array 101. 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. Furthermore, the memory array 101 can be a secure memory array, as will be further described herein. Furthermore, although Figure 1Although not shown, memory array 101 may be located on a particular semiconductor die along with various peripheral circuitry associated with its operation.

[0030] like Figure 1 As shown, the memory array 101 has several physical blocks 107-0 (block 0), 107-1 (block 1), ..., 107-B (block B) of memory cells. The memory cells can 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 the memory array 101 can 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 the memory array 101.

[0031] A plane of memory cells may include several physical blocks of memory cells (e.g., blocks 107-0, 107-1, ..., 107-B), and a die may include several planes of memory cells. 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 memory array 101 shown may be a die of memory cells.

[0032] 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 specific number of rows 103-0, 103-1, ..., 103-R per physical block. In addition, although Figure 1 Not shown, but memory cells can be coupled to columns of sense lines (eg, data lines and / or digit lines).

[0033] 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 1In the illustrated embodiment, 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 memory cell pages are coupled to even-numbered data lines, and one or more odd memory cell pages are 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 an upper data page and one or more bits toward a lower data page).

[0034] like Figure 1 As shown, a memory cell page may include several 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 the cell may store several logical sectors of data. In addition, each logical sector of data may correspond to a portion of a particular data page. 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 data page, and a second logical sector of data stored in a particular physical sector may correspond to a second data page. 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.

[0035] Logical block addressing is a scheme that a host can use to identify logical sectors of data. For example, each logical sector can correspond to a unique logical block address (LBA). In addition, an LBA can also correspond to (e.g., dynamically map to) a physical address that can indicate the physical location of the logical sector of data in memory, such as a physical block address (PBA). A logical sector of data can 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.

[0036] 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 contain, for example, more or less than 512 bytes of data.

[0037] Figure 2A 206 and a memory device 206. As used herein, "device" 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 200 may include a number of memory devices similar to memory device 206. In an example embodiment, as Figure 2B As further shown in FIG. 2 , computing system 200 may represent a node within a larger network of nodes, such as a distributed peer-to-peer network.

[0038] exist Figure 2A In the illustrated embodiment, the memory device 206 may include a memory 216 having a memory array 201. Figure 2A As shown, the memory 216 can store "blockchain data" 220 used in the blockchain technology system in the memory array 201. A "block" of blockchain data in the blockchain technology system can include data (e.g., payload), header, encryption, history, timestamp, etc. As will be described in conjunction with Figure 3 and 4 As further described, blockchain data 220 may be “local blockchain” data and / or “global blockchain” data, and may include a stored global blockchain ledger (e.g., “global ledger blockchain” data) and / or a stored local blockchain ledger (e.g., “local ledger blockchain” data).

[0039] The memory array 201 may be similar to the previously described Figure 1 However, as used herein, a block of block chain data in a block chain architecture is not necessarily equivalent to the previously described memory array 101. Figure 1 Therefore, the terms "global block" and / or "local block" are not necessarily equivalent to the block size unit of the memory when the block chain data is stored in the memory. The global block and / or local block can be smaller than, equivalent to, and / or larger than the block size unit associated with a particular memory architecture or design, such as the naming. In addition, the memory array 201 can be a secure array, as will be described herein in conjunction with Figure 5A and 5B further described. Figure 2A One memory array 201 is shown in FIG. 2 , but memory 216 may include any number of memory arrays similar to memory array 201 .

[0040] like Figure 2AAs shown, host 202 can be coupled to memory device 206 via interface 204. Host 202 and memory device 206 can communicate (e.g., send commands and / or data, such as blockchain data 220) on interface 204. Host 202 and / or memory device 206 can be or be 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, for example, 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 can include a memory access device (e.g., a processor). A person of ordinary skill in the art will understand that a "processor" can be one or more processors, such as a parallel processing system, a number of coprocessors, etc.

[0041] The interface 204 may be in the form of a standardized physical interface. For example, when the memory device 206 is used for information storage in the computing system 200, the interface 204 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. The interface 204 may provide an interface for passing control, address, information (e.g., data), and other signals between the memory device 206 and a host (e.g., host 202) having a compatible receiver for the interface 204.

[0042] The memory device 206 includes a controller 208 that communicates with the host 202 and the memory 216 (e.g., the memory array 201). For example, the controller 208 can send commands to perform operations on the memory array 201, including operations of sensing (e.g., reading), programming (e.g., writing), moving and / or erasing data (e.g., "local" and / or "global" blockchain data), as well as other operations. Likewise, the blockchain technology and system are intended to combine the terms "global block" and / or "local block" with the blockchain data. Figure 3 and 4 definition.

[0043] The controller 208 may be included on the same physical device (e.g., the same die) as the memory 216. Alternatively, the controller 208 may be included on a separate physical device that is communicatively coupled to the physical device that includes the memory 216. In an embodiment, the components of the controller 208 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).

[0044] Host 202 may include a host controller ( Figure 2A 206). The host controller may send commands to the memory device 206 via the interface 204. The host controller may communicate with the memory device 206 and / or the controller 208 on the memory device 206 to read, write and / or erase data (e.g., "local" and / or "global" blockchain data), among other operations. In addition, in an embodiment, the host 202 may be an IoT-enabled device with IoT communication capabilities as previously described herein.

[0045] The controller 208 on the memory device 206 and / or the host controller on the host 202 may include control circuitry and / or logic (e.g., hardware and firmware) configured to perform the functions described herein, for example, in accordance with the DICE-RIoT architecture and / or protocol. Figure 3 and 4 In an embodiment, the controller 208 on the memory device 206 and / or the host controller on the host 202 may be an application specific integrated circuit (ASIC) coupled to a printed circuit board containing the physical interface. Also, the memory device 206 and / or the host 202 may include a buffer and a number of registers of volatile and / or non-volatile memory.

[0046] For example, Figure 2A As shown, the memory device may include circuit system 210. Figure 2A In the illustrated embodiment, the circuit system 210 is included in the controller 208. However, the embodiments of the present disclosure are not limited in this regard. For example, in an embodiment, the circuit system 210 may be included in the memory 216 (e.g., on the same die) (e.g., instead of the controller 208). The circuit system 210 may include hardware, firmware, and / or instructions to transmit to a processing resource to, for example, use the DICE-RIoT architecture and / or protocol. Figure 6-11 The encryption technology described in Figure 3 and 4 Perform the block chain operations described in this article.

[0047] For example, circuit system 210 may be configured to receive a global block of block chain data (in Figure 3 and 4 ), adding the local block as block chain data (e.g., 220) to the local ledger block chain within array 201 of memory 216 (also Figure 3 and 4 For example, a local block of blockchain data, such as 220, may be a verified received global block of blockchain data and may generate and / or add to a local ledger blockchain (such as Figure 3 and 4201 ), for verifying (e.g., authenticating and / or proving) updates to data stored in memory 216 (e.g., memory array 201). A global block to be added as a local block in the local ledger blockchain may include multiple headers. In embodiments, a subset of array 201 or the entire array 201 may be a secure array (e.g., an area of ​​memory 216 to be kept under control). Figure 2A A pair of registers 214-1 and 214-2 are shown, but embodiments are not limited thereto and one or more registers may be used. For example, the data stored in memory array 201 may include sensitive (e.g., non-user) data, such as host firmware and / or code to be executed for sensitive applications. In such embodiments, a pair of non-volatile registers may be used to define a security array. For example, in Figure 2A In the illustrated embodiment, the circuit system 210 includes registers 214-1 and 214-2 that can be used to define the security array. For example, the register 214-1 can define the address of the security array (e.g., the starting LBA of the data), and the register 214-2 can define the size of the security array (e.g., the ending LBA of the data). Figure 5A-5B Examples of such registers and their use in defining a security array are further described.

[0048] Once the security array is defined, the circuit system 210 may be used to generate (e.g., calculate) a cryptographic hash associated with the security array, which may be referred to herein as a golden hash (e.g., such that only the memory device 206 knows the golden hash and only the memory device 206 can generate and update the golden hash) using authenticated and anti-replay protected commands. The golden hash may be stored in an inaccessible portion of the memory array 201 (e.g., the same inaccessible portion of the storage blockchain data 220 and the local ledger blockchain) and may be used in the process of verifying the data of the security array.

[0049] In one example embodiment, the memory device 206 (e.g., using the circuit system 210) can send the block chain data 220 (which can be a global block received from the global ledger block chain) to the host 202 via the interface 204 along with the digital signature associated with the block chain data 220 for verifying the update (e.g., the payload of the block chain data) before updating the data stored in the memory array 201. For example, in response to the powering up (e.g., power on and / or power up) of the memory device 206, the circuit system 210 can sense (e.g., read) the block chain data 220 received and stored in the memory array 201, and send the sensed block chain data 220 to the host 202 to verify the update to the data stored in the array 201. Thus, the verification of the update to the data stored in the memory array 201 can be initiated (e.g., automatically) when the memory device 206 is powered.

[0050] As an additional example, the circuit system 210 can send the block chain data 220 together with the digital signature associated with the block chain data 220 to the host 202 when an external entity such as the host 202 initiates verification of an update to the data stored in the memory array 201. For example, the host 202 can send a command to the memory device 206 (e.g., the circuit system 210) to sense the block chain data 220, and the circuit system 210 can operate on the command in response to receiving the command to sense the block chain data 220 and send the sensed block chain data 220 to the host 202 to verify the data stored in the array 201.

[0051] After receiving the block chain data 220, the host 202 can verify (e.g., determine whether to verify) the data stored in the memory array 201 using the received block (e.g., the payload of the received global block). Figure 3 and 4 To further elaborate, the host 202 can verify the data using a cryptographic hash of a previous block in the blockchain and a cryptographic hash of the data stored in the memory array 201. In addition, the host 202 can verify the digital signature associated with the blockchain data 220 to determine that the local block is included (e.g., meets the requirements to be included) in the local ledger blockchain. As used herein, verifying an update to the data stored in the memory array 201 may include and / or involve authenticating and / or proving that the update is authentic (e.g., the same as originally programmed) and has not been altered by hacking activities often provided by hackers, or otherwise includes unauthorized changes.

[0052] In an embodiment where the memory array 201 is a secure array, as in combination with Figure 3 and 4 As further described, the golden hash may also be used to verify updates to data stored in the memory array 201. For example, a runtime cryptographic hash may be generated (e.g., calculated) and compared to the golden hash. If the comparison indicates that the runtime and golden hashes match, then it may be determined that the secure array has not been altered, and therefore the data stored therein is valid. However, if the comparison indicates that the runtime and golden hashes do not match, then this may indicate that the data stored in the secure array has been altered (e.g., due to a hacker or a malfunction in the memory), and this may be reported to the host 202.

[0053] In an example embodiment, in addition to verifying the data stored in the memory array 201, the circuit system 210 can also verify the blockchain data 220 (e.g., the global block received from the global ledger blockchain) to determine whether the blockchain data 220 is from an authorized entity (e.g., a known entity) and the hash indicated on the received blockchain data 220 matches the most recent local block of blockchain data on the local ledger blockchain. In response to the verification of the blockchain data 220, the circuit system 210 can be configured to provide an update contained in the blockchain data 220 to add, modify and / or replace the code (or a portion of the code) stored in the secure array.

[0054] If combined Figure 3 and 4 To further illustrate, after verifying the block chain data 220 as a local block in the local ledger block chain stored in the memory array 201, the circuit system 210 can generate an additional (e.g., next) local block to be added to the local ledger block chain to update the data stored in the memory array 201 (e.g., receiving the next global block that forms the global ledger block chain), in a manner similar to the manner in which the previous block chain data 220 was generated / received. For example, this additional local block of block chain data 220 may include a cryptographic hash of the previous block in the local ledger block chain, and a new cryptographic hash of the new update to the data stored in the memory array 201. In addition, this additional local block may include a header with a timestamp indicating when this block was generated (e.g., received as an additional global block), and may have a digital signature associated therewith, the digital signature indicating that this additional local block is from an authorized entity and can be included in the local ledger block chain. Examples of such additional local blocks (e.g., in conjunction with Figure 3 ). Furthermore, in embodiments where memory array 201 is a secure array, additional (eg, new) golden hashes may be generated.

[0055] The additional local blocks of blockchain data and the digital signature and additional golden hash associated with the additional local blocks may be stored in the memory array 201 as part of the local ledger blockchain. For example, the additional local blocks may replace the blockchain data 220 (e.g., the previous blockchain data 220) in the memory array 201. The host 202 may then use the additional blockchain data, the digital signature, and the additional golden hash to verify updates to the data stored in the memory array 201 (e.g., the payload) in a manner similar to that previously described herein for the blockchain data 220. The circuit system 210 may continue to generate the additional local blocks in the local ledger blockchain as they are received as global blocks, verified by the host 202, and used by the host 202 to verify updates to the data stored in the memory array 201, in this manner throughout the life of the memory device 206.

[0056] Figure 2A The illustrated embodiment may include additional circuitry, logic, and / or components that are not shown to avoid obscuring the embodiments of the present disclosure. For example, the memory device 206 may include address circuitry that latches address signals provided on the I / O connector via the I / O circuitry. A row decoder and a column decoder receive and decode the address signals to access the memory array 201. In addition, the memory device 206 may include a main memory that is isolated from the memory array 201 and / or in addition to the memory array, such as a DRAM or SDRAM. Examples of additional circuitry, logic, and / or components that further illustrate the memory device 206 are further described herein (e.g., in conjunction with Fig.11 ).

[0057] Figure 2B is a block diagram of a computing system network according to an embodiment of the present disclosure, which may include many computing nodes in a public and / or private distributed network such as a peer-to-peer network connected in a wired and / or wireless manner using wireless protocols and Internet Protocol (IP). Figure 2B In the example of FIG. 1 , a plurality of nodes 200-1, 200-2, 200-3, ..., 200-N connected in a network such as a peer-to-peer network are shown. The network may support a distributed ledger technology (DLT), such as a "block chain" technology. A distributed ledger is a database distributed across several nodes or computing devices.

[0058] A "blockchain" is a growing list of encrypted records. A blockchain is a form of DLT where multiple nodes 200-1, 200-2, 200-3, ..., 200-N can share and store a distributed list of records in a peer-to-peer network. As described herein, a "block" in a blockchain is a collection of information, such as data, headers, transactions, encryption, etc. If a block is verified, it can be added to the growing list of records in the ledger. Blocks are added to the blockchain ledger in chronological order.

[0059] Therefore, in Figure 2B In an example, a given node 200-1 (H1), 200-2 (H2), 200-3 (H3), ..., 200-N may maintain a copy of the current list or record in the ledger. Multiple nodes 200-1, 200-2, 200-3, ..., 200-N may each represent a different host, for example, a computing device with processing resources. For ease of illustration, a host or multiple nodes 200-1, 200-2, 200-3, ..., 200-N may be considered in relation to a block chain of an automated and / or non-automated transport vehicle, automobile, bus, emergency vehicle, etc. However, the embodiments are not limited to this example.

[0060] In this example, if Figure 2B As shown, a server of a vehicle manufacturer may represent one node, such as 200-1, on a network of nodes 200-1, 200-2, 200-3, ..., 200-N. A certified repair facility, such as a dealer repair shop, may represent another node, such as 200-2. Node 200-3 may be another host, such as another computing device, connected to the peer-to-peer network via the Internet and / or other wireless connections.

[0061] The manufacturer associated with node 200-1 may maintain a "first block chain ledger" having chronologically linked data blocks associated with a specific topic associated with node 200-1, for example, maintaining a first block chain ledger for all vehicles produced by the manufacturer. For ease of illustration and not as a limitation, a "first block chain ledger" having chronologically linked data blocks associated with a specific topic associated with a specific node (e.g., all vehicles produced by a given vehicle manufacturer) may also be referred to herein as a "global block chain ledger" (or "global ledger block chain"). The manufacturer may distribute the first block chain ledger ("global ledger block chain") to other nodes 200-2, 200-3, etc. in a peer-to-peer network in a wired and / or wireless manner, as well as to its vehicles connected to the network as nodes. Various wireless communication technologies may be used when communicating with different nodes 200-1, 200-2, 200-3, ..., 200-N. For example, different generations of broadband mobile communication technologies (e.g., first to fifth generations (1-5G)), device-to-device (e.g., vehicle-to-vehicle (v2v)) communications including Bluetooth, Zigbee and / or LTE device-to-device communication technologies, and / or other wireless communications utilizing intermediate devices (e.g., WiFi utilizing an access point (AP)) may be used for communication with different nodes.

[0062] exist Figure 2B In the example of , node 200-4 may represent a specific vehicle belonging to a subset or category of vehicles manufactured by a specific manufacturer represented by node 200-1. In this example, node 200-5 may represent another specific vehicle in the same or different subset or category of vehicles manufactured by a specific manufacturer or alternatively unrelated to the manufacturer associated with node 200-1. Similarly, node 200-N may represent another specific vehicle in the same or different subset or category of vehicles manufactured by a specific manufacturer or alternatively unrelated to the manufacturer associated with node 200-1.

[0063] Each node may have its own processing resources, such as a host connected to one or more memory devices, e.g. Figure 2AAs shown. Thus, vehicle nodes 200-4, 200-5, and 200-N may each include a single and / or multiple hosts, such as processing resources 202-4, 202-5, 202-N, respectively. Each host on a given vehicle node 200-4, 200-5, and 200-N may be connected to multiple memory devices on each vehicle. For example, memory devices 206-4-1, 206-4-2, 206-4-X may be associated with host 202-4 on node 200-4, memory devices 206-5-1, 206-5-2, and 206-5-B may be associated with host 202-5 on node 200-5, and memory devices 206-N-1, 206-N-2, and 206-NZ may be associated with host 202-N on node 200-N.

[0064] In this example, node 200-1 may periodically send (e.g., distribute) to nodes 200-4, 200-5, ..., and 200-N an updated copy of a continuously growing first (e.g., "global") blockchain ledger maintained by node 200-1 (also referred to herein as a "global ledger blockchain"), which contains chronologically ordered blocks, such as data, related to a subject of all vehicles produced by a manufacturer. According to blockchain technology, node 200-1 may share a copy of the first (e.g., "global") ledger blockchain with other nodes 200-1, 200-2, 200-3, ..., 200-N in a distributed network. However, not all "blocks" in the growing first (e.g., "global") ledger blockchain maintained by node 200-1 and received by other specific nodes 200-4, 200-5, ..., 200-N may be credible and / or relevant to other specific nodes. For example, a particular vehicle, such as node 200-4, 200-5, ..., 200-N, may belong to a subset or subclass of vehicles manufactured by a particular manufacturer associated with node 200-1, but only a particular block in the first (e.g., "global") ledger block chain may be related to the particular node 200-4, 200-5, ..., 200-N (e.g., a particular vehicle in the subset or subclass of vehicles). Thus, according to embodiments disclosed herein, a particular node 200-4, 200-5, ..., 200-N may only verify those blocks that are authenticated and related to the node 200-4, 200-5, ..., 200-N.

[0065] According to an example embodiment, a specific node (e.g., 200-4) may verify a block that is authenticated and associated with the node and add the block to a second block chain ledger, which may be a subset of all blocks contained in the global ledger block chain received from node 200-1 to node 200-4. Node 200-4 may store a subset of the "global ledger block chain" as a "local block chain ledger" (also referred to herein as a "local ledger block chain") on the corresponding node 200-4, 200-5, ..., 200-N. Node 200-4 may also share a local ledger block chain with other nodes. However, it is not required to be the same, and the local ledger block chain is referred to as "local" because it can be kept "local" only for a specific node 200-4 (e.g., a host and / or memory device of a specific vehicle). Therefore, for ease of explanation, the second block chain ledger ("local ledger block chain") may be referred to as a local ledger block chain in this article. A node (e.g., 200-4) may receive many global blocks on various topics associated with other global ledger blockchains via the network of nodes to which it is connected. However, a node (e.g., 200-4) may choose which blocks it accepts to be added and which blocks it allows to be added to its local ledger blockchain. Figure 3 and 4 In more detail, embodiments of the present disclosure may be used Figure 6-11 , 200-N, and stores and maintains those blocks on the specific nodes 200-4, 200-5, ..., 200-N as "local ledger blockchain" data, for example, as a secure firmware update for a specific vehicle. In one example, a single host (e.g., Figure 2A As shown, one or more hosts may maintain a local ledger block chain. As an example, a single or multiple hosts may be based on co-pending, commonly filed U.S. Application No. _____________, attorney docket number 1016.0030001, entitled “USING MEMORY AS A BLOCK IN A BLOCK CHAIN.” In this example, firmware updates associated with a particular vehicle (e.g., nodes 200-4, 200-5, ..., 200-N) may be verified and added to the “local ledger block chain” of nodes 200-4, 200-5, ..., 200-N, or alternatively discarded.

[0066] Figure 3An example of an exchange between a global ledger blockchain 322 and local ledger blockchains 324, 326, and 328 is shown, which may be operated by the circuit system and stored in a memory and / or secure array (e.g., via Figure 2A In this example, secure updates to data may be verified and stored in memory, for example in conjunction with Figure 2A Memory array 201 described herein. As used herein, a "block" according to blockchain technology in a blockchain ledger or system may include data (e.g., payload), headers, encryption, history, timestamps, etc. Likewise, a "block" in a blockchain is not necessarily related to or equivalent to the size of a memory block, such as Figure 1 As described in the description as a memory storage unit.

[0067] Furthermore, as used herein, the term "global block" is a block in the first ledger, in this case, maintained and shared within a larger entity system or network. A "local block" is a block that is only in the local ledger blockchain as a subset of data associated with a specific node (e.g., 200-4), as a subset of data associated with an entity system or network (e.g., Figure 2A The global blocks and / or local blocks may be named smaller than, equal to, and / or larger than the block size associated with a particular memory architecture or design.

[0068] exist Figure 3 In an example of Figure 2B The global ledger block chain may include global blocks 320-1, 320-2, 320-3, 320-4, 320-5, 320-6, and 320-N. When operated by the circuit systems and logic described herein, the global block 320 may be verified and accepted into the second (e.g., local) ledger block chain 324, 326, and 328, shown as local blocks 321-1, 321-2, 321-3, 321-4, 321-5, 321-6, and 321-N. The second (e.g., local) ledger block chain 324, 326, and 328 may be composed of Figure 2B , wherein the corresponding nodes 200-4, 200-5, ..., 200-N maintain. Alternatively, if a particular node (e.g., Figure 2B The local ledger block chain maintained on the nodes 200-4, 200-5, ..., 200-N) shown in the figure can reject the corresponding global block of the global ledger block chain.

[0069] For example, when a specific memory receives global blockchain data to be verified and stores it as a local block in the local ledger blockchain, it must pass through circuit systems and logic (e.g., Figure 2A The circuit system 210 in the local ledger verifies the global blockchain data before it becomes a local block in the local ledger blockchain. Figure 3 In the example, through the circuit system 210, the global block 320-1 has been verified to become the local block 321-1 in the local ledger block chain 324, the global block 320-2 has been verified to become the local block 321-2 in the local ledger block chain 326, the global block 320-3 has been verified to become the local block 321-3 in the local ledger block chain 328, the global block 320-4 has been verified to become the local block 321-4 in the local ledger block chain 324, the global block 320-5 has been verified to become the local block 321-5 in the local ledger block chain 324, the global block 320-6 has been verified to become the local block 321-6 in the local ledger block chain 326, and the global block 320-N has been verified to become the local block 321-N in the local ledger block chain 328.

[0070] In one example embodiment, by using Figure 2A The circuit system 210 described in the above may receive the global block 320 into a memory device, such as Figure 2A 201, verify and add (e.g., generate) to the local ledger blockchain 324, 326 or 328. Figure 3 In the example of , global block 320-4 has been received and verified to become local block 321-4. Local block 321-4 can be added to local ledger block chain 324 after local block 321-1 has been verified by the circuit system and logic described herein. Figure 4 As further described, local block 321-1 is used to verify global block 320-4 as an update of data stored in memory. In this example, local block 321-4 may be accepted and stored as the next block after local block 321-1 in local ledger blockchain 324. Global ledger blockchain 322 may include data from multiple hosts (e.g., in combination with Figure 2A Blocks in the blockchain configuration, architecture and / or protocol of the host 202) described.

[0071] The host and / or storage may maintain (e.g., store) a local ledger block chain 324, 326, 328 and contain only verified global blocks associated with a particular host and / or storage. The global block 320 may contain an identifier of a particular host and / or storage associated with the data contained in the global block. For example, the local ledger block chain 324 is shown to be associated with a particular host / storage identifier (ID_1). Therefore, the circuit system associated with this host / storage relationship will only verify the relevant global blocks, so that the local ledger block chain 324 will only contain local blocks 321-1 (global block 320-1 from the global ledger block chain 322), local blocks 321-4 (global blocks 320-4 from the global ledger block chain 322), and local blocks 321-5 (global blocks 320-5 from the global ledger block chain 322). The local ledger block chain 326 is shown to be associated with another host and / or storage identifier (ID_2). Thus, the circuitry associated with this host / memory relationship will only verify the relevant global blocks, such that the local ledger block chain 326 will contain local block 321-2 (global block 320-2 from global ledger block chain 322) and local block 321-6 (global block 320-6 from global ledger block chain 322). The local ledger block chain 328 is shown associated with another host and / or memory identifier (ID_k). Thus, the circuitry associated with this host / memory relationship will only verify the relevant global blocks, such that the local ledger block chain 328 will contain local block 321-3 (global block 320-3 from global ledger block chain 322) and local block 321-N (global block 320-N from global ledger block chain).

[0072] Using the local ledger blockchain (e.g., 324, 326, 328) to store appropriate blockchain data as updates to the memory and / or memory relationships (e.g., ID_1, ID_2, and ID_k) of the corresponding host, it is possible to provide updates to the data stored in a given memory device associated with a given host (e.g., Figure 2A Thus, the circuitry and logic described herein allow for secure updating of data in the memory device 206). Figure 3. For example, the circuit system is configured to receive a global block (e.g., 320-4) from the global ledger block chain 322 and determine whether the global block 320-4 is associated with a specific host and / or memory relationship. If the global block 320-4 is associated with a specific host and / or memory, for example, the circuit system may add the global block 320-4 to its local ledger block chain 324 by comparing the encrypted hashes of the corresponding identifiers (e.g., ID_1, ID_2, and ID_k) according to a block chain matching technique. The global block 320-4 of block chain data may contain a payload of updates to data contained in a security array associated with the host and / or memory. The circuit system described herein, such as the circuit system 210, can verify the global block 320-4 by checking (e.g., comparing) the cryptographic hash of the current local block (e.g., 321-1) in the local ledger block chain 324 with the cryptographic hash of the data to be updated contained in the global block 320-4 stored in the memory. The current local block 321-1 of the local ledger block chain 324 also has a digital signature associated therewith, which is similarly compared to indicate whether the global block 320-4 is from an authorized entity (e.g., contains an identifier ID_1 that proves that the global block 320-4 is from an entity associated with a particular host and / or contains a memory relationship of the local ledger block chain 324). Figure 4 As explained above, if verified, the current local block 321-1 will become the “previous” local block, and the global block 320-4 will become the “current” local block 321-4 in the local ledger blockchain 324. Figure 4 Describe in detail the contents of local block 321 of local ledger blockchain 324 (e.g., and / or 326, 328).

[0073] An authorized entity may provide the global ledger blockchain 322 as a public ledger that may be distributed to all and / or a portion of hosts and / or memories that are consistent with the global ledger blockchain 322 to receive system updates (e.g., updates to hardware, software, and / or configuration updates). For example, the global ledger blockchain 322 may be generated and maintained by an entity that may provide services such as hardware updates, software updates, component configurations, changes to code stored in memory, changes to a portion of code stored in memory, etc., for multiple host devices and / or memory devices served by the entity. For example, the global ledger blockchain 322 may be generated and monitored by a vehicle manufacturer. Each global block 320 within the global ledger blockchain 322 may include data for implementing updates to instructions stored in memory for a vehicle having a particular identifier. For example, if Figure 3As shown, global blocks 320-1, 320-4, 320-5 correspond to host and / or memory ID_1, global blocks 320-2, 320-6 correspond to host and / or memory ID_2, and global blocks 320-3, 320-N correspond to host and / or memory ID_k, wherein different IDs correspond to different host and / or memory relationships (e.g., different vehicles).

[0074] In this example, the vehicle manufacturer generates and monitors the global ledger blockchain 322 such that each instance of an update generated for a particular vehicle (e.g., or a particular subset of vehicles that share an identifier) ​​is recorded as an immutable record in the global ledger blockchain 322. For example, global block 320-1 contains updates to the vehicle associated with ID_1 (e.g., or data in a memory associated with the vehicle), global block 320-2 contains updates to the vehicle associated with ID_2, and so on. The global blocks 320 are assembled in sequential order as they are produced by the vehicle manufacturer, and each global block 320 may include a digital signature indicating the vehicle manufacturer (e.g., entity) from which the block originated. In this way, the vehicle manufacturer can maintain an immutable record of all updates generated for the different vehicles being monitored.

[0075] As used in blockchain technology and combined Figure 4 In more detail, a global block 320 in a global ledger block chain 322 may include multiple headers and encryptions. For example, a global block of a global ledger block chain may include a global block header that includes cryptographic hash data to a previous global block (e.g., a link to a previous global block) and a hash that includes cryptographic hash data to a previous local block. Thus, when Figure 2A When the host 202 and / or the memory device 206 in the local ledger block chain receives the global block, the global block to be added to the local ledger block chain may include a cryptographic hash of the current local block in the local ledger block chain (e.g., in the block chain data 220) (e.g., a link to the current local block) and a cryptographic hash of the update to the data (e.g., the payload) stored in the memory device 206. The block chain data 220 in the local ledger block chain may also include a digital signature associated therewith, the digital signature indicating that the global block is from an authorized entity.

[0076] In other words, the host and / or storage (e.g., Figure 2A The host 202 and / or memory 216 shown may receive a global block from the global ledger blockchain, and the circuitry and / or logic on the host and / or memory may determine whether the global block is relevant to the host and / or memory. If so, the global block and its contents may be validated to become a new local block of blockchain data stored in the local ledger blockchain (e.g., as stored in the local ledger blockchain). Figure 2AThe local block may also include a header with a timestamp indicating when the local block was generated / received.

[0077] stored in a memory array (e.g., Figure 2A The cryptographic hash of the data in the memory array 201) will be updated, modified, configured, and / or otherwise changed by the data contained in the received / generated local block, and / or the cryptographic hash of the previous local block in the local ledger block chain may include, for example, a SHA-256 cryptographic hash. In addition, the cryptographic hash of the data stored in the memory array and the cryptographic hash of the previous local block in the local ledger block chain may each include 256 bytes of data, respectively.

[0078] A cryptographic hash of the data stored in the memory array may be generated by e.g. Figure 2A In such instances, the cryptographic hash of the stored data may be generated (e.g., calculated) by a circuit system such as circuit system 210 in FIG. Figure 2A 206) is generated internally without requiring a host / memory device interface (e.g., Figure 2A As an additional example, a cryptographic hash of the data can be transmitted from an external entity. For example, the host can generate a cryptographic hash of the data stored in the memory array and send the generated cryptographic hash to the memory device, for example, the circuit system of the memory device can receive the cryptographic hash of the data stored in the memory array from the host.

[0079] In addition, a digital signature associated with the local block may be generated (e.g., calculated) by the circuit system based on (e.g., in response to) an external command (e.g., a command received from the host). The digital signature may be generated using symmetric or asymmetric cryptography. The digital signature may include a freshness field in the form of a previous local block on the global ledger block chain (when a block is added, it should match the current local block on the local ledger block chain). As an additional example, the host may generate a digital signature and send (e.g., provide) the generated digital signature to the memory device.

[0080] The freshness field described herein may change with each global block added to the local ledger block chain. Therefore, the freshness field can be used to verify that the incoming global block is the correct block to be added as the next block in the local ledger block chain. When the digital signature indicates that the incoming global block is related to the host, and the previous local block field (freshness) of the incoming global block is the same as the current local block in the local ledger block chain, it is verified that the incoming global block is the next local block to be added to the local ledger. Because freshness can also be used to calculate the digital signature, the digital signature can be different for each incoming global block.

[0081] As mentioned, the digital signature can be, for example, a digital signature generated using asymmetric cryptography (e.g., based on public and / or private keys), and can include, for example, an elliptic curve digital signature. As an additional example, the signature can be generated using symmetric cryptography (e.g., based on a unique secret key shared between the host and the memory device). The secret key can be exchanged using any asymmetric protocol (e.g., the Diffie-Hellman protocol). In other examples, the key can be shared with the host in a secure environment (e.g., factory production, secure manufacturing, etc.). In conjunction with Figure 6-11 The generation and verification of secret keys is discussed further.

[0082] As combined Figure 2A As described, such block chain data 220 may be stored in a memory array, such as Figure 2A The blockchain data 220 may be stored in a portion of the memory array 201 that is not accessible to a user and / or host of the memory device (e.g., in a "hidden" area of ​​the memory array). Storing local blocks of blockchain data and / or local ledger blockchains in a particular memory array may simplify the storage of local blocks by eliminating the need for software storage management of local blocks.

[0083] exist Figure 3 In an example of , the global block 320-6 may include a global header having a field for a hash of a previous global block 320-5, wherein the previous global block field indicates a previous block in the global ledger block chain 322. A different hash in the global header may include a previous local block field, wherein the previous local block field indicates a previous global block with the same host identifier and / or memory ID.

[0084] For example, global block 320-6 may include a local block field with a hash of global block 320-2 (the previously related global block) because they are both vehicle ID 2. In this way, a particular host and / or memory device relationship (e.g., for a vehicle, or a subset of vehicles) may receive multiple global blocks 320 from the global ledger blockchain 322 and determine which global blocks 320 to accept as local blocks and which global blocks 320 to discard.

[0085] For example, the local ledger block chain 324 may be contained in a memory device and / or memory associated with a particular host by an identifier in the form of a host (e.g., a vehicle) with ID_1. The circuit system as described herein may be configured to store the global block 320 in a memory associated with the host vehicle as part of the local ledger block chain 324. In other words, the circuit system is configured to receive multiple global blocks 320 from the global ledger block chain 322, and when the circuit system determines that the global blocks 320 belong to the host vehicle associated with vehicle ID_1, they are accepted as local blocks 321 and added to the local ledger block chain 324.

[0086] Specifically, in an example, a host vehicle and / or a memory associated with a host vehicle having ID_1 includes (e.g., may store) a local ledger block chain 324, and the circuit system and / or the memory may receive a plurality of global blocks 320-1, 320-2, 320-3, 320-4, 320-5, 320-6, and 320-N from a global ledger block chain 322. The circuit system is configured to determine whether the plurality of global blocks 320 received by the circuit system from the global ledger block chain 322 is related to the host vehicle and / or the memory associated with the host vehicle ID_1. Thus, the circuit system can determine that the global blocks 320-1, 320-4 and 320-5 are associated with the host vehicle ID_1, and the circuit system is configured to verify, and if verified, sequentially add the global blocks 320-1, 320-4, 320-5 from the multiple global blocks received from the global ledger block chain 322 to the local ledger block chain 324 as local blocks 321-1, 321-4 and 321-5 because they have been verified to be associated with the host vehicle ID_1.

[0087] In one example, global blocks 320-1, 320-4, and 320-5 may be added (sequentially) to local ledger block chain 324 when the previous local block field in the corresponding global block 320 matches the current local block field in the current local block of local ledger block chain 324. Specifically, the circuit system may verify the incoming global block 320-4 by confirming that the global block 320-4 is from an authorized entity (e.g., the global ledger block chain 322 of the vehicle manufacturer), checking whether the previous local block field of global block 320-4 is the hash of local block 321-1 (which is the same as global block 320-1), and checking that the current local block 321-1 has a matching hash in its own current local block field. This process may be applied to add global block 320-5 to local ledger block chain 324. Therefore, global blocks 320-1, 320-4, and 320-5 can become local blocks 321-1, 321-4, and 321-5 in the local ledger block chain 324. Using this method and configuration, the local ledger block chain 324 contains multiple local blocks associated with the host and / or storage associated with (ID_1) compiled in a sequential order.

[0088] Additionally, when a global block 320 is not associated with the host and / or memory ID_1, the circuit system is configured to avoid adding the global block to the local ledger block chain 324. Therefore, the circuit system may determine that global blocks 320-2, 320-6, 320-3, and 320-N are not associated with the host and / or memory ID 1, and may discard the unrelated global blocks from the local ledger block chain 324. Figure 3 The described mechanisms may be applied to multiple hosts and / or multiple memories, for example, local ledger blockchain 326 and local ledger blockchain 328.

[0089] For example, the circuit system may generate a local ledger block chain (e.g., 324) for verifying updates to data stored in a memory (e.g., associated with ID_1) and receive global blocks (e.g., 320-1, 320-2, 320-3, 320-4, 320-5, 320-6, 320-N) from the global ledger block chain 322. When the digital signature associated with each of the global blocks in a first portion of the global block (e.g., 320-1, 320-4, 320-5) is verified by the circuit system as being associated with a host and / or memory (e.g., ID_1), the circuit system may add the first portion to the local ledger block chain 324. When the second portion of the received global block (e.g., 320-2, 320-6, 320-3, 320-N) is determined to be unrelated to the host and / or memory associated with ID_1 (e.g., the second portion is associated with ID_2 and / or ID_k), the circuit system may discard the second portion of the global block.

[0090] As combined Figure 4 Further describing, the circuit system can use the freshness field to verify whether the global block belongs to the local ledger block chain (e.g., 324, 326, 328). In the above example, each of the global blocks of the first part (e.g., 320-1, 320-4, 320-5) contains a freshness field for generating a digital signature. The freshness field of each of the global blocks of the first part (e.g., 320-1, 320-4, 320-5) corresponds to the current local block of the local ledger block chain 324. Thus, the global blocks of the first part (e.g., 320-1, 320-4, 320-5) are added to the local ledger block chain 324 (as local blocks 321-1, 321-4 and 321-5) in a sequential order and stored in a memory associated with the host.

[0091] Specifically, the circuit system can generate a digital signature based on the freshness field of the global block. For example, the circuit system can generate the freshness field of the global block 320-4 by identifying the previous local block field in the header of the global block 320-4 (in this example, this will be the hash of the global block 320-1 because it is the previous global block with ID_1). Where the previous local block field of the current local block 321-1 of the local ledger block chain 324 and the global block 320-4 of the global ledger block chain 322 are the same (again, in this example, this will be the global block 320-1).

[0092] Figure 4 The method for storing in a memory (for example, previously combined with Figure 2A An example of a local ledger blockchain (e.g., local ledger blockchain 424) that is securely updated in the memory array 201 described above. The local ledger blockchain 424 may be similar to the one combined with Figure 3 The local ledger block chain 324 described above. For ease of explanation, Figure 4 Only the local ledger blockchain 424 is shown. However, in conjunction with Figure 4 The examples described with respect to local ledger blockchain 424 may also be applied to other local ledger blockchains (e.g., in conjunction with Figure 3 The local ledger blockchain 424 is a blockchain used to securely update data stored in the memory of the corresponding host and / or memory exchange. As an example, the host and / or memory exchange is associated with a specific identifier (e.g., identifier ID_1).

[0093] In this example, local blocks 421-1, 421-4, 421-5 of the local ledger block chain 424 are previously received as e.g. Figure 3 In one example, Figure 2A The circuit system 210 uses a combination of Figure 5A-11 The described block chain encryption and decryption techniques operate on the received global blocks to compare and verify the hash of the block chain data, for example, using a SHA256 hash. When the global blocks are verified to be associated with the host and / or memory (e.g., ID_1), they can become local blocks 421-1, 421-4, and 421-5 and stored as immutable records in the local ledger block chain 424 for the host and / or memory associated with ID_1. In this example, the circuit system is used to compare the block chain hash of the local block 421-4 (e.g., the previous global block 320-4) with the local block 421-1 (e.g., the previous global block 320-1) for storage in the memory associated with the host ID_1. The circuit system can be linked to the local block 421-1 once verified by the circuit system associated with the host and / or memory. Likewise, local block 421 - 5 (eg, previously global block 320 - 5 ) may be linked to local block 421 - 4 once verified by circuitry associated with the host and / or memory.

[0094] exist Figure 4 In the example of , each local block (e.g., 421-1, 421-4, and / or 421-5, etc.) may include the following information: a global block header, such as 430-1, 430-4, 430-5; and a local block header, such as 432-1, 432-4, 432-5. In this example, each local block header 432-1, 432-4, 432-5 includes a previous local block hash 433-1, 433-4, 433-5, a current local block hash 434-1, 434-4, 432-5, and a block signature 435-1, 435-4, 435-5. Figure 4 As shown in the example of , each local block, such as 421-1, 421-4 and 421-5, contains a payload, such as 436-1, 436-4, 436-5, as part of the block information, such as data. Figure 3 As mentioned, each of the blocks (e.g., global and local) may contain multiple headers (e.g., 430-1, 432-1) to link the current block to the previous blocks in its corresponding blockchain ledger (global or local).

[0095] For example, referring to the method of adding local block 421-4 to local ledger blockchain 424, global block header 430-4 may include a freshness field in the form of a hash for the previous global block with the same associated ID_1 in the global ledger blockchain and a hash for the current global block (to link the global ledger blockchain together). In other words, when a global block (e.g., Figure 3 320-4) located on the global ledger blockchain (e.g., Figure 3322), the freshness field in the global block header is the global ledger block chain (e.g., Figure 3 322) with the same associated identifier (e.g., ID_1) in the previous global block (e.g., Figure 3 In this example, when verifying the addition of local block 421-4 to local ledger block chain 424, when the circuit system verifies the incoming global block (e.g., 320-4) to be added to local ledger block chain 424 as local block 421-4, the current local block hash 434-1 of local block 421-1 in local ledger block chain 424 will be the same as the freshness field in global block header 430-4. In other words, the freshness field of global block header 430-4 should match the current local block hash 434-1 of local block 421-1 of local ledger block chain 424 because the current local block 421-1 was previously the global block 320-1.

[0096] The local block headers, such as 432-1, 432-4, and 432-5, each contain a previous local block hash, such as 433-1, 433-4, and 433-5, respectively (for linking the local ledger block chain 424) and a current local block hash, such as 434-1, 434-4, and 434-5 (same as the incoming global block freshness field), and a block signature, such as 435-1, 435-4, 435-5, to indicate that the block is from an authorized entity (e.g., from a vehicle manufacturer and / or an entity associated with the host and / or memory) and is associated with the host and / or memory (e.g., ID_1). The payloads, such as 436-1, 436-4, and 436-5, can be data containing a cryptographic hash of hardware, configuration, and / or software updates (e.g., configurations, configuration changes, changes to a device of the host and / or memory associated with the host, etc.) and / or data stored in the memory to be updated.

[0097] For example, a host in the form of a vehicle and / or a memory associated with a vehicle having an identifier ID_1 may include memory and circuitry to generate a local ledger blockchain 424 for verifying updates to data stored in the memory. In this example, the local ledger blockchain 424 is comprised of data taken from a global ledger blockchain (e.g., Figure 3 322) of the local block 421-4 (for example, Figure 3The local block 421-4 includes a current local block cryptographic hash 434-4 of the current local block 421-4. The current local block cryptographic hash 434-4 can be compared with the previous local block cryptographic hash 433-4 (which is the current local block hash 434-1) as a freshness field that verifies the order (e.g., sequence) and links the local ledger block chain 424 with the cryptographic hash of the data to be updated stored in the memory (e.g., payloads 436-1, 436-4, and 436-5). The local block 421-4 of the local ledger block chain 424 has a digital signature 435-4 associated therewith, which indicates that the global block (e.g., Figure 3 320-4) from an authorized entity and is correctly added as a local block 421-4. In some instances, the authorized entity may be a vehicle manufacturer that is updating all vehicles produced by the manufacturer. In this way, the host and / or storage associated with ID_1 can check the block signature (e.g., 435-4) and can discard global blocks received from the global ledger blockchain (e.g., global ledger blockchain 322) that are not related to the host and / or storage associated with ID_1.

[0098] The host and / or memory ID_1 may be configured to receive a local ledger blockchain 424 from the memory, and use the received local ledger blockchain 424 to verify updates to the data stored in the memory (e.g., payloads 436-1, 436-4, and 436-5). In this way, the host and / or memory associated with ID_1 can maintain and / or monitor each of the updates provided to the host and / or memory from an authorized entity. Because the compilation of the local ledger blockchain 424 generates an immutable record, the circuit system can maintain control of the updates that occur. This can prevent fraudulent updates, unintentional changes, unintentional errors, and malicious hacking attempts. In addition, maintaining a local ledger blockchain 424 on a memory associated with the host can provide a record of updates that can be generated as needed. In the case of updates from a global ledger blockchain (e.g., Figure 3 After the global block of the global ledger block chain 322 has been verified and added to the local ledger block chain 424, the circuit system may implement the updates contained in the payloads of, for example, 436-1, 436-4, and 436-5.

[0099] For example, the local ledger blockchain 424 may verify the global blockchain (e.g. Figure 3The circuit system may verify the global block 320-1 of ID_1 and add it to the local ledger blockchain 424 as a local block 421-1. After verification, the circuit system may execute the update 438-1 contained in the payload 436-1 of the local block 421-1. The authorized entity may push another update to the host and / or memory associated with ID_1, and thus the circuit system may receive a second global block (e.g., Figure 3 4), which may be verified by the circuit system and sequentially added as a local block 421-4 linked to the local block 421-1. The circuit system may check and compare the cryptographic hash of the freshness field, for example, the previous local block hash 433-4. If this verification and link in the local ledger block chain 424 is valid, the circuit system may execute the update 438-2 contained in the payload 436-4 of the local block 421-4. Using this method, the memory may continue to add global blocks as local blocks to the local ledger block chain 424, as described for local blocks 421-5, etc. In some instances, the host and / or memory associated with ID_1 may remove older portions of the local ledger block chain 424 to create empty spaces in the memory as the local ledger block chain 424 grows as more updates are generated by authorized entities.

[0100] For example, the host and / or memory may be a computing device of a vehicle with ID_1, and the local ledger block chain 424 may indicate an update to software and / or hardware components on the vehicle. The computing device may contain a threshold amount of immutable records that may be stored in the memory. In some instances, updates (e.g., 438-1, 438-2) are pushed from an authorized entity via a global block to update the software and / or hardware components of the computing device, and when the local ledger block chain 424 has reached a threshold, the circuit system may remove local blocks (e.g., older local blocks) from the local ledger block chain 424. The circuit system may remove older local blocks (e.g., 421-1) by executing firmware to change the root (e.g., the root of the consistency, the root of the Merkle tree, etc.) of the local ledger block chain 424, creating an empty space in the memory of the computing device for newer local blocks (e.g., 421-5). In this way, the circuit system can maintain control of the update when the local ledger block chain 424 adds a new local block.

[0101] Figure 5A An example of a pair of registers 514-1 and 514-2 for defining a secure memory array according to an embodiment of the present disclosure is shown, and Figure 5B A diagram showing a portion of a memory array 501 including a secure memory array defined with registers 514-1 and 514-2 according to an embodiment of the present disclosure. Registers 514-1 and 514-2 may be, for example, previously described in conjunction with Figure 2AThe registers 214-1 and 214-2 described above, and the secure memory array 501 may be, for example, previously combined with Figure 2A The memory array 201 described above. For example, Figure 5B As shown, the secure memory array 501 may include a plurality of physical blocks 507-0, 507-1, ..., 507-B of memory cells, each physical block including a plurality of physical rows 503-0, 503-1, ..., 503-R having a plurality of memory cell sectors, in a manner similar to that previously described in connection with Figure 1 A memory array 101 is described.

[0102] like Figure 5A As shown, register 514-1 can define the address of the security array (e.g., the address of the different parts of the security array), and register 514-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 514-1 can correspond to, for example, the starting point (e.g., the 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 514-2 can correspond to, for example, the ending point (e.g., the ending LBA) of the security array (e.g., the ending point of the different parts of the security array).

[0103] For example, Figure 5A As shown, registers 514-1 and 514-2 may define N pairs of values, where each corresponding pair includes an address value (e.g., addr) defined by register 514-1 and a size value (e.g., size) defined by register 514-2. Figure 5A In the example shown, Pair0 includes an address value addr0 and a size value size0 (eg, Pair0 = [addr0, size0]), Pair1 includes an address value addr1 and a size value size1 (eg, 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 ]). A pair of address values ​​may correspond to a starting point of a portion of a 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 that makes up the entire security array) may be given by the following formula: [addr0, addr0+size0]∪[addr1, addr1+size1]∪…∪[addr N,addr N +size N ].

[0104] The first pair of registers 514-2 defining a size value of zero may stop the definition of the security array. Figure 5A In the example shown, if the size value of Pair2 is zero, the secure array will be given by the following formula: [addr0, addr0+size0]∪[addr1, addr1+size1].

[0105] The security array instance defined by registers 514-1 and 514-2 (eg, all size values ​​defined by register 514-2 are non-zero) is as follows: Figure 5B For example, Figure 5B As shown, the address (e.g., LBA) associated with sector 505-0 of the memory array 501 is addr0, the address associated with sector 505-1 of the memory array 501 is addr0+size0, the address associated with sector 505-2 of the memory array 501 is addr1, the address associated with sector 505-3 of the memory array 501 is addr1+size1, and the address associated with sector 505-4 of the memory array 501 is addr0+size0. N , and the address associated with sector 505-5 of memory array 501 is addr N +size N Thus, the security array includes sectors (e.g., data stored in the sectors) 505-0 to 505-1, sectors 505-2 to 505-3, and 505-4 to 505-5. However, sectors of the memory array 501 located before sector 505-0 and sectors 505-1 to 505-2 of the memory array 501 are not part of the security array (e.g., the security array includes a subset of the array 501).

[0106] Figure 6 606 according to an embodiment of the present disclosure. The host 602 and the memory device 606 may be, for example, Figure 2A A host 202 and a memory device 206 are depicted.

[0107] A computing device can be started in stages using layers, where each layer identifies and loads subsequent layers and provides increasingly complex runtime services at each layer. A 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 6As shown, layer 0 ("L0") 651 and layer 1 ("L1") 653 are located within the host. Layer 0 651 can provide a firmware derived secret (FDS) key 652 to layer 1 653. 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 stable 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 host 602.

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

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

[0110] K L1 =KDF[Fs(s), hash(“immutable information”)]

[0111] 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:

[0112] FDS = HMAC-SHA256[Fs(s), SHA256("immutable information")]

[0113] Likewise, memory device 606 may transfer data to host 602 , as indicated by arrow 656 .

[0114] Figure 7 is a block diagram of an example process for determining several parameters according to an embodiment of the present disclosure. Figure 7is an example of determining parameters including an external public identifier, an external certificate, and an external public key, as shown by arrow 754, which are then sent to a memory device (eg, Figure 6 606) of layer 2 (e.g., layer 2 655). Figure 7 Layer 0 ("L0") 751 in corresponds to Figure 6 651 in FIG. 6 , similarly, 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.

[0115] The FDS 752 from Layer 0 751 is sent to Layer 1 753 and used by the Asymmetric ID Generator 761 to generate a Public Identifier (“ID lk public ”) 765 and private identifier 767. In the abbreviation “ID lk public ”, “lk” indicates layer k (layer 1 in this example), and “public” indicates that the identifier is publicly shared. The public identifier 765 is shown as shared by the arrow extending to the right and extending outside the host's layer 1 753. The generated private identifier 767 is used as a key input to the encryptor 773. The encryptor 773 can be any processor, computing device, etc. for encrypting data.

[0116] The host's layer 1 753 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 that is consistent with the host (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 the external private key). The external public key 769 can be input as an input (as “data”) to an encryptor 773. The encryptor 773 can generate a result K’775 using the input of the external private identity 767 and the external public key 769. The external private key 771 and the result K’775 can 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 can 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 can be associated with the identity of the host, such as by combining Fig. 9 Further described. In addition, the external public key (“KL1 public key ”) 783 can be transmitted to layer 2. Therefore, the host's public identification 765, certificate 781 and external public key 783 can be transmitted to layer 2 of the memory device.

[0117] Figure 8 is a block diagram of an example process for determining several parameters according to an embodiment of the present disclosure. Figure 8 Shows the generated device identification ("ID L2 public")866、Device Certificate ("ID L2 Certificate”) 882 and the device public key (“K L2 public key ”) 884 memory device (e.g., Figure 6 Layer 2 855 of the memory device 606 in.

[0118] like Figure 7 As described above, an external public key (“K L1 public key ”) 883 is used by the asymmetric ID generator 862 of the memory device to generate a public identifier (“ID lk public ”) 866 and private identifier 868. In the abbreviation “ID lk public ”, “lk” indicates layer k (layer 2 in this example), and “public” indicates that the identifier is publicly shared. The public identifier 866 is shown as shared by the arrow extending to the right and extending outside of layer 2 855. The generated private identifier 868 is used as a key input to the encryptor 874.

[0119] like Figure 8 As shown, the certificate verifier 847 uses the external certificate 881 and the external identifier 865 and the external public key 883. The certificate verifier 847 can verify the external certificate 881 received from the host (e.g., the host 602), and determine whether to accept or discard the data received from the host in response to the external certificate 881 being verified or not verified. Fig. 9 Describes further details of verifying external certificate 881.

[0120] Layer 2 855 of the memory device may include an asymmetric key generator 864. In at least one example, the 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 associated with the memory device (e.g., Figure 6The 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 input as an input (as “data”) to 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 can 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 can be associated with the identity of the memory device, such as by combining Fig. 9 In addition, the device public key (“K L2 public key ”)884 can be transmitted to Layer 1. Therefore, the public identification 866, certificate 882 and device public key 884 of the memory device can be transmitted to Layer 1 of the host.

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

[0122] 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 example shown, from a host (e.g., from Figure 6653 of the host 602 in the layer 1) provides a 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 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 as input to the secondary decryptor 987 together with the public identification, producing an output. The external public key 983 and the output from the decryptor 987 can indicate whether the certificate is verified by comparison as shown at 989, thereby producing 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, illegal devices that send illegal data can be detected and avoided. As an example, a hacker who sends data to be processed can be identified and the hacker data is not processed.

[0123] Fig.10 is a block diagram of an example process for verifying a signature according to an embodiment of the present disclosure. In an example where a device sends 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.

[0124] Memory device 1006 (eg, Figure 2A The memory device 206 in the embodiment may send data 1090 to the host (e.g., Figure 2A 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. At 1098, the host 1002 may verify the signature using the previously received data 1092 and the external public key 1069. 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.

[0125] Fig.111 is a block diagram of an example memory device 1106 according to an embodiment of the present disclosure. For example, the memory device 1106 may be a memory device 1106 previously described in conjunction with Figure 2A Memory device 206 is described.

[0126] like Fig.11 As shown, the memory device 1106 may include a plurality of memory arrays 1101-1 to 1101-7. The memory arrays 1101-1 to 1101-7 may be similar to those previously described in connection with Figure 1 The memory array 101 is described. In addition, Fig.11 In the example shown, 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.

[0127] like Fig.11 As shown, 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.

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

[0129] like Fig.11 As shown, 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.

[0130] like Fig.11 As shown, 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.

[0131] like Fig.11As shown, memory device 1106 may include an electronically 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.

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

[0133] like Fig.11 As shown, 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, such as the cryptographic hash of block 220 as previously described herein, and / or the golden hash for verifying 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.

[0134] Although specific embodiments have been shown 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 adaptations or variations of several embodiments of the present disclosure. It should be understood that the above description is provided in an illustrative and not 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 and the full scope of equivalents to which such claims are assigned.

[0135] In the foregoing detailed description, some features are grouped together in a single embodiment for the purpose of simplifying the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the disclosed embodiments of the disclosure must use more features than are explicitly recited 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 this detailed description, with each claim representing a separate embodiment on its own.

Claims

1. A device for using a memory as a local block in a local ledger block chain, comprising: Memory; as well as A circuit system configured to receive from the global ledger block chain a global block to be added to the local ledger block chain for verifying updates to non-user data stored in the memory, wherein: The global block to be added to the local ledger blockchain contains: a cryptographic hash of the current local block residing in said local ledger block chain; a cryptographic hash of the non-user data to be updated stored in the memory; and a payload of data for said updated non-user data stored in said memory; and the current local block in the local ledger block chain having a digital signature associated therewith, the digital signature indicating that the global block is from an authorized entity, wherein the digital signature includes a freshness field in the form of a hash of a previous global block in the global ledger block chain that was previously added to the local ledger block chain; comparing the freshness field to the cryptographic hash of the current local block residing in the local ledger blockchain to verify the update; and The cryptographic hash of the non-user data stored in the memory identifies the non-user data in the memory to be updated by the payload.

2. The apparatus of claim 1, wherein the local ledger blockchain is stored in a secure array defined by a pair of registers.

3. The apparatus of claim 1 , wherein the circuit system is configured to store the global block in the memory as part of the local ledger block chain.

4. The device of claim 1 , wherein the circuit system is configured to receive a plurality of global blocks from the global ledger block chain, and the circuit system is configured to determine whether the plurality of global blocks received by the circuit system from the global ledger block chain are relevant to the device.

5. The device of claim 4, wherein the circuit system is configured to avoid adding a global block to the local ledger blockchain when the global block is not relevant to the device.

6. The device of claim 4, wherein the circuit system is configured to sequentially add a global block to the local ledger block chain when a global block among the plurality of global blocks received from the global ledger block chain is relevant to the device.

7. The apparatus of claim 1, wherein the global block is added to the local ledger block chain when a previous local block field of the global block matches a current local block field in the current local block of the local ledger block chain.

8. The apparatus of any of claims 1-7, wherein the circuitry is configured to provide the update to a portion of code stored in a secure array in response to the circuitry verifying that the update is from the authorized entity.

9. The apparatus of claim 1, wherein: The memory comprises a memory cell array; The circuitry includes a pair of registers configured to define the array; and Wherein the pair of registers comprises: registers configured to define addresses of the array; and A register configured to define the size of the array.

10. An apparatus for using a memory as a local block in a local ledger block chain, comprising: Memory; as well as A circuit system configured to: Receive global blocks from the global ledger block chain; determining whether the global block is associated with the device; adding the global block to a local ledger blockchain for verifying updates to non-user data stored in the memory to be updated, wherein: The global block to be added to the local ledger blockchain contains: a cryptographic hash of the current local block residing in said local ledger block chain; a cryptographic hash of the non-user data to be updated stored in the memory; and a payload of data for said updated non-user data stored in said memory; and the current local block of the local ledger block chain has a digital signature associated therewith, the digital signature indicating that the global block is from an authorized entity, wherein the digital signature includes a freshness field, The freshness field is in the form of a hash of a previous global block in the global ledger blockchain that was previously added to the local ledger blockchain; comparing the freshness field to the cryptographic hash of the current local block residing in the local ledger blockchain to verify the update; and The cryptographic hash of the non-user data stored in the memory identifies the non-user data in the memory to be updated by the payload.

11. The apparatus of claim 10, wherein the circuit system further generates the digital signature based on the freshness field, and the current local block residing in the local ledger block chain is identical to the previous global block in the global ledger block chain.

12. An apparatus according to any one of claims 10 to 11, wherein the local ledger block chain comprises a plurality of local blocks associated with the host compiled in a sequential order.

13. The apparatus of any one of claims 10-11, wherein the local ledger blockchain is stored in a portion of the memory that is not accessible to users of the memory.

14. A system for using a memory as a local block in a local ledger blockchain, comprising: Memory; as well as A circuit system that generates a local ledger block chain for verifying updates to non-user data stored in the memory to be updated, wherein the local ledger block chain is composed of a global block from a global ledger block chain, wherein the global block includes: a cryptographic hash of the current local block residing in said local ledger block chain; and a cryptographic hash of the non-user data to be updated stored in the memory; and a payload of data for said updated non-user data stored in said memory; and the current local block of the local ledger block chain having a digital signature associated therewith, the digital signature indicating that the global block is from an authorized entity, wherein the digital signature includes a freshness field in the form of a hash of a previous global block in the global ledger block chain that was previously added to the local ledger block chain; comparing the freshness field to the cryptographic hash of the current local block residing in the local ledger blockchain to verify the update; as well as the cryptographic hash of the non-user data stored in the memory identifies the non-user data in the memory to be updated by the payload; as well as A host, wherein the host is configured to: receiving the local ledger blockchain from the memory; and The update to the non-user data stored in the memory is verified using the received local ledger blockchain.

15. The system of claim 14, wherein the host is a computing device of a vehicle and the local ledger blockchain indicates updates to software or hardware components on the vehicle.

16. The system of any one of claims 14-15, wherein when the local ledger block chain has reached a threshold, the circuit system removes a local block from the local ledger block chain by executing firmware to change a root of the local ledger block chain.

17. A system according to any one of claims 14 to 15, wherein when the circuit system determines that the freshness field included in the digital signature is an expected freshness field, the circuit system adds the global block as an immutable record to the local ledger block chain.

18. A system for using a memory as a local block in a local ledger blockchain, comprising: a host computer including a storage device; as well as A circuit system configured to: generating a local ledger blockchain for verifying updates to non-user data stored in the memory; receiving a global block from a global ledger blockchain, wherein the local ledger blockchain is composed of global blocks from the global ledger blockchain; adding the first portion of the global blocks to the local ledger block chain when a digital signature associated with each global block in the first portion of the global blocks is verified by the circuit system as being associated with the host, wherein the digital signature includes a freshness field in the form of a hash of a previous global block in the global ledger block chain that was previously added to the local ledger block chain; comparing the freshness field to a first cryptographic hash in the global block received from the global ledger block chain of a current local block residing in the local ledger block chain to verify the update; identifying the non-user data in the memory to be updated by the payload using a second cryptographic hash in the global block received from the global block ledger chain of the non-user data stored in the memory; as well as When the received second portion of the global block is not relevant to the host, the second portion of the global block is discarded.

19. The system of claim 18, wherein each global block in the first portion contains the freshness field, and wherein the freshness field of each of the global blocks in the first portion corresponds to a current local block of the local ledger block chain.

20. The system of any one of claims 18 to 19, wherein the global blocks of the first portion are added to the local ledger block chain in a sequential order and stored in the memory associated with the host.

Images