阅读说明：本技术 存取网络时的安全通信 (Secure communication while accessing a network ) 是由 A·蒙代洛 A·特罗亚 于 2020-03-09 设计创作，主要内容包括：本文中描述存取网络时的安全通信。实例设备可包含存储器及耦合到所述存储器的处理器。所述处理器可经配置以从标识装置接收标识公钥。可响应于向所述标识装置提供修改所述标识装置的内容的请求而接收所述标识公钥。所述处理器可进一步经配置以使用所述标识公钥对与订户信息对应的数据进行加密,(向所述标识装置)提供所述经加密数据以将所述订户信息存储在所述标识装置中,及经由存储在所述标识装置中的所述数据存取由网络运营商运营的网络。(Secure communications when accessing a network are described herein. An example apparatus may include a memory and a processor coupled to the memory. The processor may be configured to receive an identification public key from an identification device. The identification public key may be received in response to providing the identification device with a request to modify content of the identification device. The processor may be further configured to encrypt data corresponding to subscriber information using the identification public key, provide the encrypted data (to the identification device) to store the subscriber information in the identification device, and access a network operated by a network operator via the data stored in the identification device.)

1. An apparatus, comprising:

a memory; and

a processor coupled to the memory, the processor configured to:

receiving an identification public key from an identification device, wherein the identification public key is received in response to providing a request to the identification device to modify content of the identification device;

encrypting data corresponding to subscriber information using the identification public key;

providing the encrypted data to the identification device to store the data in the identification device; and

accessing a network operated by a network operator via the data stored in the identification means.

2. The apparatus of claim 1, wherein the processor is configured to:

receiving, from a server operated by the network operator, a device secret along with the data corresponding to the subscriber information;

generating a subscriber public key based on the received device secret; and

providing the subscriber public key to the identification means, wherein the identification of the apparatus is verified based on at least the subscriber public key.

3. The apparatus of claim 2, wherein the identification public key is received from the identification device in response to authenticating the apparatus based on the subscriber public key.

4. The apparatus according to any of claims 1 to 3, wherein the network operator is a first network operator,

and wherein the request to modify the content of the identified device comprises at least one of:

a request to handover a network operator from a second network operator to the first network operator; or

Adding a request of the first network operator.

5. An apparatus, comprising:

a memory; and

a processor coupled to the memory, the processor configured to:

generating an identification public key and an identification private key in response to receiving a request from a subscriber device to modify contents of the memory;

providing the identification public key to the subscriber device;

receiving data from the subscriber device in response to providing the identification public key, wherein the received data is encrypted by the subscriber device using the identification public key;

decrypting the received data using the identification private key; and

modifying the content of the memory based on the decrypted data.

6. The apparatus of claim 5, wherein a subscriber public key is received from the subscriber device along with the request to modify the content of the processor, and wherein the processor is configured to:

verifying an identity of the subscriber device based at least on the subscriber public key prior to generating an identity public key and the identity private key; and

generating the identification public key and the identification private key in response to verifying the identification of the subscriber device.

7. The apparatus of claim 6, wherein the processor is configured to: in response to not authenticating the subscriber device, discarding the data received from the subscriber device.

8. The apparatus of claim 6, wherein the processor is configured to:

receiving a subscriber public identity and a subscriber certificate from the subscriber device along with the subscriber public key; and

comparing the subscriber public key to an output of a decryption component to verify the identity of the subscriber device, wherein the subscriber public identity, the subscriber certificate, and the subscriber public key are entered into the decryption component.

9. The apparatus of claim 8, wherein the decryption component comprises a first decryptor and a second decryptor, and wherein:

the subscriber public key and the subscriber certificate are input into the subscriber decryptor; and is

The output of the first decryptor and the subscriber public key are input into the second decryptor, wherein the output of the second decryptor is compared with the subscriber public key.

10. A method, comprising:

in response to receiving a request to modify content of an identification device and a subscriber public key from a subscriber device, verifying an identification of the subscriber device based at least on the subscriber public key;

generating an identification public key and an identification private key in response to verifying the identification of the subscriber device;

in response to providing the identification public key to the subscriber device, receiving data corresponding to subscriber information encrypted based on the identification public key;

in response to decrypting the data using the identification private key, modifying the content of the identification device based on the decrypted subscriber information.

11. The method of claim 10, wherein modifying the content of the identification device based on the decrypted subscriber information comprises:

adding a network operator associated with the decrypted subscriber information to the identification device such that a network operated by the network operator is accessed by the subscriber device using the decrypted subscriber information stored in the identification device.

12. The method of claim 10, wherein the decrypted subscriber information corresponds to a first network operator, and wherein modifying the content of the identification device based on the decrypted subscriber information comprises:

switching a network operator from a second network operator to the first network operator.

13. The method of any one of claims 10-12, further comprising encrypting and decrypting the subscriber information using a Device Identification Combining Engine (DICE) -robust internet of things (RIOT) protocol.

14. The method of any of claims 10-12, further comprising preventing generation of the identification public key and the identification private key in response to the subscriber device not being authenticated.

15. A system, comprising:

a subscriber device configured to receive data corresponding to subscriber information from a server operated by a network operator; and

a Subscriber Identity Module (SIM) in wireless communication with the subscriber device, the SIM configured to:

receiving, from the subscriber device, a subscriber public key and a request to modify content of data stored in the SIM;

in response to verifying an identity of the subscriber device, providing an identity public key to the subscriber device, wherein the identity of the subscriber device is verified based on the received subscriber public key;

wherein the subscriber device is configured to:

encrypting the data corresponding to the subscriber information based on the identification public key;

providing the encrypted data to the SIM;

wherein the SIM is configured to decrypt the data corresponding to the subscriber information such that the subscriber device is configured to access a network operated by the network operator via the subscriber information stored in the SIM.

16. The system of claim 15, wherein:

the subscriber device is configured to:

generating a subscriber public identity and a subscriber certificate along with the subscriber public key; and

providing the subscriber public identity, the subscriber certificate, and the subscriber public key to the SIM; and is

The SIM is configured to perform a comparison between the subscriber public identity, the subscriber certificate, and the subscriber public key to verify the identity of the subscriber device.

17. The system of claim 16, wherein the SIM is configured to:

generating an identification public identity and an identification certificate along with the identification public key based at least on the subscriber public key received from the subscriber device; and

providing the identification public identity, the identification certificate, and the identification public key back to the subscriber device.

