Non-volatile memory device, related method and system having regions with individually programmable secure access features

Abstract

The apparatus includes a plurality of regions, each region including a plurality of non-volatile memory cells, a permission store configured to non-volatilely store a permission value set including at least one permission value for each region, and an access control circuit configured to control access to each region according to the permission value for the region, the controlling including one or more of requiring authentication to access the region, encrypting data read from the region, and decrypting data for storage in the region. Related methods and systems are disclosed.

Description

Technical Field

[0001] Related Applications This application is an international application of U.S. non-provisional application No. 16 / 827,478 filed on Mar. 23, 2020, which claims priority and benefit under 35 U.S.C. § 119(e) of U.S. provisional patent application No. 62 / 878,404 filed on Jul. 25, 2019, the content of which is incorporated herein by reference.

[0002] Technical Field The present disclosure generally relates to non-volatile memory devices, particularly non-volatile memory devices having a plurality of regions each of which can have its own user-configured security attributes.

Background Art

[0003] Flash memory devices are widely used in electronic systems to non-volatily store important data, such as firmware for execution by a related processor and / or configuration data for a system. Thus, an important feature for non-volatile memory is the ability to securely store such values. Some NAND flash devices can include a replay protected memory block (RPMB). Such a feature can provide a secure section within the memory device, but this is limited to a region of limited size. Thus, secure access can be limited to one region.

[0004] Unlike NAND flash memory, NOR flash memory can offer higher granularity (i.e., byte-level access) in addition to faster access. Furthermore, many NOR flash memory devices have in-place execution (XIP) capabilities, which allows code to be executed directly from the memory device without needing to be loaded into system RAM. For these reasons, NOR devices can be a preferred non-volatile storage solution for firmware in many systems. However, conventional NOR flash memory devices offer few or no security options. [Brief explanation of the drawing]

[0005] [Figure 1] This is a block diagram of a system having a memory device with areas having individually programmable security features, according to one embodiment. [Figure 2] This is a block diagram of a system having a NOR-type non-volatile memory device equipped with multiple programmable non-volatile monotonic counters, according to one embodiment. [Figure 3] This figure shows access to a region key for a memory device equipped with a duplicator, according to one embodiment. [Figure 4] This figure shows access to a region key having a non-volatile index according to one embodiment. [Figure 5A] This figure shows a method for enabling or disabling manufacturer access to a memory device area according to an embodiment. [Figure 5B] This figure shows a method for enabling or disabling manufacturer access to a memory device area according to an embodiment. [Figure 5C] This figure shows a method for enabling or disabling manufacturer access to a memory device area according to an embodiment. [Figure 6]This is a flowchart of a method for erasing data in a memory device area in response to an invalid access attempt, according to one embodiment. [Figure 7] This is a block diagram of a memory device having regions with individually programmable security features, according to another embodiment. [Figure 8A] This figure shows an apparatus and method that, according to an embodiment, enables different types of security access to different areas of a memory device. [Figure 8B] This figure shows an apparatus and method that, according to an embodiment, enables different types of security access to different areas of a memory device. [Figure 8C] This figure shows an apparatus and method that, according to an embodiment, enables different types of security access to different areas of a memory device. [Figure 9A] This figure shows a communication method that may be included in the embodiment. [Figure 9B] This figure shows a communication method that may be included in the embodiment. [Figure 10] This figure shows the generation of a packet and its corresponding message authentication code (MAC) according to one embodiment. [Figure 11] This diagram shows packet encryption according to one embodiment. [Figure 12A] This figure shows an authenticated request packet to a memory device according to an embodiment. [Figure 12B] This figure shows an authenticated response to a memory device according to an embodiment. [Figure 13] This is a diagram of a non-volatile key indexing and storage structure for a memory device according to one embodiment. [Figure 14A] This figure shows the establishment of a session key for secure communication between a memory device and a host device according to the embodiment. [Figure 14B] This figure shows the establishment of a session key for secure communication between a memory device and a host device according to the embodiment. [Figure 15A]Flowchart of a method for secure access to a region of a memory device according to one embodiment. [Figure 15B] Flowchart of a method for secure access to a region of a memory device according to one embodiment. [Figure 16] Flowchart of a method for generating a session key for secure communication between a memory device and a host device according to one embodiment. [Figure 17A] Diagram showing a mutual authentication method between a host device and a memory device having firmware according to one embodiment. [Figure 17B] Diagram showing a mutual authentication method between a host device and a memory device having firmware according to one embodiment. [Figure 18] Diagram of a system comprising a memory device having regions that can be securely accessed by different devices and / or computing elements according to one embodiment. [Figure 19] Diagram of a memory array that may be included in an embodiment. [Figure 20] Diagram of a memory device according to one embodiment. [Figure 21] Diagram of an automotive-related system according to one embodiment. **DETAILED DESCRIPTION OF THE INVENTION**

[0006] According to an embodiment, a non-volatile memory device can include a plurality of different regions, and each region can be individually configured using different security features. The security features can include, but are not limited to, disabling a particular type of access (e.g., read, programming, or erase) to the region, or requiring that some or all of such access be subject to a security operation. The security operation can include, but is not limited to, authentication and encryption.

[0007] In some embodiments, the regions of the non-volatile memory device may have a NOR configuration.

[0008] In some embodiments, the non-volatile memory device may include one or more non-volatile monotonic counters that can be set by a user to generate one-time count values for security operations.

[0009] In some embodiments, short-lived keys can be generated using a duplicator that prevents keys from the key pool from being reused.

[0010] In some embodiments, a non-volatile index for each region may be used to access secure keys from such a key pool.

[0011] In some embodiments, the non-volatile memory device can authenticate the host device.

[0012] In the various embodiments hereinafter, similar members are referred to by the same reference numerals, where the leading digit corresponds to the figure number.

[0013] FIG. 1 is a block diagram of a system 100 according to an embodiment. The system 100 may include a memory device 102 that communicates with a host device 104 via a communication path 106. The memory device 102 may include an interface (I / F) 108, a command decoder 110, an access control circuit 112, a non-volatile memory section 114, a region configuration store 116, and a key store 118. The interface 108 can enable communication with the host device 104 via the communication path 106. The I / F 108 may be any suitable I / F, including but not limited to a parallel I / F, a serial I / F, or a wireless I / F. The communication path 106 can take a form suitable for the I / F 108. In some embodiments, the I / F 108 can process communication in packet form.

[0014] The command decoder 110 can decode commands received from the host 104. In some embodiments, the command decoder 110 can distinguish between read commands, programming commands, and erase commands. Furthermore, these commands may include or be accompanied by area identifiers. The area identifiers can identify a specific area (described in more detail below) located within the non-volatile memory section 114 that is the target of the command operation.

[0015] The access control circuit 112 can control access to different areas of the non-volatile memory section 114 according to the security characteristics of those areas. The access control circuit 112 can implement any suitable security algorithm, which may include one or more authentication and / or encryption methods.

[0016] The non-volatile memory section 114 may include one or more arrays of non-volatile memory cells organized into a plurality of regions 120-0 to 120-n. The regions (120-0 to 120-n) may have predetermined limitations or may be user-configurable. In some embodiments, the regions (120-0 to 120-n) may consist of flash memory cells in a NOR configuration. The memory cells may be addressable in relatively small sizes, such as bytes, words, or double words.

[0017] The region configuration store 116 can store configuration values ​​that can control access to regions (120-0 to 120-n) within the non-volatile memory section 114, and in some embodiments, can define the range of regions (120-0 to 120-n) within the non-volatile memory section 114. The region configuration store 116 may include non-volatile memory circuits, which may or may not be part of the non-volatile memory section 114. The values ​​stored in the region configuration store 116 may be stored securely and may only be accessible by predetermined procedures, which may include authentication or decryption. In the illustrated embodiment, access to the region configuration store 116 may be controlled by an access control circuit 112. Furthermore, the access control circuit 112 may read values ​​from the region configuration store 116 to determine whether access to the region (120-0 to 120-n) is permitted based on any access restrictions to that region.

