阅读说明：本技术 在存储器装置处的物理不可复制函数 (Physically unclonable function at a memory device ) 是由 L·W·多弗 O·杜瓦尔 于 2019-12-27 设计创作，主要内容包括：各种实例涉及用于将存储器装置的选定部分的数字指纹提供到主机装置的系统及方法。在主机装置处执行的主机装置可将产生数字指纹数据的命令发送到驱动程序。所述命令可包含指示本地存储器的存储器位置的输出指针。所述驱动程序可产生不包含所述输出指针的经修改命令。所述驱动程序可将所述经修改命令发送到存储器装置。所述驱动程序可接收包括所述数字指纹数据的回复且将所述数字指纹数据写入到由所述输出指针指示的所述主机装置的本地存储器的所述存储器位置处的位置。(Various examples relate to systems and methods for providing a digital fingerprint of a selected portion of a memory device to a host device. A host device executing at the host device may send a command to the driver to generate the digital fingerprint data. The command may include an output pointer indicating a memory location of the local memory. The driver may generate a modified command that does not include the output pointer. The driver may send the modified command to the memory device. The driver may receive a reply that includes the digital fingerprint data and write the digital fingerprint data to a location at the memory location of a local memory of the host device indicated by the output pointer.)

1. A system for providing a digital fingerprint of a selected portion of a memory device to a host device, comprising:

a memory device;

a host device comprising local memory separate from the memory device, the host device for executing drivers and host applications, wherein the host device is configured to perform operations comprising:

sending, by the host application, a command to the driver to generate digital fingerprint data, the command including an output pointer to a memory location of the local memory to be written to the digital fingerprint data;

generating, by the driver, a modified command, wherein the modified command does not include the output pointer;

sending, by the driver, the modified command to the memory device;

receiving, by the driver, a reply including the digital fingerprint data describing a selected portion of the memory device; and

writing the digital fingerprint data to a location at the memory location of the local memory indicated by the output pointer.

2. The system of claim 1, wherein the host device is further configured to perform operations comprising: decrypting, by the driver, the digital fingerprint data using a host device private key prior to writing the digital fingerprint data to the location at the local memory indicated by the output pointer.

3. The system of claim 1, wherein the command comprises an input parameter, and wherein the host device is further configured to perform an operation comprising encrypting the input parameter based at least in part on a public key associated with the memory device.

4. The system of claim 1, wherein the host device is further configured to perform operations comprising sending an instantiation command to the memory device, wherein the instantiation command indicates an allocation size indicating an amount of memory at the memory device to be allocated to a PUF.

5. The system of claim 4, wherein the instantiation command further indicates a host public key used to encrypt digital fingerprint data at the memory device.

6. The system of claim 1, wherein the command is an enrollment command, and wherein the digital fingerprint data includes an activation code.

7. The system of claim 1, wherein the command comprises an activate code received in response to a previous command to the driver.

8. The system of claim 1, wherein the command comprises an indication of a key type and wherein the digital fingerprint data comprises a key of the key type.

9. A method for providing a digital fingerprint to a host device, comprising:

sending, by a host application executing at the host device, a command to a driver executing at the host device to generate digital fingerprint data, the command including an output pointer indicating a memory location of a local memory of the host device to which the digital fingerprint data is to be written;

generating, by the driver, a modified command, wherein the modified command does not include the output pointer;

sending, by the driver, the modified command to an external memory device;

receiving, by the driver, a reply including the digital fingerprint data; and

writing the digital fingerprint data to a location at the memory location of the local memory indicated by the output pointer.

10. The method of claim 9, further comprising decrypting, by a driver, the digital fingerprint data using a host device private key prior to writing the digital fingerprint data to the location at the local memory indicated by the output pointer.

11. The system of claim 9, wherein the command comprises an input parameter, further comprising encrypting the input parameter based at least in part on a public key associated with the memory device.

12. The method of claim 9, further comprising sending an instantiation command to the memory device, wherein the instantiation command indicates an allocation size that indicates an amount of memory at the memory device to be allocated to a PUF.

13. The method of claim 12, wherein the instantiation command further indicates a host public key used to encrypt digital fingerprint data at the memory device.

14. The method of claim 9, wherein the command is an enrollment command, and wherein the digital fingerprint data includes an activation code.

15. The method of claim 9, wherein the command comprises an activate code received in response to a previous command to the driver.

16. The method of claim 9, wherein the command comprises an indication of a key type and wherein the digital fingerprint data comprises a key of the key type.

17. A non-transitory computer-readable medium comprising instructions thereon, which, when executed by a hardware processor, cause the hardware processor to perform operations comprising:

sending, by a host application executing at the hardware processor, a command to a driver executing at the host device to generate digital fingerprint data, the command including an output pointer indicating a memory location of a local memory associated with the hardware processor to which the digital fingerprint data is to be written;

generating, by the driver, a modified command, wherein the modified command does not include the output pointer;

sending, by the driver, the modified command to a memory device;

receiving, by the driver, a reply including the digital fingerprint data; and

writing the digital fingerprint data to a location at the memory location of the local memory indicated by the output pointer.

18. The medium of claim 17, wherein the operations further comprise decrypting, by a driver, the digital fingerprint data using a host device private key prior to writing the digital fingerprint data to the location at the local memory indicated by the output pointer.

19. The medium of claim 17, wherein the command comprises an input parameter, and wherein operations further comprise encrypting the input parameter based at least in part on a public key associated with the memory device.

20. The medium of claim 17, wherein the operations further comprise sending an instantiation command to the memory device, wherein the instantiation command indicates an allocation size indicating an amount of memory at the memory device to be allocated to a PUF.

Technical Field

Examples described herein generally relate to systems and methods for managing a Physically Unclonable Function (PUF) at a system including a host device and a memory device.

Background

Various computing devices utilize keys to guard stored data, authenticate commands, and for other purposes. However, generating and securely storing keys at a computing device or component thereof can create significant challenges.

Drawings

In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. Some examples are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which:

figure 1 is a diagram showing one example of an environment including a host device and a memory device, where a Physically Unclonable Function (PUF) is implemented at the memory device.

Figure 2 is a flow diagram showing one example of a process flow that may be performed by the local driver of figure 1 to manage a PUF implemented at a memory device.

Figure 3 is a flow diagram showing one example of a process flow that may be performed by the local driver of figure 1 to initialize a PUF that manages an implementation at a memory device.

Figure 4 is a flow diagram showing one example of a process flow that may be performed by the PUF utility at the memory device of figure 1 to instantiate a PUF.

Figure 5 is a flow diagram showing one example of a process flow that may be performed in the environment of figure 1 to execute a command to generate digital fingerprint data (e.g., PUF data).

Fig. 6 shows an example processing system with a memory arrangement as part of one or more apparatuses.

FIG. 7 is a block diagram showing one example of a software architecture of a computing device.

Fig. 8 is a block diagram illustrating a computing device hardware architecture within which a set or sequence of instructions may be executed to cause a machine to perform an example of any of the methods discussed herein.

Detailed Description

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of some examples. However, it will be apparent to one skilled in the art that the present invention may be practiced without these specific details.