18. The system of claim 15, wherein the subscriber device comprises an asymmetric identification generator, and wherein the subscriber device is configured to:

generating a private subscriber identity using the asymmetric identity generator together with the public subscriber identity.

19. The system of any of claims 15-18, wherein the subscriber device comprises an asymmetric key generator, and wherein the subscriber device is configured to:

generating a subscriber private key using the asymmetric key generator along with the subscriber public key.

20. The system of any of claims 15-18, wherein the SIM is configured to:

generating an identification private key based on a device secret of the SIM together with the identification public key; and

providing the identification public key to the subscriber device;

wherein the subscriber device is configured to verify an identity of the SIM based on the identity public key.

Technical Field

The present disclosure relates generally to apparatus, methods, and systems, and more particularly, to secure communications in an access network.

Background

Memory devices are typically provided as internal semiconductor integrated circuits and/or external removable devices in computers or other electronic devices. There are many different types of memory, including volatile and non-volatile memory. Volatile memory may require power to maintain its data and may include Random Access Memory (RAM), Dynamic Random Access Memory (DRAM), and Synchronous Dynamic Random Access Memory (SDRAM), among others. Non-volatile memory can provide persistent data by retaining stored data when not powered, and can include NAND flash memory, NOR flash memory, Read Only Memory (ROM), and resistance variable memory, such as Phase Change Random Access Memory (PCRAM), Resistive Random Access Memory (RRAM), and Magnetoresistive Random Access Memory (MRAM), among other memories.

Memory devices may be combined together to form Solid State Drives (SSDs), embedded multimedia cards (e.mmcs), and/or Universal Flash Storage (UFS) devices. SSD, e.mmc and/or UFS devices may include non-volatile memory (e.g., NAND flash memory and/or NOR flash memory), and/or may include volatile memory (e.g., DRAM and/or SDRAM), as well as various other types of non-volatile and volatile memory. Non-volatile memory may be used in a wide range of electronic applications, such as personal computers, portable memory sticks, digital cameras, cellular telephones, portable music players such as MP3 players, movie players, and other electronic devices.

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

The memory cells can be arranged in an array, and the memory cells in the array architecture can be programmed to a target (e.g., desired) state. For example, charge can be placed on or removed from a charge storage architecture (e.g., floating gate) of a flash memory cell to program the cell to a particular data state. The stored charge on the charge storage architecture of a cell may be indicative of the threshold voltage (Vt) of the cell. The state of a flash memory cell can be determined by sensing the stored charge (e.g., Vt) on the cell's charge storage architecture.

Many threats may affect the operation of a memory device and/or the data stored in the memory cells of a memory device. Such threats may result in significant economic losses, and/or may present significant security and/or safety issues.

Drawings

Fig. 1 is a block diagram of an example subscriber device in accordance with an embodiment of the disclosure.

Fig. 2 is a block diagram of an example identification device, according to an embodiment of the present disclosure.

Fig. 3 is a block diagram of an example computing system capable of wireless communication with a server and a network in accordance with an embodiment of the present disclosure.

Fig. 4 is a block diagram of an example system including a subscriber device and an identification device in accordance with an embodiment of the disclosure.

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

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

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

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

Fig. 9 illustrates a flow chart illustrating an example method for accessing a network according to an embodiment of the present disclosure.

FIG. 10 is a block diagram of a computing system including a host and an apparatus in the form of a memory device, according to an embodiment of the disclosure.

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

Detailed Description

Secure communications when accessing a network are described herein. An example apparatus may include a memory and a processor coupled to the memory. The processor may be configured to receive an identification public key from an identification device. The identification public key may be received in response to providing the identification device with a request to modify content of the identification device. The processor may be further configured to encrypt data corresponding to subscriber information using the identification public key, provide the encrypted data (to the identification device) to store the subscriber information in the identification device, and access a network operated by a network operator via the data stored in the identification device.

The user device may store data corresponding to personal information that may identify itself within the network so that a service provider of the network may authorize it based on the personal information. Typically, the personal information may be stored within the user device and/or in a remote memory device that is wirelessly accessible to the user device. In either case, personal information may be exposed to many threats from hackers and/or other malicious activities, and such hacking activities may result in significant economic losses, and/or may pose significant security and/or safety issues.

Some previous approaches provide anti-hacking mechanisms that may include, for example, a timestamp, a random number generator, and/or a counter (e.g., a monotonic counter) that may provide a piece of information that changes each time personal information is accessed and/or exchanged. However, such previous anti-hacking mechanisms may require additional components and/or circuitry specifically dedicated to anti-hacker functionality, which may increase the size and/or complexity of the circuitry of the memory.

In contrast, embodiments of the present disclosure may provide an anti-hacking mechanism that ensures secure memory while not requiring additional circuitry dedicated exclusively to anti-replay functionality, which may reduce the size and/or complexity of the circuitry of the memory as compared to memories utilizing previous anti-hacking mechanisms. For example, such anti-hacking mechanisms can utilize existing circuitry of a memory (e.g., existing firmware of a memory device) to provide anti-hacker functionality without having to add additional (e.g., new) components or circuitry specifically dedicated for anti-hacker functionality.

The figures herein follow a numbering convention in which the first digit or digits correspond to the drawing figure number of the drawing and the remaining digits identify an element or component in the drawing. Similar elements or components between different figures may be identified by the use of similar digits. For example, 102 may be referred to in fig. 1 as element "02," and similar elements may be referred to in fig. 3 as 302.

Fig. 1 is a block diagram of an example subscriber device 102 in accordance with an embodiment of the disclosure. As used herein, a subscriber device may refer to a device used by a subscriber (e.g., user) of a particular network operator to access a network (e.g., network 308) operated by the particular network operator. As used herein, a network operator may refer to an entity that provides access and/or services to users via a network. The terms "network operator," "mobile operator," "service provider," and "operator" are used interchangeably herein and may have the same meaning, depending on the context.

Subscriber devices 102 may include User Equipment (UE) devices such as laptops, personal computers, digital cameras, digital recording and playback devices, mobile phones, PDAs, memory card readers, interface hubs, or internet of things (IoT) -capable devices, such as automobiles (e.g., vehicles and/or transportation infrastructures) IoT-capable devices or medical (e.g., implantable and/or health monitoring) IoT-capable devices, as well as other host systems, and may include memory access devices (e.g., processors). One of ordinary skill in the art will appreciate that "processor" may mean one or more processors, such as a parallel processing system, a plurality of coprocessors, or the like.