[0018] The region configuration store 116 can store appropriate values ​​to establish the security characteristics of a region, but in the illustrated embodiment, the region configuration store 116 can store access restriction values ​​for each region (0 to n). As illustrated, the access restriction values ​​can define a specific authentication or encryption method. However, such values ​​can also restrict access according to the type of operation (e.g., read, program, erase). Thus, the access restriction values ​​can indicate whether a region (120-0 to 120-n) is readable, programmable, erasable, requires authentication, requires encryption / decryption, or any combination thereof. As described above, the regions (120-0 to 120-n) may be defined by the user. In the illustrated embodiment, the regions (120-0 to 120-n) may be defined by a range of values ​​(range 0 to range n) that can correspond to a physical address for each region (120-0 to 120-n). The physical addresses may be mapped to logical addresses understood by the host device 104 according to any appropriate method.

[0019] The keystore 118 can store key values ​​that can be used to control access to regions (120-0 to 120-n). The keystore 118 may include non-volatile storage circuits, which may or may not be part of the non-volatile memory section 114. Like the region configuration store 116, the keystore 118 may be able to securely store key values ​​and be accessible only by a predetermined procedure, which in the illustrated embodiment is accessible by the access control circuit 112. The access control circuit 112 may read key values ​​from the keystore 118 when determining whether a region (120-0 to 120-n) is accessible. The keystore 118 may store multiple key values ​​for each region (120-0 to 120-n). In some embodiments, such keys may be one-time keys or keys used a limited number of times, enabling the generation of short-lived session keys for transactions between the host device 104 and the memory device 102.

[0020] Figure 2 is a block diagram of system 200 according to another embodiment. System 200 may include a memory device 202, a host device 204, and a communication path 206, as shown in Figure 1. Figure 2 differs from Figure 1 in that the host device 204 may have a function 222 that can use count values, and the memory device 202 may have a non-volatile monotonic counter (NMC) section 226. The NMC section 226 may include one or more NMCs (228-0 to 228-i). Each NMC (228-0 to 228-i) may generate a non-volatile, non-repeating count value or a substantially non-repeating count value. A substantially non-repeating count value may be a count value that is repeated only after its wrap-around (exceeding a maximum value that is reset to a minimum value). Each NMC (228-0 to 228-i) may generate a different count value each time it is activated. The NMCs (228-0 to 228-i) may be individually configurable according to NMC configuration values ​​230. Such configuration values ​​can modify any appropriate characteristics of the NMC. Such characteristics may include, but are not limited to, the counting direction (e.g., increment / decrement), the counting span (e.g., the difference between each count), the counting value size, the counting value format, the starting counting value, and which operations trigger the activation of a new counting value (e.g., a new communication session). The NMC configuration values ​​230 may include non-volatile memory circuits, which may or may not be part of the non-volatile memory section 114.

[0021] The count values ​​generated by NMC(228-0~228-i) may be used for any appropriate function, including functions inside and outside memory device 202. Two of the many possible functions for the count values ​​are shown in Figure 2. As a first example, the count values ​​from NMC(228-0~228-i) may be used by an authentication function to block a replay attack from host device 204, or a replay attack that appears to be from host device 204. The transfer of the count values ​​for such a function is shown as 232-0. The count values ​​are then securely transmitted to host device 204 (or another device) and may be used to generate a message authentication code (MAC), etc. As a second example, one or more count values ​​from NMC(228-0~228-i) may be transmitted to host device 204 for use by function 222 (i.e., a function other than blocking replay attacks from the host). The transfer of the count values ​​for such a function is shown as 232-1. Such a forwarding 232-1 may include a packetized and / or encrypted count value. Function 222 may be any suitable function, and is just one example, it may be used for communication with another device (not shown) to the host device 204.

[0022] Figure 3 is a block diagram illustrating a region key access operation according to one embodiment. Figure 3 shows a portion of a memory device 300, which includes a deprecator 334, a keystore 318, and a non-volatile memory section 314. The non-volatile memory section 314 may include a plurality of regions 320-0 to 320-n, which can take any of the forms described herein or equivalent thereto.

[0023] The keystore 318 can store multiple keys (m+1 keys) corresponding to each region. Therefore, it is understood that keys "region_0_key0" to "region_0_keym" correspond to regions 0 320-0. In the illustrated embodiment, keys are accessed via the deprecator 334. The deprecator 334 can prevent key values ​​for a given region from being repeated. Therefore, with each key access operation 336, the deprecator 334 will disable access to that key. For example, in the case of accessing region 0 320-0, the value region_0_key0 has already been used and is no longer available for access operations to region 0 320-0. Furthermore, the values ​​region_n_key0 and region_n_key1 have already been used and are no longer available for access operations to regions 320-n.

[0024] The capabilities shown in Figure 3 enable the generation of short-lived keys that are used in a single communication session and then discarded, providing an extremely high level of security.

[0025] Figure 4 is a block diagram illustrating a region key access operation according to another embodiment. Figure 4 shows a portion of a memory device 400 including an index store 438, a key store 418, and a non-volatile memory section 414. The non-volatile memory section 414 may include a plurality of regions 420-0 to 420-n as described herein or equivalent thereto.

[0026] The keystore 418 can store multiple keys "region_key0" to "region_keyk", and any of these keys can be assigned to any region (420-0 to 420-n). In the illustrated embodiment, keys are accessed via the indexstore 438. The indexstore 438 can store multiple index values ​​corresponding to each region (420-0 to 420-n) (m+1 in this case). Therefore, it is understood that "index_region_0_key0" to "index_region_0_keym" correspond to region 0 420-0. The indexstore 438 may include a non-volatile memory circuit, which may or may not be part of the keystore 418, and can safely store index values.

[0027] The capabilities shown in Figure 4 provide high flexibility in assigning keys to regions (420-0 to 420-n), which includes the ability to assign more keys to one region than another, and to leave some regions without assigning any keys.

[0028] Some embodiments may include various methods and circuits for assigning key values ​​to specific areas of a non-volatile memory device, while some embodiments may also include selectively enabling or disabling manufacturer-known keys (i.e., RMA keys) to access areas by the manufacturer.

[0029] For memory device manufacturers, access to the protected areas of devices returned by customers or others can be valuable. Such access can be useful for repairing the device, retrieving data for customers, and performing failure analysis. At the same time, customers may consider certain data stored within the device to be of high value and therefore want such data to remain secure after being programmed into the memory device.

[0030] Figures 5A to 5C illustrate how manufacturer access to areas of a non-volatile memory device may be enabled or disabled. Figure 5A is a flowchart of method 540 according to one embodiment. Method 540 may include a customer designation of one or more areas that are not accessible to the manufacturer 540-0. These areas may be areas of a non-volatile memory device as described herein in embodiments or equivalent. Such action may be used to ensure that confidential information is not accessed when the memory device is returned to the manufacturer or when it is returned. A key known to the manufacturer (e.g., an RMA key) may be disabled by the customer for the areas thus designated 540-1. Such action may include the customer erasing, overwriting, or otherwise disabling a key known to the manufacturer for the designated areas. The key may be accessed for such modification according to any embodiment shown herein or equivalent.

[0031] Figure 5B is a flowchart of method 542 according to another embodiment. Method 542 may include the creation of a manufacturer code by the customer for areas of a memory device 542-0. Those areas, which will be accessible by the manufacturer, may then be programmed with the generated code 542-1. The manufacturer code generated by the customer may then be sent to the manufacturer 542-2. In this way, the areas accessible by the manufacturer may be completely controlled by the customer.