A PUF is an electrically readable non-programmed digital fingerprint derived from a selected portion of a semiconductor device under selected access conditions. In many instances, the digital fingerprint will vary depending on manufacturing variations of the individual semiconductor die that result in die-specific variations. The digital fingerprint may include parameters such as a default state or other property of a group of memory cells (e.g., at power-up), signal propagation delay (or other characteristic) within a circuit, and so forth.

In some examples, PUFs are based on small process variations in the manufacture of memory and other semiconductor devices may additionally cause similar semiconductor devices to exhibit slightly different behavior. These small behavioral differences can be detected and used to generate PUF data. The PUF data is data that contains or is derived from the digital fingerprint described above. The PUF data may be used, for example, to generate cryptographic keys and to generate random or pseudorandom numbers.

In various examples, the PUF is implemented by a PUF utility executed at a device that includes a master semiconductor component. The PUF utility reads a digital fingerprint of a selected portion of the semiconductor device. The PUF utility returns the digital fingerprint as PUF data or, in some instances, modifies the digital fingerprint to produce PUF data. For example, the PUF utility may convert a digital fingerprint into a form of appropriate size for use as a key, random number, or other application.

Consider an example in which the main semiconductor component includes a Synchronous Random Access Memory (SRAM) memory cell. In this example, the PUF utility reads the initial logic state of the SRAM memory cell at start-up and translates the read value into PUF data of the appropriate size. Consider another example in which the main semiconductor component includes NAND memory cells. In this example, the PUF utility reads NAND memory cells to detect threshold voltage distributions. The threshold voltage distribution is used to generate PUF data. The PUF data generated by the PUF utility may be used for a number of different purposes, including, for example, as a random number, as a key, or as a basis for generating a key, etc.

The PUF utility corresponds to commands from various other applications or utilities. For example, the one or more commands may instruct the PUF utility to generate digital fingerprint data, such as a PUF. Other commands to the PUF utility may instruct the PUF utility to perform actions related to the generation of PUF data. Example commands to the PUF utility may include commands for preparing or initializing a master semiconductor component to read a digital fingerprint, commands for reading a digital fingerprint and generating a corresponding PUF or other digital fingerprint data, and commands for returning data (e.g., version data) about the PUF utility.

Various examples described herein relate to systems and methods for implementing PUFs at external memory devices. For example, implementing a PUF at a memory device creates a challenge that is addressed by the systems and methods described herein as compared to implementing the PUF directly at the host device.

To illustrate the challenge of implementing a PUF at an external memory device, consider an arrangement in which the PUF is implemented locally at a host device (rather than at an external memory device). In this arrangement, the local SRAM cell of the host device is used as the selected portion of the semiconductor device on which the PUF is based. In this arrangement, the PUF utility and the application that consume the PUF data produced by the PUF utility are both executed at the host device. The host device may implement an Application Programming Interface (API) that the application uses to send commands directly to the PUF utility. Further, the PUF utility may map the results of the command (if any) to memory at the host device, where the results are accessed using a pointer or indirect by the requesting application.

However, when the PUF is implemented externally, the SRAM cells or other selected portions of the semiconductor device used to generate the PUF digital fingerprint are implemented at a memory device external to the host device. For example, the host device may be formed on a first semiconductor chip. The memory device may be formed on a second semiconductor chip. The host device and the memory device may communicate over a bus between the first semiconductor chip and the second semiconductor chip. In some examples, the host device is or includes a system on chip (SoC) and the memory device is or includes an embedded multimedia controller (eMMC).

In this arrangement, commands from an application executing at the host device to the PUF utility may be susceptible to interception and/or spoofing when transmitted from the host device to the PUF utility at the external memory device. Also, sensitive PUF data may be susceptible to interception when transmitted from a PUF utility at an external memory device to a requesting application at a host device. Furthermore, since the PUF utility executes at an external memory device, it may not have access to the local memory of the host device. This may prevent the PUF utility from mapping command results to host device memory using pointers and/or indirection.

Various examples described herein address these and other challenges by executing a local driver at a host device. The local driver may be configured to receive host commands directed to the PUF utility by an application executing at the host device. The local driver receives host commands from the host application. The host command may include a parameter, such as an output pointer parameter. The output pointer parameter is a local memory mapped pointer of the host device that indicates the location where the host application expects to access the PUF data after executing the command. The host command may also include input parameters that include or refer to data used by the PUF to execute the command. The input parameters may be included directly in the host command or passed indirectly using an input parameter pointer to a memory location at the local memory map.

After receiving the host command, the local driver generates a modified command. In some examples, the modified command is digitally signed, e.g., using one or more keys trusted or known by both the host device and the external memory device. The modified command may also exclude the output pointer parameter. For example, the local driver may store the output pointer parameter at the host device for later use, as described herein. The local driver directs the modified command to the external memory device.

The PUF utility at the external memory device executes the modified command. If the modified command produces an output, such as PUF data, the PUF utility passes the output (e.g., including the PUF data) back to the local driver. After receiving the output, the local driver retrieves the stored output pointer parameter provided using the host command and writes the output to local memory at the host device at the location or locations referred to by the output pointer parameter. In this way, the host application may utilize pointers and/or indirection to access PUF data.

Figure 1 is a diagram showing one example of an environment 100 including a host device 102 and a memory device 104, where a PUF124 is implemented at the memory device 104. The host device 102 communicates with the memory device 104 via the communication interface 118. The host device 104 and/or the memory device 104 may be included in various products, such as internet of things (IoT) devices (e.g., refrigerators or other appliances, sensors, motors, actuators, mobile communication devices, automobiles, drones, etc.), network appliances (e.g., routers, switches, etc.), or any other suitable product, to support processing, communication, or control of the products. In some examples, host device 105 and memory device 104 are included on a common circuit board or package. In some examples, the host device 102 is or includes a system on chip (SoC) and the memory device 104 is or includes an eMMC in communication with the SoC.

In the example of fig. 1, host device 102 includes a processor 109 and local memory 108. The processor 109 may be or include any suitable hardware processor. The local memory 108 may be or include any suitable type of memory including, for example, SRAM, other suitable RAM, or other suitable data storage. In some examples, host device 102 also includes a memory device controller 116 to communicate with memory device 104 via a communication interface 118.

The memory device 104 includes one or more controllers 123 configured to perform logical functions for operating the memory device and/or interfacing with the host device 102 via the communication interface 118. The memory device 104 also includes a memory array 122 that can implement a PUF 124. The memory array 122 may include a number of blocks or a number of memory cells. The memory array 122 may include any suitable type of memory cells including, for example, SDRAM. In some examples, memory device 104 also includes a flash array 121 separate from memory array 122. For example, memory array 122 may be an SRAM array utilized by controller 123 to manage flash array 121.

Referring again to the host device 102, the processor 109 executes the host application 110. The host application 110 may be any suitable application or utility that executes at the host device 102 to perform any suitable function. In some examples, the host application 110 is an Operating System (OS) of the host device 102.