Subscriber device 102 may include memory resources 112, processing resources 114, and transceiver resources 116, as illustrated in fig. 1. The memory resources 112 (which may also be referred to as "memory") may include memory (e.g., memory cells) arranged in multiple bank groups, banks, bank sections, sub-arrays, and/or rows, such as multiple memory devices. In some embodiments, the memory resources 112 may include a plurality of memory devices, such as a plurality of volatile memory devices formed and/or operable as RAM, DRAM, SRAM, SDRAM, and/or TRAM, among other types of volatile memory. In some embodiments, the memory resources 112 may include a plurality of non-volatile memory devices formed and/or operable as PCRAM, RRAM, FeRAM, MRAM and/or STT RAM, phase change memory, 3DXPoint and/or flash memory devices, among other types of non-volatile memory devices. In some embodiments, the memory resources 112 may include a combination of multiple volatile memory devices and multiple non-volatile memory devices, as described herein.

Although not shown in fig. 1, the memory resource 112 can be coupled to and/or include a controller that can send commands to perform operations on the memory resource 112, including operations to sense (e.g., read), program (e.g., write), move, and/or erase data.

The processing resource 114 may be coupled to the memory resource 112 and the transceiver resource 116, and configured to access data stored in the memory resource 112 via the transceiver (e.g., the transceiver resource 116) and/or data stored at a server (e.g., the server 306), a network (e.g., the network 308), and/or an identification device (e.g., the identification device 304).

As used herein, a "transceiver" may be referred to as a device that includes both a transmitter and a receiver. In one embodiment, the transceiver may be and/or include a plurality of Radio Frequency (RF) transceivers. In various embodiments, the transmitter and receiver may be combined and/or share common circuitry. In an embodiment, no circuitry may be shared between transmit and receive functions, and the device may be referred to as a transmitter-receiver. Other devices consistent with the present disclosure may include repeaters, converters, and/or repeaters, and the like. As used herein, the terms "transceiver resource" and "transceiver" are used interchangeably herein and may have the same meaning, depending on the context.

Various wireless communication techniques may be used to communicate with different entities (e.g., server 306, network 308, and/or identification device 304) via transceiver resources 116. For example, different generations of broadband mobile telecommunication technology (e.g., first to fifth generations (1G-5G)), device-to-device communications, including bluetooth, Zigbee, 1G-5G, and/or Long Term Evolution (LTE) device-to-device communication technologies, and/or other wireless communications utilizing intermediate devices (e.g., WiFi utilizing an access point AP) may be used to communicate with different entities.

In some embodiments, the subscriber device 102 may access an identification device (e.g., identification device 302) to wirelessly utilize data stored in the identification device. As an example, the subscriber device 102 may access data stored in the identification device to further access a network (e.g., network 308) operated by a particular network operator. More details of the access identification means are described in connection with fig. 3.

Fig. 2 is a block diagram of an example identification device 204, in accordance with an embodiment of the present disclosure. The identification means 204 may be a Subscriber Identity Module (SIM). As used herein, a SIM may refer to a module that stores data (e.g., information) that may be used by a subscriber device to access a network (e.g., network 108). In one example, the identifying means 204 may be implemented as an application on a smart card, such as a Universal Integrated Circuit Card (UICC), that may be removably coupled to the subscriber device 102. In another example, the identification device 204 need not be physically present within the subscriber device 102 and/or removably coupled to the subscriber device 102. In this example, the subscriber device 102 may wirelessly access the identification device 204 via the transceiver resources 116.

The identification device 204 may include memory resources 218, processing resources 220, and transceiver resources 222, as illustrated in fig. 2. The memory resources 218 (which may also be referred to as "memory") may include memory (e.g., memory cells) arranged in multiple bank groups, banks, bank sections, sub-arrays, and/or rows, such as multiple memory devices. In some embodiments, the memory resources 218 may include a plurality of memory devices, such as a plurality of volatile memory devices formed and/or operable as RAM, DRAM, SRAM, SDRAM, and/or TRAM, among other types of volatile memory. In some embodiments, the memory resources 218 may include a plurality of non-volatile memory devices formed and/or operable as PCRAM, RRAM, FeRAM, MRAM and/or STT RAM, phase change memory, 3DXPoint and/or flash memory devices, among other types of non-volatile memory devices. In some embodiments, the memory resources 218 may include a combination of multiple volatile memory devices and multiple non-volatile memory devices, as described herein.

Although not shown in fig. 2, the memory resource 218 can be coupled to and/or include a controller that can send commands to perform operations on the memory resource 218, including operations to sense (e.g., read), program (e.g., write), move, and/or erase data.

The memory resources 218 may store data corresponding to various types of information, such as subscriber information. As used herein, subscriber information may refer to information that may identify and authenticate a particular subscriber device (e.g., subscriber device 102) in a network. As an example, the subscriber information may include an International Mobile Subscriber Identity (IMSI) number (e.g., an IMSI number that identifies a subscriber device in a carrier network), an International Mobile Equipment Identity (IMEI) number, a Personal Identification Number (PIN) (e.g., a code that the subscriber device uses to access the identified device), a personal unlock code and/or personal unlock key (PUC/PUK), an authentication key (K/Ki), and/or network status information, e.g., received from a Location Area Identity (LAI) (e.g., information indicating the location of the subscriber device). The memory resource 218 may also store non-subscriber information, such as a plurality of text messages (e.g., Short Message Service (SMS) messages) and/or contact information for a subscriber device.

Processing resources 220 may be coupled to memory resources 218 and transceiver resources 222, and configured to receive data from different entities, such as a subscriber device (e.g., subscriber device 102) and/or a network (e.g., network 308), via transceiver resources 222.

Various wireless communication techniques may be used to communicate with different entities, such as subscriber device 302 and/or network 308, via transceiver resources 222. For example, different generations of broadband mobile telecommunication technologies (e.g., 1G-5G), device-to-device communications, including bluetooth, Zigbee, 1G-5G, and/or LTE device-to-device communication technologies, and/or other wireless communications utilizing intermediate devices (e.g., WiFi utilizing access points APs) may be used to communicate with different entities.

In some embodiments, the identification device 204 may authenticate the subscriber device, provide a particular key that the subscriber device may use to encrypt data, and decrypt data received from the subscriber device using another key generated along with the particular key. More details of authentication, provisioning, and decryption are described in connection with fig. 3.