[0032] Figure 5C shows a diagram of the memory section before and after a programming operation to restrict manufacturer access. Figure 5C shows the initial non-volatile memory section 514 having regions 520-0 to 520-n. The non-volatile memory section 514 can take any form disclosed herein or equivalent. Before the key programming operation, regions (520-0 to 520-n) may have security features not specified with respect to manufacturer access. Next, Figure 5C shows the non-volatile memory section 514' after the key programming operation. As shown, the access key for region 0 520-0 does not include any manufacturer key (i.e., there is no RMA key). Therefore, in the corresponding memory device or system returned to the manufacturer, the data stored in this region is inaccessible to the manufacturer.

[0033] Some embodiments may also include memory devices with security features that can erase or otherwise make data unreadable if an invalid access attempt is made to a region (for example, by a bad key or credentials). Figure 6 is a flowchart of such a method 646 according to one embodiment. Method 646 may include determining whether an access attempt has been made to a region by a bad key or credentials 646-0. Such an action may include an attempt to access one of several regions of the memory device. A bad key or credentials may include, but is not limited to, any of the following: an expired key (for example, due to deprecation), a key that does not match a valid key for this region, an intermediate key that does not produce a usable final key, or an authentication code that does not decrypt to a valid result. Optionally, Method 646 may return a warning in response to the attempted access 646-1. In response to an invalid access attempt (or optionally a continuation of an invalid attempt), Method 646 may erase, overwrite, or otherwise prevent the data in the region from being accessed 646-2. In other embodiments, this may include locking access to this area via an access circuit or the like (for example, by specifying an area that is unreadable, unprogrammable, or unerasable).

[0034] In an alternative embodiment, the method may perform actions as shown in 646-2 in response to the manufacturer's use of a manufacturer access code (i.e., an RMA code).

[0035] Referring to Figure 7, a memory device 702 according to another embodiment is shown in a block diagram. In some embodiments, the memory device 702 may be a more detailed version of any of the memory devices shown in Figures 1 to 4. The memory device 702 may include a NOR flash array 714, a memory interconnect (I / C) 748, a diagnostic circuit 750, a safe boot circuit 752, an I / F and data CRC circuit 708, a reset circuit 754, an ECC circuit 756, an array configuration circuit 716, an authentication / cryption (auth / crypt) circuit 724, a counter circuit 726, a secure boot circuit 758, a keystore 718, a packet buffer 760, a processor section 762, and a serial communication controller 764. The NOR flash array 714 may include secure areas 714-0, 714-1, and a general-purpose area 714-2. The secure areas 714-0 / 1 may include areas that can be programmed using different access / security features described herein and equivalent thereto. Such security features may include requiring authentication and / or encryption. Secure areas 714-0 / 1 may be programmed for access types (read, programming, and erasing permitted or not permitted). General-purpose areas 714-2 may be areas that do not contain security features. In some embodiments, various sizes / ranges of areas 714-0 / 1 / 2 may be programmable. Furthermore, area types 714-0 / 1 / 2 may have default settings that can be changed by programming area access values ​​(i.e., any general-purpose area 714-2 or all general-purpose areas 714-2 may be programmable to become secure areas).

[0036] The memory I / C 748 can interconnect various parts of the memory device 702 and may include any suitable bus. The diagnostic circuit 750 may include a circuit for determining the functionality of the memory device 702 and, in some embodiments, may include one or more serial test access ports (e.g., JTAG standard). The safe boot circuit 752 can enable the memory device 702 to be powered up into a state with limited capabilities. The I / F and data CRC circuit 708 can provide an interface for the memory device, which includes any of those described herein. In some embodiments, this interface may be a packet processing interface. The I / F and data CRC circuit 708 may also perform CRC operations on received data to determine whether the data is corrupted. The reset circuit 754 can enable reset operations on the memory device 702, which include those that respond to commands, power-on, or other predetermined conditions. The ECC circuit 756 can perform error detection and error correction on data values ​​received via the interface (e.g., 708) by the ECC codes contained in the received data.

[0037] The array configuration circuit 716 can store configuration data for areas of the NOR flash array 714, including secure areas 714-0 / 1. Such configuration data may include any configuration data described herein and equivalent thereto, which includes physical address data, access type permissions, keys or indices to keys for defining the range of areas. The array configuration circuit 716 may include non-volatile memory circuits for storing such values.

[0038] The auth / crypt circuit 724 may include circuitry for performing authentication and / or cryptographic operations on transactions to the memory device 702. In some embodiments, such operations may access the keystore 718 to obtain a key value based on region identification (i.e., a value that identifies a particular region of the NOR flash array 714). The auth / crypt circuit 724 may also access the counter circuit 726 to read a count value for such operations. The counter circuit 726 may include one or more NMCs that can be configured as described herein or equivalently.

[0039] The secure boot circuit 758 can enable the memory device 702 to authenticate the requesting device based on a pre-established shared secret value. Furthermore, the secure boot circuit 738 can generate code values ​​specific to the memory device 702 and specific to the firmware stored on the memory device.

[0040] The keystore 718 can securely store key values ​​relating to security-related operations and can take any form disclosed herein or equivalent. The packet buffer 760 can buffer packets received via the I / F 708 for processing by the memory device 702.

[0041] The processor section 762 may include one or more processors for performing various operations of the memory device 702, including security-related operations. In some embodiments, the processor section may include a lower-power processor, such as a processor with a reduced instruction set. The serial communication controller 764 can control serial communication with the memory device 702 according to any suitable protocol or standard, which includes, but is not limited to, SPI, serial SPI, quad SPI, or HyperBus®.

[0042] Figure 8A shows a user-defined partitioning of a non-volatile array according to one embodiment. Figure 8A shows a user array portion 866 which may be part of a non-volatile memory array section of a memory device, including those disclosed herein and equivalents. In some embodiments, the user array portion 866 may include a NOR flash array. The user array portion 866 can be organized into a plurality of different regions 820-0 to 820-n. As in the case of other embodiments herein, the regions may have a predetermined size or a user-defined size.

[0043] Access to each region (820-0 to 820-n) may be configured by the user. A value may be assigned to each region (820-0 to 820-n). Based on this value, the region may be accessed in the conventional manner or may require secure access. In the illustrated embodiment, if the "key_type" value is "0", the region may be configured for conventional access. If the "key_type" value is "1", the region may be configured for secure access. Therefore, regions 0, 1, and 2 (820-0, 820-1, 820-2) may be secure access regions 814-0, while regions 3, 4, and 5 (820-3, 820-4, 820-5) may be conventional access regions 814-2.

[0044] Figure 8B is a table showing region type values ​​that may be used to establish region access types according to one embodiment. The configuration in Figure 8B should be understood as illustrative and not interpreted as limiting. In the table in Figure 8B, the column REGION_KEY_TYPE provides a general description of the region type defined by the value. The column KeyType# indicates the key number assigned to the access type and may correspond to the values ​​shown in Figure 8A. For regions with KeyType#=0, no key is required to access this region. Furthermore, this region is not considered part of the user array (e.g., it is not logically mapped to the user array address space that defines regions programmed to be secure). In contrast, for regions with KeyType#=1, access may require knowledge of a stored key shared between the memory device and another device (e.g., the host device). Furthermore, the session key may be used to generate a Message Authentication Code (MAC) for cryptographic and / or authentication operations.

[0045] The remaining column is divided into two parts: “Normal Mode” and “Encryption Mode”. Normal Mode corresponds to access without security features, including read operations, programming operations, and erase operations. Encryption Mode describes three different security features of the area, which include “Authenticated Lock / Unlock,” “Authenticated Read / Programming / Erase,” and “Encrypted Read / Programming / Erase.” “Authenticated Lock / Unlock” indicates that the area requires an authenticated request to lock and unlock access to this area. Such an authenticated request may be generated by another device (e.g., a host device) that has knowledge of a valid key for this area, and in some embodiments, a valid count value may also be generated (e.g., a count generated by an NMC on a memory device). “Authenticated Read / Programming / Erase” indicates that the area requires an authenticated request to perform a read operation, programming operation, or erase operation on this area. “Encrypted Read / Programming / Erase” indicates that the area requires encryption and decryption in access operations to this area. Such encryption and decryption may utilize a valid key for this domain and, in some embodiments, a valid count value.