The processor 109 also executes the local driver 106. The local driver 106 implements an Application Programming Interface (API)112 to communicate with the host application 110. The API 112 may support a set of host commands 113 and host replies 115. Host commands 113 are commands provided by host application 110. The host command 113 may include input parameters that are directly included or referred to by a pointer. The host command 113 may also include an output pointer that refers to a location at the local memory 108 where the host application 110 will access PUF data originating from the command. The API 112 may also support one or more host replies 115. The host reply is a response to the command generated by the PUF utility. For example, the reply may contain PUF data. Not all commands cause the PUF utility to generate replies. The host reply 115 is a reply provided to the host application 110. Host reply 115 may incorporate PUF data derived from the command and/or may indicate that the PUF data derived from the command is mapped to local memory 108, as described herein.

The local driver 106 is configured to receive host commands 113 from the host application 110. Host commands 113 may be received directly from host application 105 or may be provided by the host application's OS in some instances. Some host commands 113 include parameters while other host commands may not. For example, the host command 113 requesting to stop the PUF124 may not contain a parameter. The host command 113 requesting a key may include one or more input parameters describing the requested key and one or more output pointer parameters pointing to memory locations 128A, 128B at the local memory 108. The output pointer parameter may indicate to the local driver 106 the location to which PUF data generated in response to the host command 113 is written or otherwise mapped.

After receiving the host command 113, the local driver 106 generates a Memory Device (MD) command 130. MD commands 130 are transmitted to memory device 104 via communication interface 118. In some examples, local driver 106 provides MD commands 130 to memory device controller 116, memory device controller 116 manages communication interface 118 with the memory device. Memory device controller 116 provides MD command 130 to memory device 104 (e.g., its PUF utility 120).

MD commands 130 may be similar to host commands 113 but directed to memory device 104. In some examples, MD command 130 is modified from original host command 113. For example, the local driver 106 may modify the host command 113 to delete the output pointer parameter. (local driver 106 stores the deleted output pointer parameter for subsequent use, as described herein.) in some examples, local driver 106 may also cryptographically sign MD command 130, e.g., using a key to generate a Message Authentication Code (MAC) or a Hashed Message Authentication Code (HMAC). The MAC or HMAC may be shared with the memory device 104, as described herein. In some examples, if MD command 130 includes one or more input parameters, the local driver encrypts the input parameters.

The PUF utility 120 at the memory device 104 receives and executes MD commands 130. The PUF utility 120 may be executed at the controller 123 of the memory device 104. As described herein, PUF utility 120 may be configured to verify received MD commands 130. If MD command 130 includes one or more encrypted input parameters, PUF utility 120 may decrypt the input parameters and use them to execute command 130.

After executing MD command 130, PUF utility 120 may provide MD reply 132 to local driver 106. MD reply 132 may include status data describing the status of the command (e.g., whether the command was successfully executed). The PUF utility 120 may be configured to sign a reply cryptogram. For example, PUF utility 120 may generate a MAC or HMAC using a MAC or HMAC key. Some MD commands 130 return PUF data such as, for example, activation codes, keys, etc. The PUF utility 120 may be configured to encrypt PUF data for transmission to the local driver 106. The encrypted PUF data may be part of an MD reply 132 cryptographically signed by the PUF utility 120.

Local driver 106 may receive MD reply 132 directly and/or via memory device controller 116. Local driver 106 may verify the cryptographic signature of MD reply 132. In examples where MD reply 132 includes PUF data, local driver 106 may decrypt the PUF data, as described herein. As described herein, the validation commands 113, 130 and replies 132, 115, as well as the cryptographic parameters and PUF data, may implement the security boundary 126 at the environment 100 including the local driver 106 and the memory device 104. This may reduce security risks associated with implementing the PUF124 outside of the host device 102.

After decrypting the PUF data, the local driver 106 may write or otherwise map the decrypted output (e.g., PUF data) to the memory location 128A, 128B indicated by the output pointer parameter associated with the original host command 113. In this manner, the host application 110 may access output at the local memory 108. The local driver 106 may also send a host reply 115 to the host application 110. The host reply 115 may indicate successful execution of the host command 113 (or unsuccessful execution of the host command 113, optionally). After receiving the host reply 115, the host application 110 may access the output data at the local memory 108 using the output pointer parameter passed with the host command 113.

The local driver 106 and the PUF utility 120 may support various commands to be executed at the PUF 124. The instantiation command instructs the memory device 104 to produce the PUF and to prepare the PUF for use. The instantiation command may originate from the host application 110 as a host command 113 or may be implemented directly by the local driver 106 as an MD command 130 after the local driver 106 is initiated. Additional details of the instance instantiation command are provided herein, such as with respect to operation 308 of the process flow 300. For example, the instantiation command may include an allocation size input parameter (e.g., a number of memory cells at the memory array 122 that will be used to implement the PUF 124) that indicates the size of the PUF 124. The instantiation command may also contain a host public key input parameter indicating the host public key that PUF utility 120 will use to encrypt PUF data derived from other commands. In some examples, the host public key is provided in association with a digital certificate that can be verified by PUF utility 120. The instantiation command may also contain a monotonic counter input parameter that instructs the PUF utility 120 to apply to generate a monotonic counter of PUF data. PUF utility 120 executes the instantiation command and generates an MD reply 132 indicating the success or failure of the command. The local driver 106 may similarly generate a host reply 115 indicating the success or failure of the command.

The product information command may be directed to the PUF124 and returned PUF data describing the PUF124 and/or PUF utility 120. The product information host command 113 may include an output pointer parameter corresponding to the expected PUF data to be generated but may not include any input parameters. Thus, the product information MD command 130 may not contain any parameters. The MD reply 132 to the product information command may include PUF data describing the PUF124 and/or PUF utility 120, such as, for example, one or more of a product identification, PUF version, PUF revision, PUF build-up version number, and the like. The local driver 106 may decrypt this PUF data and write it to the location at the local memory 108 indicated by the output pointer parameter included within the initial host command. The local driver 106 may generate a host reply 115 indicating the success or failure of the command.

The initialization command may confirm that the PUF has been instantiated correctly. The initialize host command 113 may include an output pointer parameter that indicates the actual PUF size and a size input parameter that indicates the desired PUF size. The local driver 106 generates an MD command 130 that includes the desired PUF size input parameter. The PUF utility 120, upon receiving the MD command 130, verifies that the instantiated size of the PUF124 matches the desired PUF size parameter and, if so, returns PUF data indicating the actual PUF size. The local driver 106 writes the PUF data to a location at the local memory 108 corresponding to the output pointer parameter. The local driver 106 may also generate a host reply 115 indicating the success or failure of the command.

The enrollment command may prompt the PUF utility 120 to use the PUF to generate the activation code. An activation code is PUF data that can subsequently be used as parameters for different commands, e.g. for generating cryptographic keys, random numbers, etc. The enrolment host command 113 may contain an output pointer parameter for receiving the activation code PUF data. Local driver 106 may generate MD command 130 that may not include any parameters. The PUF utility 120 generates a activation code using the PUF124 and returns the activation code as PUF data using the MD reply 132. The local driver 106 writes the activation code to the memory location at the local memory 108 indicated by the output pointer parameter and generates a host reply 115 indicating the success or failure of the command.

The start command provides the PUF124 with a previously generated activate code and prepares it to receive additional commands. The initiate host command 113 includes an activate code input parameter. The local driver 106 generates an MD command 130 that includes an activate code as an input parameter. The PUF utility 120 initiates the PUF124 using the activation code and returns an MD reply 132 indicating the success (or failure) of the initiation command. The local driver 106 then generates a host reply 115 indicating the success or failure of the command.