Fig. 3 is a block diagram of an example computing system 310 capable of wireless communication with server 306 and network 308 in accordance with an embodiment of the disclosure. The subscriber device 302 and the identification device 304 may be, for example, the subscriber device 102 and the identification device 204 previously described in connection with fig. 1 and 2, respectively. In one example, subscriber device 302 may utilize identification device 304 to access network 308. In another example, the identification device 304 may be part of another subscriber device (e.g., a wearable device, such as a smart watch), whose SIM (e.g., implemented within the identification device 304) may be activated by the subscriber device 302.

Subscriber device 302 may communicate (e.g., wirelessly) with server 306. By communicating with server 306, subscriber device 302 can obtain data to be stored in identification device 304 and/or used to access network 308. As an example, the data available from server 306 may include subscriber information, as described in connection with fig. 2.

Various different techniques may be utilized to initiate communication with the server 306. For example, a Quick Response (QR) code (e.g., from a network operator) may be provided to a user of the subscriber device 302, which may direct the subscriber device to a server (e.g., server 306) such that the user may obtain data from the server by scanning the QR code through the subscriber device. For example, a user of a subscriber device may be directed to log into a particular website that may provide subscriber information. For example, the subscriber device 302 may be physically coupled to a particular device that transmits subscriber information to the subscriber device.

Although server 306 is illustrated as being separate from network 308, server 306 may be part of network 308. Thus, in some embodiments, subscriber device 302 may initially be provided with (e.g., limited) access to the carrier network to access server 306. For example, subscriber device 302 may initially be provided with a boot SIM and utilize the boot SIM to access server 306 of network 308.

The subscriber device 302 may further communicate (e.g., wirelessly) with the identification device 304. For example, the content of the identification device 304 (e.g., data stored therein) may be modified according to a request of the subscriber device 302. As used herein, an identifying device (e.g., SIM) whose contents may be modified may be referred to as an embedded SIM (esim). As an example, the eSIM can modify the content to add another network operator, switch to a different network operator, and/or delete existing subscriber information corresponding to a particular network operator so that the subscriber device 302 can no longer access the network 308 via the particular network operator. Thus, in some embodiments, the eSIM can include a plurality of subscriber information corresponding to a plurality of respective network operators, such that the subscriber device 302 can select a network operator among the plurality of network operators to access the network 308.

Communication between the subscriber device 302 and the identification device 304 may be performed in a secure manner. In an embodiment, the subscriber device 302 may receive (e.g., from the server 306) data to be sent to the identification device 304, request the identification device 304 to authenticate the subscriber device 302 (e.g., handshake), encrypt the data using a security key received from the identification device 304 (e.g., upon authentication by the identification device 304), and provide the encrypted data to the identification device 304. In an embodiment, the identifying means 304 may provide (e.g., in response to authenticating the subscriber device 302) a particular key to the subscriber device 302, receive data encrypted with the particular key previously provided, and decrypt the data using another key, the key generated with the particular key previously provided to the subscriber device 302. Upon successful decryption of data received from the subscriber device 302, the identification device 304 may store the decrypted data such that the subscriber device 302 may access the identification device 304 to access the network 308 via the decrypted data. Further details of exchanging keys and data between the subscriber device 302 and the identification device 304 are described below.

Fig. 4 is a block diagram of an example system including a subscriber device 402 and an identification device 404, according to an embodiment of the disclosure. The subscriber device 402 and the identification device 404 may be a subscriber device 102 and an identification device 204, respectively, such as previously described in connection with fig. 1 and 2. As an example, the identification device 404 can be an eSIM of a wearable device (e.g., a smart watch) that is different from the subscriber device 402. In this example, the subscriber device 402 can be configured to wirelessly activate an eSIM of the wearable device such that the wearable device can access a network (e.g., network 108) via the activated eSIM.

Computing devices may be started in stages using tiers, where each tier authenticates and loads subsequent tiers, and provides increasingly complex runtime services at each tier. A layer may be serviced by a previous layer and serviced by a subsequent layer, thus creating an interconnected network of layers that are built up on lower layers and that service higher layers. In the embodiment illustrated in FIG. 5, layer 0 ("L₀") 451 and layer 1 (" L₁") 453 within the subscriber device 402. Layer 0451 may provide Firmware Derived Secret (FDS) key 452 to layer 1453. FDS key 452 may describe the identity of the code of layer 1453 and other security-related data. In an example, a particular protocol, such as the robust internet of things (RIOT) core protocol, may use the FDS 452 to verify the code of the layer 1546 that it loads. In an example, the particular protocol may include a Device Identification Combining Engine (DICE) and/or a RIOT core protocol. As an example, the FDS may include the layer 1 firmware image itself, a manifest that cryptographically identifies authorized layer 1 firmware, a firmware version number of signed firmware in the context of a secure boot implementation, and/or a security critical configuration setting of the device.

Device secret 458 may be used to create FDS 452 and stored in memory of subscriber device 402. In some embodiments, device secret 458 may be received from a server (e.g., server 106) operated by a particular network operator. In an example operation, the subscriber device 402 may read the device secret 458, the identification of the hash layer 1453, and perform calculations, including:

K_L1KDF [ fs(s), Hash ("immutable info")]

Wherein K_L1For public keys, KDF (e.g., KDF defined in National Institute of Standards and Technology (NIST) Special publication 800-108) is the key derivation function (i.e., HMAC-SHA256), and Fs(s) is device secret 458. The FDS 452 may be determined by performing the following operations:

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

The subscriber device 402 may transmit data to the identification device 404, as illustrated by arrow 454. As an example, the transmitted data may include a public subscriber identification, certificate (e.g., a subscriber identification certificate), and/or a subscriber public key before subscriber device 402 is authenticated by identification device 404. As an example, after the subscriber device 402 is authenticated by the identification device 404, the transmitted data may include data to be stored in the identification device 404, such as data corresponding to subscriber information (e.g., as described in connection with fig. 2), contact information, and/or a text message of the subscriber device 402.

Identifying layer 2 ("L") of device 404₂") 455 may receive the transmitted data and execute the data in the operation of an operating system (" OS ") 457 and on first application 459-1 and second application 459-2. The identifying means 404 may also transmit data to the subscriber device 402, as illustrated by arrow 456.

In some embodiments, data (e.g., subscriber information, contact information, and/or text messages) to be stored in identification device 404 may also be received simultaneously along with a subscriber public identification, subscriber identification certificate, and/or subscriber public key received for authenticating subscriber device 402. In this example, the allowable data may be stored in the identification device 404 when the subscriber device 402 is authenticated and may be discarded when the subscriber device 402 is not authenticated by the identification device 404. Further details of the authentication device (e.g., subscriber device 402 and/or identification device 404) are described in connection with fig. 6.