[0046] Figure 8C is a table showing how a secure area can have additional values ​​that define the types of access permitted to the area. In the table in Figure 8C, the column "Allowed Type" describes the type of restriction. The column "Access #" assigns a numerical value to the type of access restriction. As in the case of Figure 8B, the remaining column is divided into two parts: "Normal Mode" and "Encryption Mode". If the Allowed Type is "Unrestricted", in normal mode, standard read, programming, and erase operations are permitted. In encryption mode, authenticated read, programming, and erase operations are permitted, but encrypted operations are not. If the Allowed Type is "READ_ONLY", in normal mode, standard read operations are permitted, but programming and erase operations are not. In encryption mode, authenticated read, programming, and erase operations are permitted, but encrypted operations are not. If the Allowed Type is "WRITE_PROTECTED", in normal mode, standard read operations are permitted, but programming and erase operations require that the area be unlocked first. In encrypted mode, authenticated read, program, and erase operations are permitted, but encrypted operations are not. When the permission type is "READ_WRITE_PROTECTED", in normal mode, read, program, and erase operations require the area to be unlocked first. In encrypted mode, authenticated read, program, and erase operations are permitted, but encrypted operations are not.When the permission type is "ENCRYPTED_ONLY", in normal mode, read operations, programming operations, and erase operations (i.e., unencrypted operations) are not permitted. In encrypted mode, authenticated read operations, programming operations, and erase operations are not permitted, but encrypted read operations, programming operations, and erase operations are permitted.

[0047] Naturally, the examples in Figures 8A to 8C are understood to be illustrative. According to alternative embodiments, the degree of permission granularity can be greater or less. For example, there may be access types that require encrypted read or programming operations and authenticated erase operations.

[0048] Some embodiments may include a memory device that receives and processes requests in any suitable form, but in some embodiments, the memory device (and its corresponding system) may receive and process requests in packet form. Figures 9A and 9B illustrate packet formats according to embodiments. Figure 9A is a diagram of a write (i.e., program) packet 968 according to one embodiment. The write packet 968 may include a command field 968-0, a target address field 968-1, and a write data field 968-2. The command field 968-0 may include a bit value that defines a command for processing by a command decoder in the memory device. In the illustrated embodiment, the command has a hexadecimal value F2h, but such a value should not be interpreted as limiting. Furthermore, the packet 968 may be received on an SPI interface, but this should not be interpreted as limiting. The packet 968 can be received on any suitable interface. The target address field 968-1 may indicate the location where the data is written (e.g., programmed). In some embodiments, the target address field 968-1 may also directly or indirectly identify the region on which the write operation is performed. In the direct case, the target address field 968-1 may include a subfield (i.e., region number) that identifies the region. From this region number, the memory device can determine which security restrictions, if any, are present in this region and ensure that the write request satisfies such restrictions. In the indirect case, the memory device can decrypt the target address to determine the target region. The write data field 968-8 may include the write data to be written to the memory device. The write data may be encrypted if required by the region security value, as shown in other embodiments herein. Furthermore, packet 968 may include a MAC in the case of access to a target region requiring authentication.

[0049] Figure 9B shows a read packet 970 according to one embodiment. The read packet 970 may include a command field 970-0 and a target address field 970-1. The command field 970-0 may include a bit value defining a command, which in the illustrated embodiment has a hexadecimal value F1h. The packet 970 can be received on an SPI interface, but the interface and specific bit values ​​should not be interpreted as limitations. The target address field 970-1 can indicate the location from which data is read, but also allows for direct or indirect identification of the area in which the read operation is performed.

[0050] If read packet 970 is valid, after a latency period 972, the memory device can output (or make available for retrieval) read data 974 from the target address location.

[0051] Figure 10 shows an authenticated packet 1076 according to one embodiment. The authenticated packet 1076 may include several fields. The command code response field 1076-0 may indicate the response type, and in the illustrated embodiment, this may be a 2-byte value. The result field 1076-1 may indicate the result from the received request, and in the illustrated embodiment, this may be a 2-byte value. The size field 1076-3 may indicate the size of the packet (e.g., the size of the payload), and in the illustrated embodiment, this may be a 2-byte value. The counter field 1076-4 may provide a count value, such as one generated by the NMC, and in the illustrated embodiment, this may be an 8-byte field. The nonce field 1076-5 may provide an encrypted nonce value, and in the illustrated embodiment, this may be a 16-byte value. The data field 1076-6 (which may be optional depending on the response type) may provide data related to the response (e.g., read data), and in the illustrated embodiment, this may be up to 512 bytes. MAC fields 1076-7 can provide a MAC for response, which may be a 64-byte value in the illustrated embodiment. The MAC may be generated using any suitable authentication routine and may use a domain key value (e.g., a secret key or other security key assigned to the domain corresponding to the operation). In Figure 10, the MAC may be generated using a hash-based authentication code (HMAC) algorithm 1080, such as HMAC-SHA2 or HMAC-SHA3, which are just two of many possible examples. The HMAC algorithm 1080 can utilize fields 1076-0 to 1076-6 and session key 1078 to generate the MAC for fields 1076-7. The session key 1078 may be generated using a domain-specific key, which allows authentication based on a key specific to the domain being accessed.

[0052] Figure 11 shows a packet encryption operation according to one embodiment. The operation can take an unencrypted packet 1182 and generate an encrypted packet 1182E. The unencrypted packet 1182 may contain fields as shown in Figure 10, which include a command code response field 1182-0, a result field 1182-1, a size field 1182-3, a counter field 1182-4, a nons field 1182-5, a data field 1182-6, and a MAC field 1182-7. In the illustrated embodiment, such fields may have the same byte size as the byte size in Figure 10.

[0053] To generate an encrypted packet 1182E, the data for the packet may be encrypted and then transmitted as an encrypted payload. In the illustrated example, the encryption algorithm 1188 can encrypt fields 1182-0 to 1182-6 using the session key 1178, initial value 1184, and counter value 1186. The encryption algorithm 1188 may be any suitable algorithm, such as AES-GCM or AES-CBC, which are just two of many possible examples. The encryption operation can generate encrypted data for the encrypted data field 1182-6E, and similarly generate the resulting tag bit for the tag field 1182-7E. The session key 1178 may be generated using a region-specific key, as in the case of Figure 10. Thus, encryption authentication can be performed based on the region-specific key being accessed.

[0054] Figures 12A and 12B show a request packet and a corresponding response according to one embodiment. In particular, Figures 12A and 12B show a program request and response. However, from the description of these packets, those skilled in the art will understand the request and response packets for other functions, such as read operations or erase operations.

[0055] Figure 12A shows an authenticated request packet 1284, including the following fields. The command code field 1284-0 may indicate an operation (in this case, a programming operation). In the illustrated embodiment, this field may be a 2-byte field having the hexadecimal value 0004h and may occupy byte location [1:0]. The address field 1284-1 may indicate the target address for this command. In the illustrated embodiment, this field may be a 4-byte field and may occupy byte location [5:2]. The size field 1284-2 may indicate the size of the packet data (in bytes), and in the illustrated embodiment, this may be a 2-byte field occupying byte location [7:6]. The data field 1284-3 may contain data for the associated operation (in this case, data to be programmed into the area). In the illustrated embodiment, this field may be up to 512 bytes and may occupy byte location [size+7:8], where size is the size value. The MAC field 1284-4 can store a MAC for an authentication operation. The MAC is generated by the requesting device (e.g., the host device). In the illustrated embodiment, this may be a 64-byte field and may occupy byte locations [size+71:size+8].