The stop command stops the PUF124 and may disable the PUF124 until it is restarted. The stop host command 113 may not include any parameters. The local driver 106 may generate and communicate a stop MD command 130, which may also lack parameters. The PUF utility may execute the stop command and provide an MD reply 132 indicating the success or failure of the command. The local driver 106 may also generate a host reply 115 indicating the success or failure of the command.

The get key command is used to generate a key using PUF 124. The get key host command 113 may include various parameters, including a key type input parameter indicating the type of key requested (e.g., key type) and, in some examples, an index input parameter. The get key host command 113 may also contain an output pointer parameter for receiving a key. Local driver 106 generates MD command 130 including a key type input parameter and an index input parameter. PUF utility 120 uses PUF124 to generate the requested key type using the index and returns the key as PUF data in MD reply 132. The local driver 106 writes the key to the location at the local memory 108 indicated by the output pointer parameter and sends a host reply 115 to the host application 110.

Another example host command 113 may request a cryptographic signature of data provided as an input parameter. For example, host command 113 may include payload data. In response to the host command 113, the PUF utility 120 generates a cryptographic signature of the payload data, e.g., using a key generated from the PUF124, as described herein. The input parameters may also include an output pointer parameter for receiving cryptographic signatures.

Figure 2 is a flow diagram showing one example of a process flow 200 that may be performed by a local driver 106 executing at a host device 102 to manage a PUF124 implemented at a memory device 104. At operation 202, the local driver 106 receives the host command 113 from the host application 110. Host commands 113 may be received directly from host application 110 and/or via the OS of host device 102. The host command 113 may include one or more parameters, including, for example, an input parameter and an output pointer parameter. The input parameters may be included within the host commands 113 or provided as pointers to memory locations 128A, 128B at the local memory 108.

At operation 204, local driver 106 generates MD command 130. This may include, for example, removing the output pointer parameter from the host command 113. The output pointer parameter may be stored locally at the host 102, such as at a secure memory location associated with the local driver 106. In examples where the input parameters are included as pointers within the host commands 113, the local driver 106 accesses the memory locations 128A, 128B at the local memory 108 that include the input parameters and incorporates the input parameters directly into the MD commands 130.

At optional operation 206, local driver 106 encrypts any input parameters of MD command 130. For example, if the host command 113 includes an input parameter, the input parameter may be encrypted. The input parameters may be encrypted using any suitable symmetric or asymmetric encryption scheme, including, for example, Data Encryption Standard (DES), Rivaist-Shamir-Aldman (Rivest-Shamir-Aldeman) (RSA), Advanced Encryption Standard (AES), and so forth. In some examples, a symmetric scheme (e.g., RSA) is used and the local driver 106 encrypts the input parameters using the memory device public key of the memory device 104 and/or the PUF utility 120. The PUF utility 120 may then decrypt the parameters using the memory device private key corresponding to the public key, as described herein. If the MD command 130 does not contain any parameters, then operation 206 may not be performed.

At operation 208, local driver 106 cryptographically signs MD command 130. Similar to the encryption of operation 206, the cryptographic signing of operation 208 may be performed using a symmetric key or a set of asymmetric keys. If an asymmetric key is used, local driver 106 may generate a digital signature using MD command 130 and its private key. As described herein, the PUF utility 120 may authenticate the digital signature using a public key associated with the local driver 106. In an example in which a symmetric key is used, both local driver 106 and PUF utility 120 have copies of the same symmetric key. The local driver 106 generates a digital signature, for example, by applying a hash or other cryptographic function to the MD command 130 using a symmetric key. In some instances, the resulting cryptographic signature is referred to as a MAC or HMAC.

At operation 210, the local driver 106 sends the MD command 130 (including the cryptographic signature) to the memory device 104 (e.g., its PUF utility 120). The memory device 104 executes the MD command and sends an MD reply 132, and the local driver 106 receives the MD reply 132 at operation 212. MD reply 132 may include a status indicating whether MD command 130 was successfully executed. In examples where MD command 130 produces PUF data, MD reply 132 also includes PUF data (which may be encrypted).

At operation 214, local driver 106 validates MD reply 132. For example, reply 132 may contain a cryptographic signature, such as a MAC or HMAC. The local driver 106 verifies the cryptographic signature with the appropriate key. In examples where the reply 132 includes PUF data, the local driver 106 may also decrypt the PUF data, e.g., using a private key associated with the host device 102 and/or a symmetric key shared with the memory device 104.

At optional operation 216, the local driver 106 writes the PUF data (if present) to the memory location 128A, 128B corresponding to the output pointer parameter included within the host command 113. For example, the local driver 106 may retrieve pointer parameters stored during generation of the modified command. At operation 218, the local driver 106 sends a status message to the host application 110 indicating that the host command 113 has been executed. Host application 110 may then access the PUF data (if present) in the PUF data at local memory 108.

Figure 3 is a flow diagram showing one example of a process flow 300 that may be performed by the local driver 106 to initialize the PUF124 at the managed memory device 104. Local driver 106 may execute process flow 300 in preparation for responding to host command 113, as described herein. In some examples, the local driver 106 performs the process flow 300 after initiation.

At operation 302, the local driver 106 accesses the host private key. The host private key may be stored, for example, at a key register associated with processor 109 and/or local memory 108. The host private key may be used to decrypt the PUF data received in MD reply 132.

At operation 304, the local driver 106 verifies the memory device credentials including the public key of the memory device 104 (the memory device public key). In some examples, the memory device credential is cryptographically signed by the credential authority with a private key of the credential authority. Verifying the memory device credential may include using a public key of the credential authority to confirm that the cryptographic signature of the memory device credential was generated using a private key of the credential authority. The memory device credential may include a memory device public key that the local driver 106 may use to encrypt MD command 130 parameters after authentication, as described herein.

At operation 306, the local driver 106 may initialize the symmetric MAC key. This may include achieving coherency with the memory device 104 with respect to the shared secret. Initializing the symmetric MAC key may be performed, for example, using any suitable key exchange algorithm. The local driver 106 may store the symmetric MAC key, for example, at a key register associated with the processor 109 and/or the local memory 108.

At operation 308, the local driver 106 sends an instantiate MD command 130 to the memory device 104. Instantiation MD command 130 instructs memory device 104 (e.g., PUF utility 120) to generate PUF 124. For example, the instantiation MD command 130 may contain a parameter such as the size of the PUF. Another example parameter of instantiation MD command 130 may be a host public key that PUF utility 120 may use to encrypt PUF data provided to local driver 106. The host public key may correspond to the host private key accessed at operation 302.

Figure 4 is a flow diagram showing one example of a process flow 400 that may be performed by the PUF utility 120 to instantiate the PUF124, e.g., in response to an instantiate MD command 130 received from the local driver 106. At operation 402, PUF utility 120 assigns PUF124 a set of memory addresses from memory array 122. At operation 404, the PUF utility allocates one or more monotonic counters at the memory device 104 for the PUF 124. At operation 406, the PUF utility assigns the key used to manage the PUF124 to a particular key register location, e.g., at the controller 123 and/or at the memory array 122. For example, the symmetric MAC key received from the local driver 106 may be stored at a key register location. The symmetric MAC key may be used to cryptographically verify MD command 130 and digitally sign MD reply 132. The memory device private key associated with the memory device digital certificate (verified at operation 304) may be stored at another key register location. The memory device private key may be used to decrypt MD command 130 parameters encrypted by local driver 106 using the memory device public key.