Fig. 5 is a block diagram of an example process for determining a plurality of parameters, in accordance with an embodiment of the present disclosure. Fig. 5 is an example of determining parameters, including a public identity (e.g., 565), a certificate (e.g., 581), and a public key (e.g., 583), which are then sent to layer 2 (e.g., layer 2455) of an identifying device (e.g., 404 in fig. 4) as indicated by arrow 554. As used herein, the public identity, certificate, and public key generated from the subscriber device 402 may be referred to as a subscriber public identity, subscriber certificate, and subscriber public key, respectively. Layer 0 ("L") in FIG. 5₀") 551 corresponds to layer 0451 and likewise FDS 552 corresponds to FDS 452, layer 1553 corresponds to layer 1453, and arrows 554 and 556 correspond to arrows 454 and 456, respectively.

FDS 552 from layer 0551 is sent to layer 1553 and used by asymmetric ID generator 561 to generate a common identification ("ID_{lk public}") 565 and a private identification 567. Under the abbreviation "ID_{lk public}"in," lk "indicates layer k (in this example, layer 1), and" public "indicates that the identity is publicly shared. Public identity 565 is illustrated as being shared by arrows extending to the right and outside of layer 1553 of the subscriber device (e.g., subscriber device 402). The generated private identity 567 is used as a key input to the encryptor 573. The encryptor 573 may be any processor, computing device, etc. for encrypting data.

Layer 1553 of the subscriber device may include an asymmetric key generator 563. In at least one example, random number generator (RND)536 may optionally input a random number into asymmetric key generator 563. Asymmetric key generator 563 may generate a subscriber public key ("K") associated with a subscriber device, such as subscriber device 402 in FIG. 4_{Lk public}") 569 and a subscriber private key (" K_{LK private}")571. Subscriber public key 569 may be input to encryptor 573 (as "data"). The encryptor 573 may use the inputs of the subscriber private identity 567 and the subscriber public key 569 to generate the result K' 575. The subscriber private key 571 and the result K'575 can be input into the additional encryptor 577, producing the output K "579. The output K "579 isCertificate ("ID") transmitted to layer 2 (455 of FIG. 4)_L1Certificate ") 581. The subscriber certificate 581 may provide the ability to verify and/or authenticate the source of data sent from the device. As an example, data sent from a subscriber device may be associated with an identification of the subscriber device through a certificate of authenticity, as will be further described in connection with fig. 6. In addition, the subscriber public key ("K)_{L1 public key}") 583 may be transmitted to layer 2. Thus, the public identification 565, certificate 581, and public key 583 of the subscriber device may be transmitted to layer 2 of the identification device.

Fig. 6 is a block diagram of an example process of verifying a certificate according to an embodiment of the present disclosure. In the illustrated example of fig. 6, the public key 683, certificate 681, and public identification 665 are provided from the subscriber device (e.g., from the layer 1453 of the subscriber device 402 in fig. 4). The data of the certificate 681 and the public key 683 can be used as input to the decryptor 685. Decryptor 685 may be any processor, computing device, etc., for decrypting data. The result of the decryption of the certificate 681 and the public key 683 can be used as an input to a secondary decryptor 687, along with the public identity, to produce an output. The public key 683 and output from the decryptor 687 may indicate, as illustrated at 689, whether to verify the certificate 681, producing yes or no 691 as output.

In response to the certificate 681 being verified, further data may be exchanged between the subscriber device and the identification device. In one example, in response to the subscriber device being authenticated, the public key, certificate, and public identification generated at the identification device may be provided back to the subscriber device. In another example, in response to the subscriber device being authenticated, the subscriber device may further provide data to be stored in the identification device and may accept, decrypt, and process the data. However, in response to the certificate not being authenticated, data received from the authenticated device may be discarded, removed, and/or ignored and/or further exchange of data between the two may be prohibited. In this way, malicious devices that send malicious data can be detected and avoided. As an example, a hacker sending the pending data may be identified without processing the hacked data. More details of the data exchange after authentication are described in connection with fig. 7.

FIG. 7 is a flowchart for determining multiple numbers according to an embodiment of the present disclosureBlock diagram of an example process of parameters. FIG. 7 illustrates generating an identification ("ID)_L2Public ") 766, certificates (" ID_L2Certificate ") 782 and the public key (" K_{L2 public key}") 784 (e.g., identification device 404 of fig. 4). As used herein, a public identity, certificate, and public key generated at an identification device (e.g., identification device 404) may be referred to as an identification public identity, identification certificate, and identification public key, respectively.

Subscriber public key ("K") transmitted from layer 1 of subscriber device to layer 2755 of identification device_{L1 public key}") 783, as described in FIG. 5, is used by the asymmetric ID generator 762 of the identification device to generate a public identification (" ID ") of the identification device_{lk public}") 766 and a private identification 768. Under the abbreviation "ID_{lk public}"in" lk "indicates layer k (layer 2 in this example), and" public "indicates that the identification is publicly shared. The public identification 766 is illustrated as being shared by an arrow extending to the right and outside 2755. The generated private identity 768 is used as a key input into the encryptor 774.

Layer 2755 of the identifying device may contain asymmetric key generator 764. In at least one example, random number generator (RND)738 may optionally input a random number into asymmetric key generator 764. Asymmetric key generator 764 may generate a public key ("K") associated with an identifying device, such as identifying device 406 in fig. 4_{Lk public}") 770 and a private key (" K_{LK private}")772. The identification public key 770 may be an input (as "data") into the encryptor 774. Encryptor 774 may generate result K'776 using inputs identifying private identity 768 and identifying public key 770. The identification private key 772 and the result K'776 may be input into an additional encryptor 778, producing the output K "780. The output K "780 is the identification certificate (" ID ") transmitted back to layer 1 (453 of FIG. 4)_L2Certificate ") 782. Identification credential 782 may provide the ability to verify and/or authenticate the source of data sent from the device. As an example, the data sent from the identification device may be associated with the identification of the identification device through a certificate of authenticity, as will be further described in connection with fig. 7. In addition, a public key ("K") is identified_{L2 public key}") 784 may be transmitted to the layer1. Thus, the public identification 766, certificate 782, and public key 784 identifying the device may be transmitted to layer 1 of the subscriber device.