[0056] Refer to Figure 12A. This figure shows the values ​​used to generate the MAC. As shown, the authentication algorithm, in this case the HMAC algorithm, can use the region_session_key, command code (field 1284-0), address (field 1284-1), data (field 1284-3), and COUNTER value. The region_session_key may be a value specific to the region being accessed (in this case, the region where the data is programmed). The COUNTER value may be a one-time count value, such as one generated by the NMC. Therefore, the COUNTER value is included in the MAC but is not transmitted in the packet. In this way, authentication can be made region-dependent.

[0057] Figure 12B shows an authenticated response 1286 including the following fields. Response field 1286-0 may indicate the response to the requested operation (in this case, the display is the response to the program request). Result field 1286-1 may indicate the result of the request (e.g., authentication of programming success, programming failure, or failure). MAC field 1286-2 may store the MAC generated by the memory device. The authentication algorithm, in this case the HMAC algorithm of the requesting device, can utilize the region_session_key, response value (field 1286-0), result value (field 1286-1), and COUNTER value. The COUNTER value may be a one-time count value, such as one generated by the NMC.

[0058] Figure 13 is a diagram of a key storage and access architecture for a memory device 1302 according to one embodiment. The memory device 1302 can take any form disclosed herein or equivalent thereto. The disclosed architecture may be one particular embodiment of the architecture shown in Figures 3 and / or 4.

[0059] The memory device 1302 may include a region key configuration section 1392 and a key storage section 1388. It is assumed that the memory device also includes eight non-volatile storage areas that can be configured to provide secure access (e.g., using authentication or encryption) by using a secret key. Both sections 1392 and 1388 may include non-volatile circuits to store values ​​and maintain state (e.g., the state of the duplicator).

[0060] The region key configuration section 1392 may include region key indexes 1338 and backup keys 1394-0 to 1394-7. The region key index 1338 contains a set of index values ​​for each region. In the illustrated labeling method, region key indexes "region_key 0.0 index" to "region_key 0.7 index" are eight indices for region 0, region key indexes "region_key 1.0 index" to "region_key 1.7 index" are eight indices for region 1, and so on. Each region key index may be programmed to point to a secret key in the key storage section 1388. Access to each group of indices can be controlled according to the corresponding backup key (1394-0 to 1394-7). When a secret key is accessed for a region, the corresponding backup keys (1394-0 to 1394-7) may be modified, thereby ensuring that the next index from this group will be different from the currently used index (and therefore the next key will also be different). In the illustrated embodiment, each backup key (1394-0 to 1394-7) may have eight values ​​corresponding to each region index of its corresponding region, but this should not be interpreted as an limitation.

[0061] The key storage section 1388 may include a secret key storage 1318 and a device key storage 1390. The secret key storage 1318 may contain multiple secret keys that can be assigned to any user-defined secure region by programming the region key index 1338. Figure 13 shows 64 secret keys ("secret_key 0" to "secret_key 63"), which may allow 8 keys per region, but this should not be interpreted as an limitation. The memory device may contain more or fewer keys than 64. Furthermore, each region may be assigned a different number of secret keys. Each region index ("region_key 0.0 index" to "region_key 7.7 index") may be configured to point to any secret key ("secret_key 0" to "secret_key 63"). Such a configuration of pointing can take any suitable form, including, but not limited to, pointing to register locations and / or address locations storing the secret keys.

[0062] In addition to storing secret keys for user-defined secure access to the memory area, the key storage section 1388 may also secure secret keys for other functions in the device key storage 1390. In the illustrated embodiment, the device key storage 1390 may store a master_key, an SB_secret key, and an rma_key. The master_key may be a unique key to the memory device and may be known to the host device enabling the authentication operation. The rma_key may enable the manufacturer to access the device. In some embodiments, the rma_key may enable global access to the device. However, as described herein, the rma_key may be assigned on a region-by-region basis. The SB_secret may be a secure boot secret key for enabling a boot operation that can authenticate the memory device 1302 and the firmware stored in the memory device 1302.

[0063] While several embodiments may use any suitable security process to control access to individual areas of the memory device, a specific embodiment is described here. Figures 14A and 14B show request and response packets for generating a session key according to one embodiment. The session key may be used to generate a MAC for an authentication process and / or to encrypt data in an encryption process. The session key may be generated together with an area key. Thus, the session key may be unique for the area being accessed. In this way, communication with the host device can be restricted to a specific area (or more areas) of the memory device.

[0064] Refer to Figure 14A. A request packet for creating a session key may contain six fields. The command code field may indicate the operation (in this case, a request to create a session key). In the illustrated embodiment, this field may be a two-byte field with the hexadecimal value 000Ah and may occupy byte location [1:0]. The algorithm field may indicate the type of algorithm to be used. In the illustrated embodiment, this field may be a two-byte field and may occupy byte location [3:2]. Furthermore, a value of 0000h may indicate the HMAC authentication algorithm for generating the MAC value. A value of 0001h may indicate EDCH P-256 type encryption, and a value of 0002h may indicate EDCH 25519 type encryption. The address field may indicate the target area of ​​the session. In the illustrated embodiment, this field may be a two-byte field and may occupy byte location [5:4]. The nonce field may store the nonce value generated for the session. In the illustrated embodiment, this field may be a 16-byte field and may occupy byte location [21:6]. The data field may be empty (in the case of an initial request) or may contain a host intermediate key for transmission to the memory device. In the latter case, the data field may be a 32-byte field occupying byte location [53:22]. The MAC field may store the MAC for the request. In the illustrated embodiment, this may be a 64-byte field and may occupy byte location [85:22] or [117:54] depending on whether or not it contains a host intermediate key.

[0065] We will now refer to Figure 14A. Here, we describe the generation of specific values ​​in the creation of a session key. As shown in the fifth row of Figure 14A, in the case of the HMAC algorithm, the MAC may be generated by the host device, which comprises an HMAC algorithm using region_key (a secret key for the region indicated in the address field), command code, algorithm code, region number, nonce value, and command counter value. The command counter value may be a count value provided by the NMC in the memory device being accessed. Furthermore, region_session_key may be generated by an HMAC algorithm using region_key, command code, region number, nonce value, and command counter value.

[0066] As shown in the last row of Figure 14A, in the case of an elliptic curve Diffie-Hellmann (ECDH) type algorithm, the MAC may be generated by the host device, which comprises an HMAC algorithm using region_key, command code, algorithm code, region number, nonce value, and host intermediate value. The region_session_key may be generated by an ECDH algorithm using the host intermediate value received from the memory device being accessed and the device initial value (device_dh_initial).

[0067] Refer to Figure 14B. The response packet for creating a session key may contain four fields. The response field may indicate the response type (in this case, a response to a request to create a session key). In the illustrated embodiment, this field may be a 2-byte field with the hexadecimal value 0A00h and may occupy byte location [1:0]. The result field may indicate the result of this request (e.g., successful, failed). In the illustrated embodiment, this field may be a 2-byte field and may occupy byte location [3:2]. The data field may be empty or may contain an intermediate device key for transmission to the host device. In the latter case, the data field may be a 32-byte field and may occupy byte location [35:4]. The MAC field may store the MAC for the response. In the illustrated embodiment, this may be a 64-byte field and may occupy byte location [67:4] or [99:36] depending on whether or not it contains an intermediate device key.

[0068] Refer to Figure 14B. Here, we describe the generation of specific values ​​for the response to create a session key. As shown in the fifth row of Figure 14B, in the case of the HMAC algorithm, the MAC may be generated by the memory device, which comprises an HMAC algorithm using region_key, response code, result value, and command counter value. In the case of the ECDH algorithm, the MAC may be generated by an HMAC algorithm using region_key, response code, result value, device intermediate value, and command count value.