FIG. 5 is a flow diagram showing one example of a process flow 500 that may be performed in the environment 100 of FIG. 1 to execute a command. The process flow 500 includes three columns 501, 503, 505. Column 501 contains operations that may be performed by the host application 110. Column 503 contains operations that may be performed by the local driver 106. Column 505 includes operations that may be performed by memory device 104 (e.g., its PUF utility 120).

At operation 502, the host application 110 sends the host command 113 to the local driver 106. Host command 113 may request that a command, such as one of the example commands described herein, be executed at PUF 124. Depending on the requested command, the host command 113 may include one or more parameters. The parameters may include input parameters to be used to execute the command and output pointer parameters. The output pointer parameter may point to a memory location 128A, 128B at the local memory 108 where the host application 110 desires to locate PUF data after executing the command. The input parameters may be included in the command 113 directly or indirectly via a pointer to the local memory 108.

Local driver 106 receives host command 113 and, at optional operation 504, it generates MD command 130. Generating the MD command 130 may include removing the output pointer parameter from the host command 113. The output pointer parameter may be stored and subsequently used to write PUF data originating from the command to the indicated memory location 128A, 128B. In some examples, the output pointer parameter is stored with an indication of the generated MD command 130 (e.g., a hash of some or all of the MD command 130). Upon receiving a reply 132 to the MD command 130, the indication of the generated MD command 130 is then used to retrieve the output pointer parameter. The generate MD command 130 may also include an encryption input parameter (if present). In examples where the input parameters are provided indirectly via one or more pointers, the local driver 106 may access the values of the relevant input parameters from the local memory 108 prior to encryption.

At operation 506, local driver 106 cryptographically signs MD command 130, e.g., using a MAC key, as described herein. At operation 508, the local driver 106 sends the MD command 130 to the memory device 104 (e.g., its PUF utility 120).

The memory device 104 receives the MD command 130 and verifies the digital signature of the MF command 130 at operation 510. In some examples, the firmware of the memory device 104 calls the PUF utility 120 to execute the command using the MD command 130. This may occur before or after verification. At operation 512, PUF utility 120 executes the command at PUF 124. Depending on the command, this may produce PUF data. If PUF data is generated, the PUF utility encrypts the PUF data at optional operation 514. The PUF data may be encrypted, for example, using a host public key provided to the memory device 104, as described herein. At operation 516, memory device 104 and/or PUF utility 120 sends MD reply 132 to local driver 106. This may include digitally signing the reply 132, for example, using a MAC key.

Local driver 106 receives MD reply 132 and verifies its cryptographic signature at operation 518. Optionally, if MD reply 132 includes PUF data, local driver 106 decrypts the PUF data and writes it to the location at local memory indicated by the output pointer parameter (if present) at operation 520. The local driver 106 may decrypt the PUF data, for example, using a host private key. At operation 522, the local driver 106 sends the host reply 115 to the host application 110. The host reply 115 indicates the success (or failure) of the original host command 113. The host application 110 receives the reply at operation 524. If the reply 115 indicates that the command was successful, the host application may access the resulting PUF data from the local memory 108 at operation 526.

Fig. 6 shows an example environment 600 that includes a processing system 610 (e.g., processing system 101) having a memory arrangement 620 (e.g., any of the memory arrangements described herein) as part of one or more apparatus 630, 640, 650. An apparatus includes any device that may include a processing system, such as processing system 610. As previously mentioned, the processing system 610 may be any device capable of executing instructions (sequentially or otherwise). Example devices include a vehicle 630 (e.g., as part of an infotainment system, a control system, or the like), a drone 650 (e.g., as part of a control system), furniture or appliances 640 (e.g., as part of a sensor system, an entertainment or infotainment system), or the like. In other examples, although not shown, the apparatus may include an aerial device, a marine device, an internet of things (IOT), and other devices.

FIG. 7 is a block diagram 700 showing one example of a software architecture 702 of a processing device. The architecture 702 may be used in conjunction with various hardware architectures. For example, the software architecture 702 may describe the host device 102. FIG. 7 is only a non-limiting example of a software architecture 702 and many other architectures can be implemented to facilitate the functionality described herein. A representative hardware layer 704 is illustrated and may represent, for example, any of the computing devices mentioned above. In some examples, the hardware layer 704 may be implemented according to the architecture 702 of fig. 7, the machine 800 of fig. 8, and/or the architectures of the secure processing system 101 described herein.

The representative hardware layer 704 includes one or more processing units 706 with associated executable instructions 708. Executable instructions 708 represent executable instructions of software architecture 702, including implementations of the methods, modules, components, etc. of fig. 1-4. The hardware layer 704 also includes memory and/or storage modules 710, which also have executable instructions 708. The hardware layer 704 may also include other hardware, as indicated by other hardware 712, which represents any other hardware of the hardware layer 704, such as the other hardware illustrated as part of the hardware architecture 800.

In the example architecture of fig. 7, the software 702 may be conceptualized as a stack of layers, where each layer provides specific functionality. For example, software 702 may include layers such as an operating system 714, libraries 716, framework/middleware 718, application programs 720, and a presentation layer 744. Operationally, the application 720 and/or other components within the layers may invoke an Application Programming Interface (API) call 724 through the software stack and receive a response, return a value, etc., illustrated as a message 726 in response to the API call 724. The layers illustrated are representative in nature and not all software architectures have all layers. For example, some mobile or special-purpose operating systems may not provide the framework/middleware layer 718, while others may provide this layer. Other software architectures may include additional or different layers.

The operating system 714 may manage hardware resources and provide common services. Operating system 714 may include, for example, kernel 728, services 730, and drivers 732. The core 728 may act as an abstraction layer between hardware and other software layers. For example, kernel 728 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, and the like. Service 730 may provide other common services for other software layers. In some examples, services 730 include interrupt services. Interrupt servicing may detect the receipt of a hardware or software interrupt and in response cause the architecture 702 to halt its current processing and execute an Interrupt Service Routine (ISR) upon receiving the interrupt.

The driver 732 may be responsible for controlling or interfacing with the underlying hardware. For example, drivers 732 may include a display driver, a camera driver, a video driver, and a video driver, depending on the hardware configuration,Drivers, flash drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers),Drivers, NFC drivers, audio drivers, power management drivers, and the like.

The library 716 may provide a common infrastructure that may be utilized by the application 720 and/or other components and/or layers. The library 716 generally provides functionality that allows other software modules to perform tasks in a manner that is easier than directly interfacing with the underlying operating system 714 functionality (e.g., the kernel 728, services 730, and/or drivers 732). The libraries 716 may include system 734 libraries (e.g., C-standard libraries) that may provide functions such as memory allocation functions, string manipulation functions, mathematical functions, and the like. Additionally, the libraries 716 may include API libraries 736, such as media libraries (e.g., libraries used to support the rendering and manipulation of various media formats (e.g., MPEG4, h.264, MP3, AAC, AMR, JPG, PNG)), graphics libraries (e.g., OpenGL framework that may be used to render 2D and 9D in graphical content on a display), database libraries (e.g., SQLite that may provide various relational database functions), website libraries (e.g., WebKit that may provide website browsing functionality), and the like. The library 716 can also include a wide variety of other libraries 738 to provide many other APIs to the application 720 and other software components/modules.