In an example, in response to the subscriber device receiving the public key from the identification device, the subscriber device may encrypt data to be sent to the identification device using the identification public key. Vice versa, the identification device may encrypt data to be sent to the subscriber device using the subscriber public key. In response to the identification device receiving the data encrypted using the identification public key, the identification device may decrypt the data using its unique private key (e.g., the identification private key). Likewise, in response to the subscriber device receiving data encrypted using the subscriber public key, the subscriber device may decrypt the data using its unique private key (e.g., the subscriber private key). Since the identification private key is not shared with another device external to the identification device and the subscriber private key is not shared with another device external to the subscriber device, the data sent to the identification device and the subscriber device remains secure.

In an embodiment, a first entity initially requesting a handshake with a second entity may generate a first public key, a first public identity, and a first certificate based on its unique device secret. In another aspect, a second entity that receives the handshake request may generate a second public key, a second public identity, and a second certificate based on a first public key provided by the first entity. For example, the embodiments illustrated in fig. 4, 5, and 7 illustrate a subscriber device (e.g., subscriber device 402) as the entity that initially requests a handshake with an identification device (e.g., identification device 404). In this embodiment, the subscriber device generates a public key (e.g., public key 583), a public identification (e.g., public identification 565), and a certificate (e.g., certificate 581) based on a device secret of the subscriber device (e.g., provided from a network operator), and the identification device generates those based on the public key provided from the subscriber device. However, the embodiments are not limited thereto. For example, the identification device may initially request a handshake with the subscriber device, such that the identification device generates a public key, a public identity, and a certificate using its unique device secret, while the subscriber device generates those based on the public key provided from the identification device.

Fig. 8 is a block diagram of an example process of verifying a signature according to an embodiment of the present disclosure. In the event that the device is sending data that can be verified to avoid subsequent repudiation, a signature can be generated and sent with the data. As an example, a first device may issue a request to a second device, and once the second device executes the request, the first device may indicate that the first device never issued such a request. A non-repudiation method, for example using a signature, may avoid repudiation by the first device and ensure that the second device can subsequently perform the requested task without difficulty.

A subscriber device 802 (e.g., subscriber device 102 in fig. 1) can send data 890 to an identification device 804 (e.g., identification device 204 in fig. 2). The subscriber device 802 may generate a signature 896 at 894 using the device private key 871. The signature 896 may be transmitted to the identification device 804. At 898, the identifying device 804 can verify the signature using the previously received data 892 and the subscriber public key 869. In this way, the signature is generated using the private key and verified using the public key. In this way, the unique signature of each device may be kept private to the device sending the signature, while allowing the receiving device to be able to decrypt the signature for verification. This is in contrast to encryption/decryption of data, which is encrypted by the sending device using the public key of the receiving device and decrypted by the receiving device using the private key of the receiver. In at least one example, the device may verify the digital signature by using an internal cryptographic process, such as Elliptic Curve Digital Signature (ECDSA) or similar process.

Fig. 9 illustrates a flow chart illustrating an example method 992 for accessing a network in accordance with an embodiment of the present disclosure. At block 993, the method 992 may include verifying (e.g., by an identification device) an identification of the subscriber device based at least on the subscriber public key. The subscriber device may be authenticated when the identification device receives a request to modify content of the identification device (e.g., from the subscriber device). Along with the request, a subscriber public key may also be received from the subscriber device. The subscriber device and identification device may be, for example, subscriber device 302 and identification device 304, as previously described in connection with fig. 3.

At block 995, method 992 may include generating (e.g., by an identification device) an identification public key and an identification private key. The identification public key and the identification private key may be generated when the identification device authenticates the subscriber device. Otherwise, the identifying device may not generate those and refrain from receiving data from the subscriber device and/or discard data received from the subscriber device. The identification public key may be provided to the subscriber device such that the subscriber device may encrypt data to be sent to the identification device using the identification public key.

At block 997, method 992 may include receiving (e.g., at an identification device) data corresponding to subscriber information encrypted using an identification public key. The encrypted data may be further decrypted at the identification device, e.g., using an identification private key generated along with an identification public key previously provided to the subscriber device. Encryption and decryption of data may be performed using the DICE-RIOT protocol.

At block 999, the method 992 may include modifying content of the identification device based on the decrypted subscriber information. As described herein, the decrypted subscriber information may be accessed by the subscriber device further to access a network operated by a particular operator.

Fig. 10 is a block diagram of a computing system 1034 including a host 1005 and an apparatus in the form of a memory device 1003, according to an embodiment of the disclosure. In an example, the host 1005 and memory device 1003 can be the subscriber device 102 and identification device 204 as previously described in connection with fig. 1 and 2, respectively. As used herein, an "apparatus" may refer to, but is not limited to, any of a variety of structures or combinations of structures, such as a circuit or circuitry, one or more dies, one or more modules, one or more devices, or one or more systems. Further, in an embodiment, computing system 1034 may include a plurality of memory devices similar to memory device 1003.

In the embodiment illustrated in FIG. 10, memory device 1003 may include a memory 1030 having a memory array 1001. The memory array 1001 may be similar to the memory resources 112 and/or 218 previously described in connection with fig. 1 and 2, respectively. Moreover, the memory array 1001 may be a secure array, as will be further described herein. Although one memory array 1001 is illustrated in FIG. 10, memory 1030 may include any number of memory arrays similar to memory array 1001.

As illustrated in FIG. 10, host 1005 may be coupled to memory device 1003 via an interface 1024. Host 1005 and memory device 1003 may communicate (e.g., send commands and/or data) over interface 1024. The host 1005 and/or memory device 1003 may be, or be part of, a laptop computer, a personal computer, a digital camera, a digital recording and playback device, a mobile phone, a PDA, a memory card reader, an interface hub, or an internet of things (IoT) -capable device, such as an automobile (e.g., vehicle and/or transportation infrastructure) IoT-capable device or a medical (e.g., implantable and/or health monitoring) IoT-capable device, as well as other host systems, and may include a memory access device (e.g., a processor). One of ordinary skill in the art will appreciate that "processor" may mean one or more processors, such as a parallel processing system, a plurality of coprocessors, or the like.

In some embodiments, interface 1024 may be in the form of a standardized physical interface. For example, when memory device 1003 is used for information storage in computing system 1034, interface 1024 may be a serial advanced technology bus attachment (SATA) physical interface, a peripheral component interconnect express (PCIe) physical interface, a Universal Serial Bus (USB) physical interface, or a Small Computer System Interface (SCSI) as well as other physical connectors and/or interfaces. In general, however, interface 1024 may provide an interface for passing control, address, information (e.g., data), and other signals between memory device 1003 and a host (e.g., host 1005) that has a compatible receiver for interface 1024.