[0069] The embodiments described above have described various methods in relation to the device and system, but here we will describe a specific method in relation to a flowchart. Figures 15A and 15B are flowcharts showing a method 1596 for accessing a non-volatile storage area of ​​a memory device, where each area may be programmed with different security features. Method 1596 may include receiving a packet in the memory device 1596-0. Such action may include receiving the packet via any suitable interface, and in some embodiments, it may include receiving the packet via a serial interface. The command code field of the packet may be decoded by the memory device 1596-1. Such action may include any suitable command decoding operation, and in some embodiments, it may include reading a predetermined location in a buffer containing the packet. Method 1596 may determine whether a non-volatile area is indicated 1596-2. Such action may include decoding an address value or detecting an area number field in the packet, which are just two of many examples. If no domain number is specified ("No" from 1596-2), method 1596 may execute the command and, if necessary, generate and transmit (or store for readout) the response 1596-4.

[0070] If a region number is provided (yes, from 1596-2), method 1596 may determine whether the region has access restrictions 1596-3. Such action may include any appropriate reference to a configuration value, and in some embodiments may include accessing a secure non-volatile storage location containing a bit value that identifies a security configuration for the identified region. If the non-volatile region is not restricted (no, from 1596-3), method 1596 may execute a command to generate a response 1596-4 (for example, by performing a conventional read, programming, or erase operation on the region).

[0071] If the non-volatile area is subject to access restrictions (yes, from 1596-3), method 1596 can generate a session key having an area key and a monotonic count value (1596-5). Method 1596 can also determine whether the area requests encryption (1596-6). If the area requests encryption (yes, from 1596-6), method 1596 can decrypt the packet data using the session key (1596-7).

[0072] Method 1596 can determine whether the MAC of the received packet is valid or not 1596-8. If the MAC is not determined to be invalid (for example, if the decoded values ​​do not match), Method 1596 can then make a predetermined bad authentication response 1596-9. A bad authentication response can include any appropriate response, including no response at all. If the MAC is determined to be valid (yes from 1596-8), Method 1596 can perform various operations depending on the access type 1596-10. In the illustrated embodiment, the access types may include read, program and erase.

[0073] In Figure 15A, the circled letters A, B, C, and D indicate the corresponding connections in Figure 15B.

[0074] Refer to Figure 15B here. In a read operation, method 1596 may include reading data from a target area 1596-11.

[0075] In a programming operation, method 1596 can determine whether encryption is requested 1596-15. If encryption is requested (yes, from 1596-15), the packet data can be decrypted using the session key 1596-16. Program data can then be programmed into the target non-volatile area at the address indicated by the packet 1596-17. Such actions may include programming in any suitable manner, and in some embodiments, may include erasing a portion of the area and then selectively programming the bits of the erased portion according to the program data.

[0076] In an erase operation, method 1596 may erase the area indicated by the packet 1596-19.

[0077] After the indicated read, programming, or erase operation is completed (or if it cannot be completed), a response can be generated on the corresponding MAC 1596-18. The response may indicate the result of the indicated operation. In the case of a read operation, the response packet may contain the read data. Method 1596 can determine whether the accessed nonvolatile area requests encryption 1596-20. If encryption is requested (yes, from 1596-20), the response data can be encrypted 1596-21. The response may be transmitted to the requesting device (e.g., the host) or stored for subsequent retrieval by the requesting device 1596-22. In some embodiments, the response may take the form of a packet.

[0078] Figure 16 shows a method 1698 for generating a session key according to one embodiment. Method 1698 shows actions that can be performed by the host 1604 and actions that can be performed by the memory device 1602.

[0079] Method 1698 may include host 1604 generating a private key 1698-0. The host may compute a host intermediate key using the private key 1698-1. In some embodiments, the host intermediate key may be a key generated by an EDCH algorithm using a host private key and parameters known to both host 1604 and memory device 1602. Host 1604 may then generate a request 1698-2. Such a request may include a region number, the host intermediate key, and a MAC generated with the region key and count value for the target region. In some embodiments, the data in the request may be encrypted. A session request may be sent to the memory device 1698-3. Such an action may include any suitable method, which includes both wired and wireless carriers. In some embodiments, the request may be transmitted via a wired serial connection in packet form.

[0080] The memory device 1602 may determine whether the region key value received in the request matches the secret key stored for that region 1698-4. Such action may include decrypting the MAC in the request for the purpose of deriving the region key. If the received region key does not match the stored region key ("no" from 1698-4), method 1698 may generate an error response or not generate a response 1698-5.

[0081] If the received region key matches a stored key for this region (yes, from 1698-4), the memory device may generate a device private key 1698-6. In some embodiments, such action may include accessing a set of keys for the target region in a substantially non-repeated manner (e.g., using a deprecator). This may include, or may not include, indirect access via index values ​​as described herein and equivalent thereto. The memory device 1602 can then compute a device intermediate key using its own private key 1698-7. In some embodiments, as in the case of the host device, the device intermediate key may be generated by an EDCH algorithm using device private keys and parameters known to both the host 1604 and the memory device 1602.

[0082] Next, the device may generate a response 1698-8. Such a response may include a device intermediate key and a MAC generated with a region key and a count value. The count value may be generated using the NMC of memory device 1602. Next, a session response may be sent to the host device 1698-9. Such action may include any suitable method, which may include sending the response after a request with a predetermined delay, or sending the response in response to another request by host 1604.

[0083] If both the host device 1604 and the memory device 1602 have an intermediate key for the other device, devices 1604 and 1602 can generate a session key. Such a session key may be used to authenticate and / or encrypt communication between the host device and the memory device directed to an indicated area in the memory device. That is, since the session key is derived from the area key, the session may be restricted to a specific area of ​​the memory device.

[0084] Some embodiments can provide secure access to multiple areas of a storage device, while some embodiments may also include systems and methods for authenticating additional features of the memory device.

[0085] Figures 17A and 17B illustrate authentication operations according to further embodiments. Figure 17A shows a provisioning operation 1799P for a system having a host device 1704 and a memory device 1702 for storing firmware (FW) for the host device 1704. The memory device 1702 can take any form disclosed herein or equivalent and may include a non-volatile storage location for the FW. The provisioning operation 1799P may include securely storing a master key in the host device 1799-0 and securely storing a master key in the memory device 1799-1. Such actions may include the host device 1704 programming the master key in the memory device, the host device retrieving the master key from the memory device, or the master key being programmed individually in each device. The master key may be a secret key shared between the host device 1704 and the memory device 1702.

[0086] Next, the host device 1704 may select a boot setup value 1799-2. The boot setup value (CONST_P) may be transferred to a memory device 1799-3. In some embodiments, such action may include the host device 1704 issuing a predetermined command (e.g., Create_SB_Secret). Such a command may be in packet form, comprising a command field that identifies the command (to create a secure boot value) and a data field that contains the boot setup value.

[0087] Upon receiving the boot setup value, the memory device 1702 can generate a unique value for the memory device's hardware (HW) and firmware (FW) 1799-4. In some embodiments, this may involve generating a value using a first value that identifies the firmware (FW_Code) and a second value that identifies the memory device (Dev_Code) (i.e., HW). In the illustrated embodiment, the unique value may be a "constrained data item" (CDI) formed by a hash function operating on FW_Code and Dev_Code.

[0088] Once a unique HW / FW value (e.g., CDI) is generated, the memory device 1702 may generate secure boot code (SB_Secret) using the boot setup value (e.g., CONST_P) received from the host device 1704. In the illustrated embodiment, such an operation may include encryption of the boot setup value using the unique HW / FW value (SB_Secret=encrypt[CDI, CONST_P]). The generated secure boot code can be securely stored within the memory device 1702.

[0089] In this way, the memory device 1702 can have a secure boot value (CONST_P) that contains a secret value known to the host device, which can only be deciphered using a value unique to the memory device's HW / FW (i.e., CDI).