Framework 718, also sometimes referred to as middleware, may provide a higher-level common infrastructure that may be utilized by applications 720 and/or other software components/modules. For example, the framework 718 may provide various Graphical User Interface (GUI) functions, advanced resource management, advanced location services, and the like. Framework 718 may provide a wide spectrum of other APIs that may be utilized by applications 720 and/or other software components/modules, some of which may be specific to a particular operating system or platform.

The applications 720 include built-in applications 740 and/or third-party applications 742. Examples of representative built-in applications 740 may include, but are not limited to, a contacts application, a browser application, a book-viewer application, a positioning application, a media application, a messaging application, and/or a gaming application. The third party applications 742 may include built-in applications as well as any of a wide variety of other applications. In a particular example, the third-party application 742 (e.g., using Android by an entity other than a vendor of a particular platform)^TMOr iOS^TMApplications developed by Software Development Kit (SDK) may be in a mobile operating system (e.g., iOS)^TM、Android^TM、Phone or other mobile computing device operating system). In this example, the third party application 742 may invoke the API call 724 provided by the mobile operating system (e.g., operating system 714) to facilitate the functionality described herein.

The application programs 720 may utilize built-in operating system functions (e.g., kernel 728, services 730, and/or drivers 732), libraries (e.g., system 734, API 736, and other libraries 738), framework/middleware 718 to generate a user interface to interact with users of the system. Alternatively or additionally, in some systems, interaction with a user may occur through a presentation layer (e.g., presentation layer 744). In these systems, the application/module "logic" may be separate from the aspects of the application/module that interact with the user.

Some software architectures utilize virtual machines. For example, the systems described herein may be executed using one or more virtual machines executing at one or more server computers. In the example of FIG. 7, this is illustrated by virtual machine 748. The virtual machine creates a software environment in which applications/modules can execute as if they were executing on a hardware computing device. The virtual machine is hosted by the host operating system (operating system 714) and typically (although not always) has a virtual machine monitor 746 that manages the operation of the virtual machine and the interface with the host operating system (i.e., operating system 714). The software architecture executes within virtual machines such as operating system 750, libraries 752, framework/middleware 754, application programs 756, and/or presentation layer 758. Such layers of the software architecture executing within virtual machine 748 may or may not be the same as the corresponding layers previously described.

Fig. 8 illustrates a block diagram of an example machine 800 on which any one or more of the techniques (e.g., methods) discussed herein may be performed. In alternative embodiments, the machine 800 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine 800 may operate in the capacity of a server machine, a client machine, or both in server-client network environments. In an example, the machine 800 may operate as a peer machine in a peer-to-peer (P2P) (or other distributed) network environment. The machine 800 may be a Personal Computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a mobile telephone, a web appliance, an IoT device, an automotive system, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), other computer cluster configurations.

As described herein, examples may include or be operable by logic, components, devices, packages, or mechanisms. A circuit system is a collection of circuits (e.g., a set of circuits) implemented in a tangible entity that includes hardware (e.g., simple circuits, gates, logic, etc.). The circuitry members may be flexible over time and have underlying hardware variability. The circuitry includes components that, when operated, may perform particular tasks either individually or in combination. In an example, the hardware of the circuitry may be designed unchanged to carry out a particular operation (e.g., hardwired). In an example, the hardware of the circuitry may include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.) including non-transitory computer-readable media that are physically modified (e.g., magnetically, electrically, movably-placed invariant mass particles, etc.) to encode instructions of a particular operation. When physical components are connected, the underlying electrical properties of the hardware makeup change, for example, from an insulator to a conductor or vice versa. The instructions enable the participating hardware (e.g., execution units or loading mechanisms) to generate, via the variable connections, components of circuitry in the hardware to perform portions of specific tasks in operation. Thus, while the device is operating, the computer-readable medium is communicatively coupled to other components of the circuitry. In an example, any of the physical components may be used in more than one component of more than one circuitry. For example, under operation, an execution unit may be used in a first circuit of a first circuitry at one point in time and reused by a second circuit in the first circuitry or a third circuit in a second circuitry at a different time.

A machine (e.g., computer system) 800 (e.g., host device 102, etc.) may include a hardware processor 802 (e.g., a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a hardware processing core, or any combination thereof, such as memory controller 116, etc.), a main memory 804, and a static memory 806, some or all of which may communicate with each other via an interconnect (e.g., bus) 808. The machine 800 may further include a display unit 810, an alphanumeric input device 812 (e.g., a keyboard), and a User Interface (UI) navigation device 814 (e.g., a mouse). In an example, the display unit 810, the input device 812, and the UI navigation device 814 may be a touch screen display. The machine 800 may additionally include a storage device (e.g., drive unit) 816, a signal generation device 818 (e.g., a speaker), a network interface device 820, and one or more sensors 817 such as a Global Positioning System (GPS) sensor, compass, accelerometer, or other sensor. The machine 800 may include an output controller 828, such as a serial (e.g., Universal Serial Bus (USB)), parallel, or other wired or wireless (e.g., Infrared (IR), Near Field Communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).

The storage 816 may include a machine-readable medium 822 on which is stored one or more sets of data structures or instructions 824 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. For example, instructions 824 may be associated with host application 110, local driver 106, PUF utility 120, or other suitable software. The instructions 824 may also reside, completely or at least partially, within the main memory 804, within static memory 806, or within the hardware processor 802 during execution thereof by the machine 800. In an example, one or any combination of the hardware processor 802, the main memory 804, the static memory 806, or the storage device 816 may constitute a machine-readable medium 822.

While the machine-readable storage medium 822 is illustrated as a single medium, the term "machine-readable storage medium" can include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) configured to store the one or more instructions 824.

The term "machine-readable medium" can include any medium that is capable of storing, encoding or carrying instructions for execution by the machine 800 and that cause the machine 800 to perform any one or more of the techniques of this disclosure or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting examples of machine-readable media can include solid-state memory and optical and magnetic media. In an example, a clustered (massed) machine-readable medium includes a machine-readable medium having a plurality of particles with an invariant (e.g., stationary) mass. Thus, a clustered machine readable medium does not propagate signals temporarily. Specific examples of a cluster-type machine-readable medium may include: non-volatile memories such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