In some embodiments, interface 1024 may be used for wireless communication technologies, such as different generations of broadband mobile telecommunication technologies (e.g., 1G-5G), device-to-device communications, including bluetooth, Zigbee, 1G-5G, and/or Long Term Evolution (LTE) device-to-device communication technologies, and/or other wireless communications utilizing intermediate devices (e.g., WiFi utilizing an access point AP) may be used to communicate with different entities, as described in connection with fig. 1 and 2.

The memory device 1003 includes a controller 1009 to communicate with a host 1005 and memory 1030, such as the memory array 1001. For example, the controller 1009 may send commands to perform operations on the memory array 1001, including operations to sense (e.g., read), program (e.g., write), move, and/or erase data, among other operations.

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

The host 1005 may include a host controller (not shown in fig. 10) to communicate with the memory device 1003. The host controller may send commands to memory device 1003 via interface 1024. The host controller may communicate with memory device 1003 and/or controller 1009 on memory device 1003 to read, write, and/or erase data, among other operations. Further, in embodiments, host 1005 may be an IoT-capable device, as previously described herein, having IoT communication capabilities.

A controller 1009 on the memory device 1003 and/or a host controller on the host 1005 may include control circuitry and/or logic (e.g., hardware and firmware). In an embodiment, the controller 1009 on the memory device 1003 and/or the host controller on the host 1005 may be an Application Specific Integrated Circuit (ASIC) coupled to a printed circuit board including a physical interface. Further, the memory device 1003 and/or the host 1005 may include a buffer of volatile and/or nonvolatile memory and a plurality of registers.

For example, as shown in fig. 10, a memory device may include circuitry 1026. In the embodiment illustrated in fig. 10, circuitry 1026 is included in controller 1009. However, embodiments of the present disclosure are not limited thereto. For example, in an embodiment, circuitry 1026 may be included (e.g., on the same die) in memory 1030 (e.g., instead of in controller 1009). The circuitry 1026 may include, for example, hardware, firmware, and/or software.

Circuitry 1026 may generate block 1032 in the block chain for verifying (e.g., authenticating and/or certifying) data stored in memory 1030 (e.g., in memory array 1001). Block 1032 may include a cryptographic hash of (e.g., to a link to) a previous block in the chain of blocks, and a cryptographic hash of (e.g., identifying) data stored in the memory array 1001. Block 1032 may also contain a header with a timestamp indicating when the block was generated. Further, block 1032 may have a digital signature associated therewith indicating that the block is included in the chain of blocks.

The cryptographic hash of the data stored in the memory array 1001 and/or the cryptographic hash of a previous block in the chain of blocks may include, for example, a SHA-256 cryptographic hash. Further, the cryptographic hash of the data stored in the memory array 1001 and the cryptographic hash of the previous block in the block chain may each include 256 bytes of data, respectively.

A cryptographic hash of the data stored in the memory array 1001 may be generated (e.g., computed), for example, by the circuitry 1026. In such examples, the cryptographic hash of the stored data may be generated internally by memory device 1003 without requiring the external data to be moved over interface 1024. As an additional example, a cryptographic hash of the data may be communicated from an external entity. For example, the host 1005 may generate a cryptographic hash of the data stored in the memory array 1001 and send the generated cryptographic hash to the memory device 1003 (e.g., the circuitry 1026 may receive the cryptographic hash of the data stored in the memory array 1001 from the host 1005).

A digital signature associated with block 1032 may be generated (e.g., computed), for example, by circuitry 1026 based on (e.g., in response to) an external command, such as a command received from host 1005. For example, a digital signature may be generated using symmetric or asymmetric cryptography. As an additional example, host 1005 may generate a digital signature and send (e.g., provide) the generated digital signature to memory device 1003 (e.g., circuitry 1026 may receive the digital signature from host 1005).

As shown in fig. 10, block 1032 and the digital signature associated with block 1032 may be stored in the memory array 1001. For example, block 1032 may be stored in a portion of memory array 1001 that is not accessible to a user of memory device 1003 and/or host 1005 (e.g., in a "hidden" area of memory array 1001). Storing blocks 1032 in the memory array 1001 may simplify storage of the blocks, for example, by eliminating the need for software storage management of the blocks.

In an embodiment, the memory array 1001 (e.g., a subset of the array 1001, or the entire array 1001) may be a secure array (e.g., an area of the memory 1030 to be kept under control). For example, data stored in the memory array 1001 may include sensitive (e.g., non-user) data, such as host firmware and/or code to be executed for sensitive applications. In such embodiments, a pair of non-volatile registers may be used to define the secure array. For example, in the embodiment illustrated in FIG. 10, circuitry 1026 includes registers 1028-1 and 1028-2, which may be used to define a secure array. For example, register 1028-1 may define an address of the secure array (e.g., a starting LBA of the data), and register 1028-2 may define a size of the secure array (e.g., an ending LBA of the data). Once the secure array has been defined, circuitry 1026 may generate (e.g., compute) a cryptographic hash associated with the secure array, referred to herein as a gold hash, using an authenticated and anti-replay protection command (e.g., such that only memory device 1003 is aware of the gold hash, and only memory device 1003 is capable of generating and updating the gold hash). The golden hash may be stored in an inaccessible portion of the memory array 1001 (e.g., where the same inaccessible portion of block 1032 is stored) and may be used during the process of verifying the data of the secure array.

Memory device 1003 (e.g., circuitry 1026) can send block 1032 along with a digital signature associated with block 1032 to host 1005 via interface 1024 for verification of data stored in memory array 1001. For example, circuitry 1026 can sense (e.g., read) a block 1032 stored in the memory array 1001 and send the sensed block to the host 1005 in response to powering on (e.g., powering on and/or powering on) the memory device 1003 to verify data stored in the array 1001. As such, verification of data stored in the memory array 1001 may be initiated when the memory device 1003 is powered on (e.g., automatically).

As an additional example, circuitry 1026 may send block 1032 to host 1005 along with a digital signature associated with block 1032 when an external entity (e.g., host 1005) initiates verification of data stored in memory array 1001. For example, host 1005 may send a command to memory device 1003 (e.g., circuitry 1026) to sense block 1032, and circuitry 1026 may execute the command to sense block 1032 and send the sensed block to host 1005 for verifying data stored in array 1001 in response to receiving the command.