[0090] Figure 17B illustrates secure boot operation 1799SB for a system as shown in Figure 17A. Specifically, Figure 17B shows the host device 1704 and memory device 1702 that were subject to the provisioning operation shown in Figure 17A. Secure boot operation 1799SB may occur in response to any suitable predetermined condition in the host device 1799-7, or in response to any suitable predetermined condition in the memory device 1799-8. The predetermined condition includes, but is not limited to, a power-on condition or a reset condition, which are just one of many possible examples.

[0091] In secure boot operation 1799SB, the host device can generate a challenge value 1799-9. The challenge value (R) may be any suitable value and, in some embodiments, may be a random or pseudorandom number generated by the host device 1704. The host device 1704 can then generate a MAC using the master key and the challenge value. In some embodiments, the MAC may also include a count value, which may be an NMC value generated (and updated each time) by the memory device 1702. The current count value may have been established by previous communication with the memory device 1702, or it may be the initial count value. The host device can then transmit a host challenge with the corresponding MAC to the memory device 1799-11. In some embodiments, such an action may include the host device 1704 issuing a predetermined command (e.g., Authenticate_SB). Such a command may be in packet form having a command field that identifies the command and a data field that contains the host challenge value.

[0092] Memory device 1702 receives the host challenge and MAC and can determine whether the MAC is valid using its own securely stored master key (and count value, if used) 1799-12. If the MAC is not valid ("no" from 1799-12), memory device 1702 may exit the authentication process because host device 1704 itself has failed authentication (e.g., does not have a valid master key). If the MAC is valid ("yes" from 1799-12), host device 1704 may be considered authenticated by the memory device 1799-13. This is in contrast to the conventional operation in which only the host authenticates the firmware of the storage device.

[0093] The memory device 1702 can regenerate the boot setup value established in a provisioning operation (e.g., Figure 17A) 1799-14. In some embodiments, this may involve decrypting an encrypted value containing the boot setup value having a value unique to the memory device's HW / FW. For example, the CDI may be generated with a value unique to the FW and HW (e.g., CDI=hash[FW_Code][HW_Code]). The CDI value may be used to decrypt the SB_Secret value to arrive at the boot setup value (CONST_P). The memory device 1702 can encrypt the regenerated boot setup value by the challenge value to create an encrypted challenge value (e.g., R_encrypted=encrypt[CONST_P,R)) 1799-15. The memory device 1702 can then generate a MAC for the challenge response using the master key, the encrypted challenge value, and optionally a nonce value (e.g., MAC[Master_key,R_encrypted][Nonce]) 1799-16.

[0094] The response and corresponding MAC may be obtained by the host device.1799-17 Such action may include any appropriate response operation, which may include, but is not limited to, the memory device transmitting a response within a predetermined time after receiving an authentication request from the host, or in response to another command / request from the host (e.g., reading data or registering a command).

[0095] The host device 1704 receives a response and a corresponding MAC from the memory device and can determine whether the response MAC is valid or not 1799-18. In some embodiments, this may include the host device 1704 using its own securely stored master key. If the MAC is not valid ("no" from 1799-18), the host device 1704 may exit the authentication process as it has determined that the memory device 1702 has failed to authenticate. If the MAC is valid ("yes" from 1799-18), the memory device 1702 may be considered authenticated 1799-19.

[0096] Next, host device 1704 may decrypt the encrypted host challenge 1799-20. Such action may include decryption using a boot setup value (e.g., CONST_P) established during the provisioning operation. If the host challenge is invalid ("No" from 1799-21), the FW is determined to be invalid, and host device 1704 may exit this operation. If the host challenge is valid ("Yes" from 1799-21), the FW may be determined to be authenticated 1799-22.

[0097] In this way, the memory device 1702 can enable mutual authentication (i.e., the host can authenticate the memory device, and the memory device can authenticate the host), as well as authentication of the memory device itself (i.e., the hardware) and authentication of the firmware stored by the memory device.

[0098] Some embodiments disclose systems and methods in which a host device accesses various areas of a memory device based on a key, while in other embodiments, the areas may be accessed by various processes or devices other than the host. Figure 18 shows one example of such a system and method according to one embodiment.

[0099] Figure 18 shows a system 1800 having a secure memory device 1802, a host device 1804, a remote access system 1895, and a remote device 1891. The memory device 1802 may include an I / F section 1808, an access control circuit 1812, and a non-volatile section 1814. The I / F section 1808 may include one or more interfaces for communicating with the host device 1804 and the remote access system 1895. The non-volatile section 1814 may include a plurality of different regions 1820-0 to 1820-n and a secure key store 1818. The regions (1820-0 to 1820-n) can take any form described herein or equivalent thereto. The key store 1818 can non-volatilely store keys for the regions (1820-0 to 1820-n) and can take any form described herein or equivalent thereto. Figure 18 shows three keys (Key_A, Key_B, Key_C), but it is understood that there may be more keys, and that such keys may change over time (for example, using a deprecator). In the illustrated embodiment, access to region 0 1820-0 requires key Key_A, access to region 1 1820-1 requires key Key_B, and access to region 2 1820-2 requires key Key_C.

[0100] The access control circuit 1812 can control access to each of the regions (1820-0 to 1820-n) based on the security controls of that region. Such controls may include, but are not limited to, any controls described herein or equivalent, which include requiring authentication or encryption / decryption operations using one or more keys assigned to the region.

[0101] The host device 1804 may include a plurality of processing elements 1897-0 to 1897-3, each processing element capable of executing a different application or function. The processing elements (1897-0 to 1897-3) may include any suitable processing elements, which may include, but are not limited to, different applications executed by processing cores, processing threads, or processors. In the illustrated embodiment, element 1897-2 can access Key_B, and element 1897-3 can access Key_C. In some embodiments, some or all access to the key by elements (1897-0 to 1897-3) may be mutually exclusive (for example, element 1897-2 is the only element that can access Key_B).

[0102] The remote access system 1895 can enable a remote device (e.g., 1891) to access the memory device 1802. In some embodiments, the remote access system 1895 can enable access via one or more wireless wide-area network protocols.

[0103] The remote access system 1895 and the host device 1804 can access the memory device 1802 via one or more communication links 1806. The communication links 1806 may be any suitable communication links described herein and equivalent thereto, including wired and wireless links. In one embodiment, the communication links 1806 may include one or more high-speed serial data buses.

[0104] The secure memory device 1802, the host device 1804, the communication link 1806, and the remote access system 1895 may all be part of the local system 1800L. The local system 1800L may have components that are in close proximity to each other (for example, on the same large device).

[0105] In contrast to the local system 1800L, the remote device 1891 may be located in a different physical location from the memory device 1802. For example, the remote device 1891 may include a server that communicates with the local system 1800L via a large network 1893. The network 1893 may be a wired or wireless network, including the Internet. In the illustrated embodiment, the remote device 1891 can access Key_A. In some embodiments, such access may be exclusive (for example, the host device does not possess Key_A or cannot access Key_A in any other way).

[0106] In the illustrated embodiment, separate processes and devices can access various areas of the memory device 1802. Assuming key access is exclusive, element 1897-2 can access area 1820-1 using Key_B, while other devices and elements cannot access area 1820-1. At the same time, element 1897-3 of the same device (host device 1804) can access area 2 1820-2 using Key_C, but cannot access area 0 1820-0 or area 1 1820-1. Furthermore, remote device 1891 can access area 0 1820-0 using Key_A, but no element within host device 1804 can access this area 1820.

[0107] The memory devices disclosed herein may include regions formed of any suitable non-volatile memory cell type and architecture. However, some embodiments may be formed from a NOR flash array, which may be configured to provide high-granularity access, faster access speeds, and the ability to enable system booting from firmware stored in the device. This is in contrast to the NAND architecture.