Instructions 824 (e.g., software, programs, an Operating System (OS), etc.) or other data are stored on the storage device 821, accessible by the memory 804, for use by the processor 802. The memory 804 (e.g., DRAM) is typically fast but volatile and thus a different type of memory than the storage device 821 (e.g., SSD), the storage device 821 being suitable for long-term storage (including when in an "off state). Instructions 824 or data used by a user or the machine 800 are typically loaded into memory 804 for use by the processor 802. When the memory 804 is full, virtual space from the storage device 821 may be allocated to supplement the memory 804; however, since memory 821 is typically slower than memory 804 and write speeds are typically at least twice slower than read speeds, the use of virtual memory can significantly reduce the user experience (compared to memory 804 (e.g., DRAM)) due to storage latency. Furthermore, using storage 821 for virtual memory may substantially reduce the usable life of storage 821.

In contrast to virtual memory, virtual memory compression (e.g.,kernel feature "ZRAM") uses portions of memory as compressed block memory to avoid pages to storage 821. Paging occurs in compressed blocks until it is necessary to write this data to the storage device 821. Virtual memory compression increases the available size of memory 804 while reducing wear on storage device 821.

Storage devices or mobile memory optimized for mobile electronic devices traditionally include MMC solid state storage devices (e.g., micro secure digital (microSD)^TM) Card, etc.). The MMC device comprisesSeveral parallel interfaces (e.g., 8-bit parallel interfaces) of the host device, and may generally be components removed from and separated from the host device. In contrast, eMMC^TMThe device is attached to a circuit board and is considered a component of a host device, which has a serial ATA based interface^TMSSD devices (serial AT (advanced technology) attachment or SATA) have comparable read speeds. However, demands for mobile device performance continue to increase, such as fully implementing virtual or augmented reality devices, utilizing increased network speeds, and so forth. In response to this demand, the storage device has been converted from a parallel communication interface to a serial communication interface. A Universal Flash Storage (UFS) device, including a controller and firmware, communicates with a host device using a Low Voltage Differential Signaling (LVDS) serial interface with a dedicated read/write path, further advancing greater read/write speeds.

Instructions 824 may further be transmitted or received over a communication network 826 using a transmission medium via network interface device 820 utilizing any one of a number of transport protocols, such as frame relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), hypertext transfer protocol (HTTP), etc. Example communication networks may include a Local Area Network (LAN), a Wide Area Network (WAN), a packet data network (e.g., the internet), a mobile telephone network (e.g., a cellular network), a Plain Old Telephone (POTS) network, and a wireless data network (e.g., referred to asOf the Institute of Electrical and Electronics Engineers (IEEE)802.11 family of standards, known asIEEE 802.16 family of standards), IEEE 802.15.4 family of standards, peer-to-peer (P2P) networks, and the like. In an example, the network interface device 820 may include one or more physical jacks (e.g., ethernet, coaxial, or telephone jacks) or one or more antennas to connect to the communication network 826. In an example, network interface device 820 may include multiple antennas to perform using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) techniquesAnd (4) wireless communication. The term "transmission medium" shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine 800, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.

The above embodiments include reference to the accompanying drawings (which form a part hereof). The drawings show, by way of illustration, specific embodiments in which the invention may be practiced. Such embodiments are also referred to herein as "examples. Such examples may include elements other than those shown or described. However, the inventors also contemplate examples in which only the elements shown or described are provided. Moreover, the inventors also contemplate using examples of any combination or permutation of the elements shown or described (or one or more aspects thereof) with respect to a particular example (or one or more aspects thereof) or with respect to other examples (or one or more aspects thereof) shown or described herein.

In this document, the terms "a" or "an" (as is common in patent documents) are used to include one or more, independent of any other instances or usages of "at least one" or "one or more. In this document, unless otherwise indicated, the term "or" is used to refer to a non-exhaustive or such that "a or B" may include "a but not B", "B but not a", and "a and B". In the appended claims, the terms "including" and "in which" are used as the plain-english equivalents of the respective terms "comprising" and "wherein. Also, in the following claims, the terms "comprising" and "including" are open-ended, i.e., a system, device, article, or process that includes elements in addition to those listed after the term is still considered to be within the scope of the claims. Furthermore, in the following claims, the terms "first," "second," and "third," etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.

In various embodiments, the components, controllers, processors, units, engines, or tables described herein may include, among other things, physical circuitry or firmware stored on a physical device. As used herein, "processor" means any type of computing circuit, such as, but not limited to, a microprocessor, a microcontroller, a graphics processor, a Digital Signal Processor (DSP), or any other type of processor or processing circuit, including a group of processors or multi-core devices.

The term "horizontal" as used in this document is defined as a plane parallel to the conventional plane or surface of the substrate (e.g., located beneath a wafer or die), regardless of the actual orientation of the substrate at any point in time. The term "vertical" refers to a direction perpendicular to horizontal as defined above. Prepositions (e.g., "on … …," "above … …," and "below … …") are defined with respect to a conventional plane or surface on the top or exposed surface of the substrate, regardless of the orientation of the substrate; and while "on … …" is intended to imply that one structure is in direct contact with another structure "on" the one structure (with no express indication to the contrary); the terms "above … …" and "below … …" expressly contemplate identifying the relative placement of structures (or layers, features, etc.), which expressly includes (but is not limited to) direct contact between identified structures unless specifically so identified. Similarly, the terms "above … …" and "below … …" are not limited to a horizontal orientation, as a structure may be "above" a reference structure if it is the outermost portion of the construction in question at some point in time, even though such structure extends vertically relative to the reference structure rather than in a horizontal orientation.

The terms "wafer" and "substrate" are used herein to generally refer to any structure on which integrated circuits are formed and also to such structures during various stages of integrated circuit fabrication. The following embodiments are, therefore, not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

Various embodiments in accordance with the present invention and described herein include memories (e.g., NAND strings of memory cells) that utilize a vertical memory cell structure. As used herein, the directional adjective will be considered relative to the surface of the substrate on which the memory cell is formed (i.e., the vertical structure will be considered to extend away from the substrate surface, the bottom end of the vertical structure will be considered to be the end closest to the substrate surface and the top end of the vertical structure will be considered to be the end furthest from the substrate surface).

As used herein, unless otherwise indicated, directional adjectives (e.g., horizontal, vertical, normal, parallel, vertical, etc.) may refer to relative orientations and are not intended to require strict adherence to particular geometric properties. For example, as used herein, a vertical structure need not be strictly perpendicular to a surface of a substrate, but may instead be substantially perpendicular to a surface of a substrate, and may form an acute angle (e.g., between 60 and 120 degrees, etc.) with a surface of a substrate.

In some embodiments described herein, different doping configurations may be applied to the source side Select Gate (SGS), Control Gate (CG), and drain side Select Gate (SGD), in this example, each of which may be formed of or at least include polysilicon, such that these stacks (e.g., polysilicon, etc.) may have different etch rates when exposed to an etch solution. For example, in forming a monolithic pillar in a 3D semiconductor device, the SGS and CG may form a groove, while the SGD may remain less recessed or even not recessed. These doping configurations may thus be able to be selectively etched into different tiers (e.g., SGS, CG, and SGD) in a 3D semiconductor device by using an etching solution, such as tetramethylammonium hydroxide (TMCH).

As used herein, operating a memory cell includes reading, writing, or erasing a memory cell. The operation of placing a memory cell in a desired state is referred to herein as "programming" and may include both writing to or erasing from the memory cell (e.g., the memory cell may be programmed to an erased state).