Upon receiving the block 1032, the host 1005 may use the received block to verify (e.g., determine whether to verify) the data stored in the memory array 1001. For example, the host 1005 may verify the data using a cryptographic hash of the previous block in the block chain and a cryptographic hash of the data stored in the memory array 1001. Further, host 1005 may verify the digital signature associated with block 1032 to determine that the block is included (e.g., eligible for inclusion) in the chain of blocks. As used herein, verifying data stored in the memory array 1001 may include and/or refer to authenticating and/or certifying that the data is authentic (e.g., the same as originally programmed) and has not been altered or otherwise unauthorized by hackers.

In embodiments where the memory array 1001 is a secure array, the gold hash previously described herein may also be used to verify data stored in the memory array 1001. For example, a runtime cryptographic hash may be generated (e.g., computed) and compared to a golden hash. If the comparison indicates that the runtime matches the golden hash, it may be determined that the secure array has not changed and, therefore, the data stored therein is valid. However, if the comparison indicates that the runtime and golden hashes do not match, this may indicate that the data stored in the secure array has changed (e.g., due to a hacker or a failure in memory), and this may be reported to the host 1005.

After verifying the data stored in the memory array 1001, the circuitry 1026 can generate an additional (e.g., next) block in the chain of blocks to verify the data stored in the memory array 1001 in a manner similar to the generation of block 1032. For example, such an additional block may include a cryptographic hash of block 1032 (which has now become the previous block in the chain of blocks), and a new cryptographic hash of the data stored in the memory array 1001. Further, such additional block may include a header with a timestamp indicating when such block was generated, and may have a digital signature associated therewith indicating that such block is included in the chain of blocks. Further, in embodiments where the memory array 1001 is a secure array, an additional (e.g., new) golden hash may be generated.

The additional blocks, as well as the digital signatures and additional gold hashes associated with the additional blocks, may be stored in the memory array 1001. For example, the additional block may replace block 1032 (e.g., the previous block) in the memory array 1001. The host 1005 may then verify the data stored in the memory array 1001 using the additional blocks, the digital signature, and the additional gold hash, in a manner similar to that previously described herein for block 1032. Additional blocks in the block chain may continue to be generated by circuitry 1026 and used by host 1005 to verify data stored in memory array 1001 in such a manner throughout the life of memory device 1003.

The embodiment illustrated in fig. 10 may include additional circuitry, logic, and/or components not illustrated so as not to obscure embodiments of the present disclosure. For example, memory device 1003 may include address circuitry to latch address signals provided through I/O connectors by the I/O circuitry. Address signals may be received and decoded by a row decoder and a column decoder to access the memory array 1001. Further, the memory device 1003 may include a main memory, such as DRAM or SDRAM, separate from and/or in addition to the memory array 1001. Examples further illustrating additional circuitry, logic, and/or components of memory device 1003 are further described herein (e.g., in connection with fig. 11).

FIG. 11 is a block diagram of an example memory device 1103, according to an embodiment of the present disclosure. For example, the memory device 1103 may be the subscriber device 102 or the identification device 206 described in connection with fig. 1 and 2, respectively.

As shown in FIG. 11, memory device 1103 may include a plurality of memory arrays 1101-1 to 1101-7. Further, in the example illustrated in FIG. 11, memory array 1101-3 is a secure array, subset 1111 of memory array 1101-6 includes the secure array, and subsets 1113 and 1115 of memory array 1101-7 include the secure array. Subsets 1111, 1113, and 1115 may each include, for example, 4 kilobytes of data. However, embodiments of the present disclosure are not limited to a particular number or arrangement of memory arrays or security arrays.

As shown in fig. 11, the memory device 1103 may include a repair (e.g., restore) block 1117. The repair block 1117 may serve as a data source in the event of an error (e.g., a mismatch) that may occur during operation of the memory device 1103. The repair block 1117 may be outside of the area of the memory device 1103 that is addressable by the host.

As shown in fig. 11, memory device 1103 may include a Serial Peripheral Interface (SPI)1107 and a controller 1109. Memory device 1103 may use SPI 1107 and controller 1109 to communicate with the host and memory arrays 1101-1 to 1101-7.

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

As shown in fig. 11, the memory device 1103 may include a key 1121. For example, the memory device 1103 may include eight different slots to store keys such as a root key, a DICE-RIOT key, and/or other external session keys.

As shown in fig. 11, the memory device 1103 may include an Electronically Erasable Programmable Read Only Memory (EEPROM) 1123. EEPROM 1123 can provide a secure, non-volatile area for a host in which individual bytes of data can be erased and programmed.

As shown in fig. 11, memory device 1103 may include a counter (e.g., monotonic counter) 1125. For example, the memory device 1103 may include six different monotonic counters, two of which may be used by the memory device 1103 for authenticated commands, and four of which may be used by the host.

As shown in fig. 11, the memory device 1103 may include a SHA-256 cryptographic hash function 1127 and/or an HMAC-SHA256 cryptographic hash function 1129. The SHA-256 and/or HMAC-SHA256 cryptographic hash functions 1127 and 1129 may be used by the memory device 1103 to generate cryptographic hashes, e.g., cryptographic hashes of commands as previously described herein, and/or to verify data golden hashes stored in the memory arrays 1101-1 to 1101-7. Further, the memory device 1103 may support L0 and L1 of die-RIOT 1131.

In the preceding detailed description, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific examples. In the drawings, like numerals describe substantially similar components throughout the several views. Other examples may be utilized and structural, logical, and/or electrical changes may be made without departing from the scope of the present disclosure.

The figures herein follow a numbering convention in which the first digit or digits correspond to the drawing figure number of the drawing and the remaining digits identify an element or component in the drawing. Similar elements or components between different figures may be identified by the use of similar digits. As will be appreciated, elements shown in the various embodiments herein can be added, exchanged, and/or eliminated so as to provide a number of additional embodiments of the present disclosure. Additionally, as will be appreciated, the proportion and the relative scale of the elements provided in the figures are intended to illustrate the embodiments of the present disclosure, and should not be taken in a limiting sense.

As used herein, "a," "an," or "a number of" something may refer to one or more of such things. "plurality" something means two or more than two. As used herein, the term "coupled" may include not electrically coupled, directly coupled, and/or directly connected (e.g., by direct physical contact) to intermediate elements or indirectly coupled and/or connected to intermediate elements. The term coupled may further include two or more elements that cooperate or interact with each other (e.g., as a cause and effect relationship).

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