[0108] Figure 19 is a diagram of a portion of a memory device area 1920 that may be included in the embodiment. Area 1920 may include multiple flash memory cells (one shown as 1985) arranged in multiple rows connected in common to the same word line (one shown as 1983) and multiple columns connected in common to the same bit line (one shown as 1987). Furthermore, a group of memory cells 1985 may be connected in common to the same source line (one shown as 1987), thereby enabling flash erasure of multiple cells in the same operation. It should be understood that the area shown in Figure 19 is provided as an example and should not be construed as limiting.

[0109] Some embodiments may include a system comprising a memory device operating in cooperation with another device, while some embodiments may also include a standalone memory device that can provide multiple regions, each having its own security features. Such a memory device may include multiple integrated circuits formed within the same package, but in some embodiments, the memory device may be advantageously a single compact integrated circuit (i.e., a chip). Figure 20 shows a packaged single-chip memory device 2002. The memory device 2002 may include multiple interface connections (two of which are shown as 2081). The interfaces (e.g., 2081) can enable connection to one or more communication paths (e.g., a serial bus). However, it is understood that the memory device according to some embodiments may include any other suitable packaging type, including direct bonding of the memory device chip on the surface of a circuit board.

[0110] Some embodiments may include any suitable system, including portable electronic devices. However, some embodiments may also include larger systems. Figure 21 is a diagram of system 2100 according to one embodiment. System 2100 may include a vehicle 2179 equipped with a local system 2100L. The local system 2100L may be all or part of a vehicle control system and may include a secure non-volatile memory device 2102 according to embodiments disclosed herein or equivalent thereto. The local system 2100L can communicate with a server 2191 via a wireless network 2193.

[0111] In some embodiments, the server 2191 may have one or more keys that enable access to one or more areas of the memory device 2102. The server 2191 can perform firewall authentication and / or hardware authentication of the memory device 2102 according to the embodiments herein or equivalent thereto. Furthermore, the memory device 2102 itself can authenticate communications from the server 2191.

[0112] Throughout this specification, any reference to “one embodiment” or “one embodiment” should be understood to mean that certain features, structures, or characteristics described in relation to this embodiment are included in at least one embodiment of the present invention. Therefore, it should be emphasized and understood that two or more references to “one embodiment” or “one embodiment” or “alternative embodiment” in different parts of this specification do not necessarily all refer to the same embodiment. Furthermore, certain features, structures, or characteristics may be combined as appropriate in one or more embodiments of the present invention.

[0113] Similarly, in the above description of exemplary embodiments of the Invention, it should be understood that, for the purpose of simplifying the disclosure to aid in understanding one or more of the various aspects of the Invention, various features of the Invention are sometimes grouped together in a single embodiment, figure, or description thereof. However, this method of disclosure should not be interpreted as reflecting an intention that the claims require more features than those explicitly listed in each claim. Rather, the aspects of the Invention relate to fewer features than all the features of the single embodiment described above. Thus, the claims following the detailed description are explicitly incorporated into this detailed description, while each claim remains independent as a distinct embodiment of the Invention.

Claims

1. 1. An apparatus, comprising: a plurality of regions, each region containing a plurality of non-volatile memory cells; a permission store configured to non-volatilely store a permission value set including at least one permission value for each region; an access control circuit; It contains the access control circuit is configured to control access to each area according to the permission value for the area; To control is to requiring authentication to access the area; encrypting the data read from the area; decrypting data for storage within said region; containing one or more of: Device.

2. Each region contains a NOR flash array.

10. The apparatus of claim 1.

3. and further including at least one nonvolatile monotonic counter (NMC) configured to generate a non-repeating, non-volatile count value.

10. The apparatus of claim 1.

4. the access control circuit includes an authentication circuit; The authentication circuit authenticating received data with said count value of at least one NMC; generating an authentication value for transmission with the count value of at least one NMC; It is configured as follows:

4. The apparatus of claim 3.

5. the apparatus further includes a non-volatile key store configured to store a plurality of region keys for each region; The access control circuit authenticating received data directed to a domain with a key for said domain; generating a message authentication code (MAC) with a key for the domain for a response to an access to the domain; decrypting received data addressed to a region with a region key for said region; decrypting the data read from the region with the region key for said region; It is configured as follows:

10. The apparatus of claim 1.

6. the permission store includes a plurality of non-volatile index values ​​for each region, each index value being programmable to point to one of the region keys; 6. The apparatus of claim 5.

7. The apparatus further includes a deprecator module configured to limit reuse of the domain key.

6. The apparatus of claim 5.

8. the authorization store includes a manufacturer store configured to selectively store an access key for each region according to a customer, each access key enabling access by a device manufacturer to a corresponding region; 10. The apparatus of claim 1.

9. 1. A method, comprising: receiving a request at a memory device, the memory device having a plurality of regions, each region individually configurable for a different type of access permission; determining, by an operation of the memory device, a target area for the operation from information in the request; providing an access store having a distinct key value for each region; adjusting access to the target area based on the key value for the target area from among several access permissions; It contains The key values ​​for the regions are stored in a non-volatile key store. method.

10. coordinating access to the target domain includes authenticating the received request using an authentication process that includes the key value for the target domain.

10. The method of claim 9.

11. The method further includes generating a non-volatile monotonic count value; the authentication process includes the key value and the monotonic count value; The method of claim 10.

12. coordinating access to the target area includes decrypting the request using a decryption process that includes the key value for the target area.

10. The method of claim 9.

13. The access permissions for each area are Reading and writing are permitted without restriction; a read operation requiring authentication with a key exclusive to the target region; programming and erasing operations requiring authentication by a key exclusive to the target area; a read operation requiring encryption with a key exclusive to the target region; programming and erasure operations requiring decryption with a key exclusive to the target area; Contains, 10. The method of claim 9.

14. the memory device includes a plurality of non-volatile key value storage locations exclusive to each region; selecting the key value for the target region further includes selecting the key value from the plurality of non-volatile key value storage locations exclusive to the target region.

10. The method of claim 9.

15. the memory device includes a plurality of non-volatile index values ​​exclusive to each region, each index value pointing to a non-volatile key storage location; selecting the key value for the target region includes selecting an index value for the target region to access the key value pointed to by the selected index value; the index values ​​are accessed with a non-volatile deprecating value that prevents the same index value from being used multiple times; 15. The method of claim 14.

16. 1. A system including at least one host device and a memory device, the host device is configured to transmit an access request identifying one of a plurality of regions within the memory device; The memory device is coupled to the host device by a communication bus, and the memory device at least two regions, each region containing a non-volatile memory cell; a non-volatile key store configured to store multiple key values ​​that are exclusive to each region; an access control circuit configured to selectively enable access to each region by the host device based on a key for the region; Contains, system.

17. the access control circuitry includes authentication circuitry configured to authenticate a request based on a key value for the domain identified by the request.

17. The system of claim 16.

18. the access control circuit includes an encryption circuit; The encryption circuit decrypting the data received in the request based on the key value for the region identified by the request; encrypting data from the region identified by the request based on a key value for the region; It is configured as follows:

17. The system of claim 16.

19. In a mutual authentication operation, The host device sending a challenge value to the memory device using a request message authentication code (MAC); responsive to receiving a response MAC from the memory device, authenticating the memory device with a master key; authenticating firmware on the memory device in response to decrypting an encrypted challenge value received from the memory device with a secret boot value; It is structured as follows: The memory device is in response to receiving the request MAC from the host device, authenticating the host device with a master key; encrypting the challenge value with the secret boot value; sending the encrypted challenge value together with the response MAC to the host device; It is configured as follows:

17. The system of claim 16.

20. the system further includes at least one second device configured to access at least one region with a key to the region, the key not being stored by the first device; 17. The system of claim 16.

21. The system includes a host device including a plurality of processing elements, a first processing element having access to keys for a first region, a second processing element having access to keys for a second region, and not having access to the first region; 17. The system of claim 16.

Images