In accordance with one or more embodiments of the present disclosure, a memory controller (e.g., processor, controller, firmware, etc.) located internal or external to a memory device is capable of determining (e.g., selecting, setting, adjusting, calculating, changing, clearing, communicating, adapting, deriving, defining, utilizing, modifying, applying, etc.) a number of wear cycles or a wear state (e.g., recording wear cycles, counting memory device operations as they occur, tracking their starting memory device operations, evaluating memory device characteristics corresponding to the wear state, etc.).

In accordance with one or more embodiments of the present disclosure, a memory access device may be configured to provide wear cycle information to a memory device at each memory operation. Memory device control circuitry (e.g., control logic) can be programmed to compensate for memory device performance changes corresponding to wear cycle information. The memory device may receive the wear cycle information and determine one or more operating parameters (e.g., values, characteristics) in response to the wear cycle information.

It will be understood that when an element is referred to as being "on," "connected to" or "coupled with" another element, it can be directly on, connected or coupled with the other element or intervening elements may be present. In contrast, when an element is referred to as being "directly on," "directly connected to" or "directly coupled with" another element, there are no intervening elements or layers present. Two elements may be coupled or directly coupled if they are shown in the figures as connected by a wire, unless otherwise indicated.

The method examples described herein may be implemented, at least in part, using a machine or computer. Some examples may include a computer-readable medium or machine-readable medium encoded with instructions operable to configure an electronic device to perform a method as described in the above examples. Implementations of such methods may include program code, such as microcode, assembly language code, higher level language code, or the like. This program code may include computer readable instructions for performing various methods. The program code may form part of a computer program product. Further, the program code may be tangibly stored on one or more volatile or non-volatile tangible computer-readable media, e.g., during execution or at other times. Examples of such tangible computer-readable media may include, but are not limited to, hard disks, removable magnetic disks, removable optical disks (e.g., compact disks and digital optical disks), magnetic cassettes, memory cards or sticks, Random Access Memories (RAMs), Read Only Memories (ROMs), Solid State Drives (SSDs), Universal Flash Storage (UFS) devices, embedded mmc (emmc) devices, and the like.

Example 1 is a system for providing a digital fingerprint of a selected portion of a memory device to a host device, comprising: a memory device; a host device comprising local memory separate from the memory device, the host device for executing drivers and host applications, wherein the host device is configured to perform operations comprising: sending, by the host application, a command to the driver to generate digital fingerprint data, the command including an output pointer to a memory location of the local memory to be written to the digital fingerprint data; generating, by the driver, a modified command, wherein the modified command does not include the output pointer; sending, by the driver, the modified command to the memory device; receiving, by the driver, a reply including the digital fingerprint data describing a selected portion of the memory device; and writing the digital fingerprint data to a location at the memory location of the local memory indicated by the output pointer.

In example 2, the subject matter of example 1 optionally includes wherein the host device is further configured to perform operations comprising: decrypting, by a driver, the digital fingerprint data using a host device public key prior to writing the digital fingerprint data to the location at the local memory indicated by the output pointer.

In example 3, the subject matter of any one or more of examples 1-2 optionally includes wherein the command includes an input parameter, and wherein the host device is further configured to perform operations comprising encrypting the input parameter based at least in part on a public key associated with the memory device.

In example 4, the subject matter of any one or more of examples 1-3 optionally includes wherein the host device is further configured to perform operations comprising sending an instantiation command to the memory device, wherein the instantiation command indicates an allocation size indicating an amount of memory at the memory device to be allocated to a PUF.

In example 5, the subject matter of example 4 optionally includes wherein the instantiate command also indicates a host public key used to encrypt digital fingerprint data at the memory device.

In example 6, the subject matter of any one or more of examples 1-5 optionally includes wherein the command is an enrollment command, and wherein the digital fingerprint data includes an activation code.

In example 7, the subject matter of any one or more of examples 1-6 optionally includes wherein the command comprises an activate code received in response to a previous command to the driver.

In example 8, the subject matter of any one or more of examples 1-7 optionally includes wherein the command includes an indication of a key type and wherein the digital fingerprint data includes a key of the key type.

In any one or more of examples 1-8, the digital fingerprint comprises a PUF and the digital fingerprint data may include PUF data.

Example 9 is a method for providing a digital fingerprint to a host device, comprising: sending, by a host application executing at the host device, a command to a driver executing at the host device to generate digital fingerprint data, the command including an output pointer indicating a memory location of a local memory of the host device to which the digital fingerprint data is to be written; generating, by the driver, a modified command, wherein the modified command does not include the output pointer; sending, by the driver, the modified command to an external memory device; receiving, by the driver, a reply including the digital fingerprint data; and writing the digital fingerprint data to a location at the memory location of the local memory indicated by the output pointer.

In example 10, the subject matter of example 9 optionally includes decrypting, by a driver, the digital fingerprint data using a host device private key prior to writing the digital fingerprint data to the location at the local memory indicated by the output pointer.

In example 11, the subject matter of any one or more of examples 9-10 optionally includes wherein the command includes input parameters, further comprising encrypting the input parameters based at least in part on a public key associated with the memory device.

In example 12, the subject matter of any one or more of examples 9-11 optionally includes sending an instantiation command to the memory device, wherein the instantiation command indicates an allocation size indicating an amount of memory to be allocated at the memory device of a PUF.

In example 13, the subject matter of example 12 optionally includes wherein the instantiate command also indicates a host public key used to encrypt digital fingerprint data at the memory device.

In example 14, the subject matter of any one or more of examples 9-13 optionally includes wherein the command is an enrollment command, and wherein the digital fingerprint data includes an activation code.

In example 15, the subject matter of any one or more of examples 9-14 optionally includes wherein the command comprises an activate code received in response to a previous command to the driver.

In example 16, the subject matter of any one or more of examples 9-15 optionally includes wherein the command includes an indication of a key type and wherein the digital fingerprint data includes a key of the key type.

In any one or more of examples 9-16, the digital fingerprint comprises a PUF and the digital fingerprint data may include PUF data.

Example 17 is a non-transitory computer-readable medium comprising instructions thereon, which when executed by a hardware processor, cause the hardware processor to perform operations comprising: sending, by a host application executing at the hardware processor, a command to a driver executing at the host device to generate digital fingerprint data, the command including an output pointer indicating a memory location of a local memory associated with the hardware processor to which the digital fingerprint data is to be written; generating, by the driver, a modified command, wherein the modified command does not include the output pointer; sending, by the driver, the modified command to a memory device; receiving, by the driver, a reply including the digital fingerprint data; and writing the digital fingerprint data to a location at the memory location of the local memory indicated by the output pointer.

In example 18, the subject matter of example 17 optionally includes wherein the operations further comprise decrypting, by a driver, the digital fingerprint data using a host device private key prior to writing the digital fingerprint data to the location at the local memory indicated by the output pointer.

In example 19, the subject matter of any one or more of examples 17-18 optionally includes wherein the command includes input parameters, and wherein operations further comprise encrypting the input parameters based at least in part on a public key associated with the memory device.

In example 20, the subject matter of any one or more of examples 17-19 optionally includes wherein the operations further comprise sending an instantiation command to the memory device, wherein the instantiation command indicates an allocation size that indicates an amount of memory to be allocated at the memory device of a PUF.

In any one or more of examples 17-20, the digital fingerprint comprises a PUF and the digital fingerprint data may include PUF data.