Security Descriptor Generation

By injecting device-specific secrets into the terminal device and using the FSD generator to generate credentials and password key pairs, the complexity and cost problems of end users need to upload information are solved, and efficient and secure authentication of the terminal device is achieved.

CN112434349BActive Publication Date: 2025-01-10MICRON TECHNOLOGY INC
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202010861491.4
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2019-08-26
Filing Date
2020-08-25
Publication Date
2025-01-10
Estimated Expiration
2040-08-25

AI Technical Summary

Technical Problem

In the prior art, in the process of identifying terminal devices, end users need to upload direct input information about terminal devices, resulting in increased deployment complexity, increased cost and deployment delay problems.

Method used

By injecting device-specific secrets into the memory of the terminal device, using a firmware security descriptor (FSD) generator to generate credentials and password key pairs based on publicly available information and device-specific secrets, achieving information without the need for a user to enter directly Identification process.

Benefits of technology

The credentials and key generation of multiple terminal devices is simplified, the deployment complexity and cost are reduced, and the authentication efficiency and security of terminal devices are improved.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN112434349B_ABST
    Figure CN112434349B_ABST
Patent Text Reader

Abstract

This application is directed to security descriptor generation. Methods, systems, and apparatus for security descriptor generation are described. A terminal device may be authenticated based on a credential and a device key based on a security descriptor. The security descriptor may be generated based on publicly available information, such as time of day information, geographic information, or a default information set. The security descriptor may be used to generate a credential that may be accessed by a server for authenticating the device and may also be used by the terminal device to generate a device key that is used for verification by the server authenticating the device.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] Cross-references

[0002] This patent application claims priority to U.S. patent application No. 16 / 551,551, entitled “SECURITY DESCRIPTOR GENERATION,” filed by DUVAL on August 26, 2019, which is assigned to the present assignee and is expressly incorporated herein by reference in its entirety. Technical Field

[0003] The technical field relates to security descriptor generation. Background Art

[0004] Memory devices are widely used to store information in various electronic devices such as computers, wireless communication devices, cameras, digital displays, etc. Information is stored by programming different states of the memory device. For example, binary devices most often store one of two states, which are often represented by a logical 1 or a logical 0. In other devices, more than two states may be stored. To access the stored information, a component of the device may read or sense at least one stored state in the memory device. To store information, a component of the device may write or program a state in the memory device.

[0005] There are various types of memory devices, including magnetic hard disks, random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase change memory (PCM), etc. Memory devices can be volatile or non-volatile. Non-volatile memory such as FeRAM can maintain a stored logic state for a long time even in the absence of an external power source. Volatile memory devices such as DRAM can lose their stored state when disconnected from an external power source.

[0006] Some devices employed by end users (e.g., terminal devices) may pass an authentication process before performing communications with a server (e.g., an Internet server). For example, the server may authenticate the terminal device based on a key associated with the terminal device and a certificate accessible to the server. Summary of the invention

[0007] A method is described. In some examples, the method may include receiving a request for a credential associated with authenticating a terminal device; identifying publicly available information based at least in part on receiving the request; generating a firmware security descriptor based at least in part on identifying the publicly available information; generating the credential based at least in part on the firmware security descriptor and a device-specific secret associated with the terminal device; and transmitting the credential for authenticating the terminal device to a server associated with authenticating the terminal device.

[0008] A method is described. In some examples, the method may include, by a terminal device, receiving a firmware security descriptor generated with publicly available information; obtaining an identifier derived from a device-specific secret stored in a memory of the terminal device; generating a cryptographic key pair including a public key and a private key based at least in part on receiving the firmware security descriptor generated with publicly available information and obtaining the identifier derived from the device-specific secret; and authenticating the terminal device based at least in part on the cryptographic key pair.

[0009] A device is described. In some examples, the device may include a receiver configured to receive a request for a credential associated with authenticating a terminal device; a firmware security descriptor generator configured to: identify publicly available information based at least in part on receiving the request; generate a firmware security descriptor based at least in part on identifying the publicly available information; generate the credential based at least in part on the firmware security descriptor and a device-specific secret associated with the terminal device; and generate a cryptographic key pair including a public key and a private key based at least in part on the firmware security descriptor and the device-specific secret associated with the terminal device, wherein the credential includes the public key of the cryptographic key pair; and a transmitter configured to transmit the credential for authenticating the terminal device to a server associated with authenticating the terminal device. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 An example of a system supporting security descriptor generation according to examples as disclosed herein is described.

[0011] Figure 2 An example of an authentication process supporting security descriptor generation according to examples as disclosed herein is described.

[0012] Figure 3 A block diagram of a firmware security descriptor (FSD) based security system supporting security descriptors according to examples as disclosed herein is shown.

[0013] Figure 4A block diagram showing a terminal device supporting security descriptor generation according to examples as disclosed herein.

[0014] Figures 5 to 7 A flow chart illustrating one or more methods of supporting security descriptor generation according to examples as disclosed herein is shown. DETAILED DESCRIPTION

[0015] End users (e.g., customers or clients of manufacturers of devices or components of devices) may deploy and operate some devices, such as Internet of Things (IoT) devices. Such devices may be referred to as end devices. Once deployed, the end device may be authenticated before communicating with a server (e.g., an Internet server or other server deployed for use by the end user). For example, before accessing data at a server or providing data to a server, the end device may undergo an authentication procedure by the server to ensure that the end device requesting access to the server is a specific device or a non-malicious device (e.g., a tamper-free device).

[0016] The server may authenticate the terminal device based on a key associated with the terminal device (e.g., a device alias key) and a credential stored at the server or otherwise accessible by the server. For example, a security descriptor (e.g., a firmware security descriptor (FSD)) may be used to generate the credential and the key associated with the device, and in some cases, the security descriptor may be based on the source code of a boot loader (e.g., a second-stage boot loader) of the terminal device (e.g., the security descriptor may be a hash code or function of the second-stage boot loader). The second-stage boot loader may be specific to the implementation of the terminal device, and the manufacturer of the terminal device may not be exposed to implementation-specific information during the manufacturing or production process of the terminal device. In a scenario where the manufacturer is to provide credentials to a terminal user operating a specific terminal device, information associated with the implementation of the terminal device, information related to the terminal user, device-specific information, or other information may be directly input by the terminal user and provided to the manufacturer before the credentials and keys for authentication are generated. In some deployment scenarios, such as when an end user operates multiple terminal devices, generating and entering implementation information, device-specific information, or other information for each of the multiple devices can increase the complexity of the deployment process, can cause deployment delays, or increase costs to the manufacturer or end user of the terminal device (or components of the terminal device), among other problems.

[0017] According to the technology described herein, a terminal device may include a memory device for authentication of the terminal device. An injection system may inject a device-specific secret (e.g., a unique device identifier) ​​into the memory device. An FSD generator may generate an FSD for authentication, which may be used to generate a memory device alias key (e.g., a private key) and a credential associated with a public key of the memory device. The FSD generator may utilize data available when the terminal device first initializes a connection (e.g., when the terminal device first connects to the Internet), such as time and date, geographic location of the terminal device, or other information, to generate the FSD. Such data may be referred to as publicly available data. In some cases, the FSD may be used by a terminal user to generate device alias keys for multiple terminal devices operated by the terminal user, wherein each of the multiple terminal devices includes a corresponding memory device into which different device-specific secrets are injected.

[0018] The server may use cryptographic techniques to authenticate or verify the terminal device. For example, the terminal device may sign a data packet using a private cryptographic key and send the signed data packet to the server. The server may perform one or more authentication processes to confirm that the data packet is from a specific electronic device. In some cases, the server may store a public key associated with a private key, and using asymmetric cryptographic techniques, the data packet may be authenticated based on the private key and the public key pair.

[0019] The authentication techniques described herein may not rely on direct input or information uploaded by the end user about the terminal device, which may facilitate deployment of multiple terminal devices by the end user. Alternatively, the end user may optionally choose to provide information to the manufacturer, and the FSD generator may use this information as well as publicly available information to generate the FSD.

[0020] First, in the reference Figure 1 Features of the present disclosure are described in the context of the memory systems and memory dies described herein. Figure 2 These and other features of the present disclosure are further illustrated by and described with reference to device diagrams and flow charts, which relate to the authentication process described in the referenced Figure 3-6 Describes the security descriptor that is generated.

[0021] Figure 1 An example of a system 100 utilizing one or more memory devices according to examples as disclosed herein is illustrated. The system 100 may include an external memory controller 105, a memory device 110, and a plurality of channels 115 coupling the external memory controller 105 and the memory device 110. The system 100 may include one or more memory devices, but for ease of description, the one or more memory devices may be described as a single memory device 110.

[0022] System 100 may include part of an electronic device such as a computing device, a mobile computing device, a wireless device, or a graphics processing device. System 100 may be an example of a portable electronic device. System 100 may be an example of a computer, a laptop, a tablet, a smart phone, a cellular phone, a wearable device, an Internet-connected device, etc. Memory device 110 may be a system component configured to store data for one or more other components of system 100.

[0023] At least a portion of the system 100 may be an example of a host device, which may be referred to as a terminal device. Such a host device may be an example of a device that uses memory to perform a process, such as a computing device, a mobile computing device, a wireless device, a graphics processing device, a computer, a notebook computer, a tablet computer, a smart phone, a cellular phone, a wearable device, an Internet-connected device, some other fixed or portable electronic device, etc. In some cases, a host device may refer to hardware, firmware, software, or a combination thereof that implements the functionality of the external memory controller 105. In some cases, the external memory controller 105 may be referred to as a host or a host device.

[0024] In some cases, memory device 110 may be a standalone device or component that is configured to communicate with other components of system 100 and provide physical memory addresses / spaces that may be used or referenced by system 100. In some instances, memory device 110 may be configurable to work with at least one or more different types of systems 100. Signaling between components of system 100 and memory device 110 may be operable to support modulation schemes used to modulate signals, different pin designs for communicating signals, different packaging of system 100 and memory device 110, clock signaling and synchronization between system 100 and memory device 110, timing conventions, and / or other factors.

[0025] The memory device 110 may be configured to store data for components of the system 100. In some cases, the memory device 110 may act as a slave device of the system 100 (e.g., responding to and executing commands provided by the system 100 through the external memory controller 105). Such commands may include access commands for access operations, such as write commands for write operations, read commands for read operations, refresh commands for refresh operations, or other commands. The memory device 110 may include two or more memory dies 160 (e.g., memory chips) that support a desired or specified capacity for data storage. A memory device 110 including two or more memory dies may be referred to as a multi-die memory or package (also referred to as a multi-chip memory or package). The memory device 110 may support different types of memory architectures, such as NAND, NOR, or both, among others.

[0026] System 100 may additionally include a processor 120, a basic input / output system (BIOS) component 125, one or more peripheral components 130, and an input / output (I / O) controller 135. The components of system 100 may electronically communicate with each other using a bus 140.

[0027] Processor 120 may be configured to control at least a portion of system 100. Processor 120 may be a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or it may be a combination of these types of components. In such cases, processor 120 may be an example of a central processing unit (CPU), a graphics processing unit (GPU), a general purpose graphics processing unit (GPGPU), or a system on a chip (SoC), among other examples.

[0028] BIOS component 125 may be a software component including BIOS operating as firmware that may initialize and run various hardware components of system 100. BIOS component 125 may also manage the flow of data between processor 120 and various components of system 100, such as peripheral components 130, I / O controller 135, etc. BIOS component 125 may include a program or software stored in read-only memory (ROM), flash memory, or any other non-volatile memory.

[0029] Peripheral component 130 may be any input device or output device, or an interface to such a device, that may be integrated into or with system 100. Examples may include a disk controller, a sound controller, a graphics controller, an Ethernet controller, a modem, a Universal Serial Bus (USB) controller, a serial or parallel port, or a peripheral card slot such as a Peripheral Component Interconnect (PCI) or a dedicated graphics port. Peripheral component 130 may be other components that are understood by those skilled in the art to be peripheral devices.

[0030] I / O controller 135 may manage data communications between processor 120 and peripheral components 130, input device 145, or output device 150. I / O controller 135 may manage peripheral devices that are not integrated into or with system 100. In some cases, I / O controller 135 may represent a physical connection or port to an external peripheral component.

[0031] Input 145 may represent a device or signal external to system 100 that provides information, signals, or data to system 100 or its components. This may include a user interface or an interface with or between other devices. In some cases, input 145 may be a peripheral device that interfaces with system 100 via one or more peripheral components 130, or may be managed by I / O controller 135.

[0032] Output 150 may represent a device or signal external to system 100 that is configured to receive output from system 100 or any of its components. Examples of output 150 may include a display, an audio speaker, a printing device, or another processor on a printed circuit board, etc. In some cases, output 150 may be a peripheral device that interfaces with system 100 via one or more peripheral components 130, or may be managed by I / O controller 135.

[0033] The components of system 100 may be composed of general or special purpose circuits designed to perform their functions. This may include various circuit elements, such as wires, transistors, capacitors, inductors, resistors, amplifiers, or other active or passive elements, configured to perform the functions described herein.

[0034] The memory device 110 may include a device memory controller 155 and one or more memory dies 160. Each memory die 160 may include a local memory controller 165 (e.g., local memory controller 165-a, local memory controller 165-b, and / or local memory controller 165-N) and a memory array 170 (e.g., memory array 170-a, memory array 170-b, and / or memory array 170-N). The memory array 170 may be a collection (e.g., a grid) of memory cells, where each memory cell is configured to store at least one bit of digital data.

[0035] The memory device 110 may be an example of a two-dimensional (2D) memory cell array or may be an example of a three-dimensional (3D) memory cell array. For example, a 2D memory device may include a single memory die 160. A 3D memory device may include two or more memory dies 160 (e.g., memory die 160-a, memory die 160-b, and / or any number of memory dies 160-N). In a 3D memory device, multiple memory dies 160-N may be stacked on each other and close to each other. In some cases, the memory die 160-N in a 3D memory device may be referred to as a stack, a level, a layer, or a die. A 3D memory device may include any number of stacked memory dies 160-N (e.g., two high stacked memory dies, three high stacked memory dies, four high stacked memory dies, five high stacked memory dies, six high stacked memory dies, seven high stacked memory dies, eight high stacked memory dies). This can increase the number of memory cells that can be positioned on a substrate compared to a single 2D memory device, which can reduce production costs or improve performance of the memory array, or both. In some 3D memory devices, different stacks can share at least one common access line such that some stacks can share at least one of a word line, a digit line, and / or a plate line.

[0036] The device memory controller 155 may include circuits or components configured to control the operation of the memory device 110. As such, the device memory controller 155 may include hardware, firmware, and software that enable the memory device 110 to execute commands, and may be configured to receive, transmit, or execute commands, data, or control information regarding the memory device 110. The device memory controller 155 may be configured to communicate with an external memory controller 105, one or more memory dies 160, or a processor 120. In some cases, the memory device 110 may receive data and / or commands from the external memory controller 105. For example, the memory device 110 may receive a write command indicating that the memory device 110 should store certain data on behalf of a component of the system 100 (e.g., the processor 120), or a read command indicating that the memory device 110 should provide certain data stored in the memory die 160 to a component of the system 100 (e.g., the processor 120). In some cases, the device memory controller 155 may control the operation of the memory device 110 described herein in conjunction with the local memory controller 165 of the memory die 160. Examples of components included in the device memory controller 155 and / or the local memory controller 165 may include a receiver for demodulating signals received from the external memory controller 105, a decoder for modulating and transmitting signals to the external memory controller 105, logic, decoders, amplifiers, filters, and the like.

[0037] A local memory controller 165 (e.g., local to the memory die 160) may be configured to control the operation of the memory die 160. Moreover, the local memory controller 165 may be configured to communicate (e.g., receive and transmit data and / or commands) with the device memory controller 155. The local memory controller 165 may support the device memory controller 155 to control the operation of the memory device 110 as described herein. In some cases, the memory device 110 does not include a device memory controller 155, and the local memory controller 165 or the external memory controller 105 may perform the various functions described herein. Thus, the local memory controller 165 may be configured to communicate with the device memory controller 155, with other local memory controllers 165, or directly with the external memory controller 105 or the processor 120.

[0038] The external memory controller 105 may be configured to enable communication of information, data, and / or commands between components of the system 100 (e.g., the processor 120) and the memory device 110. The external memory controller 105 may act as a liaison between the components of the system 100 and the memory device 110, so that the components of the system 100 may not need to know the operating details of the memory device. The components of the system 100 may present requests (e.g., read commands or write commands) to the external memory controller 105 that the external memory controller 105 satisfies. The external memory controller 105 may convert or translate communications exchanged between the components of the system 100 and the memory device 110. In some cases, the external memory controller 105 may include a system clock that generates a common (source) system clock signal. In some cases, the external memory controller 105 may include a common data clock that generates a common (source) data clock signal.

[0039] In some cases, the external memory controller 105 or other components of the system 100, or their functionality described herein, may be implemented by the processor 120. For example, the external memory controller 105 may be hardware, firmware, or software, or some combination thereof, implemented by the processor 120 or other components of the system 100. Although the external memory controller 105 is depicted as being external to the memory device 110, in some cases, the external memory controller 105 or their functionality described herein may be implemented by the memory device 110. For example, the external memory controller 105 may be hardware, firmware, or software, or some combination thereof, implemented by the device memory controller 155 or one or more local memory controllers 165. In some cases, the external memory controller 105 may be distributed across the processor 120 and the memory device 110, such that portions of the external memory controller 105 are implemented by the processor 120 and other portions are implemented by the device memory controller 155 or the local memory controller 165. Likewise, in some cases, one or more functions attributed herein to device memory controller 155 or local memory controller 165 may in some cases be performed by external memory controller 105 (separate from or included in processor 120 ).

[0040] Components of system 100 may exchange information with memory device 110 using multiple channels 115. In some examples, channels 115 may enable communication between external memory controller 105 and memory device 110. Each channel 115 may include one or more signal paths or transmission media (e.g., conductors) between terminals associated with components of system 100. For example, channel 115 may include a first terminal including one or more pins or pads at external memory controller 105 and one or more pins or pads at memory device 110. A pin may be an example of a conductive input or output point of a device of system 100, and a pin may be configured to act as part of a channel. In some cases, a pin or pad of a terminal may be part of a signal path of channel 115. Additional signal paths may be coupled to the terminals of the channel to route signals within the components of system 100. For example, the memory device 110 may include signal paths (e.g., signal paths internal to the memory device 110 or its components, such as signal paths internal to the memory die 160) that route signals from terminals of the channel 115 to various components of the memory device 110 (e.g., device memory controller 155, memory die 160, local memory controller 165, memory array 170).

[0041] Channel 115 (and associated signal paths and terminals) may be dedicated to conveying a specific type of information. In some cases, channel 115 may be an aggregated channel and, therefore, may include multiple individual channels. For example, data channel 190 may be x4 (e.g., including four signal paths), x8 (e.g., including eight signal paths), x16 (e.g., including sixteen signal paths), and the like. Signals transmitted via the channel may use a double data rate (DDR) timing scheme. For example, some symbols of the signal may be registered on the rising edge of the clock signal, and other symbols of the signal may be registered on the falling edge of the clock signal. Signals transmitted via the channel may use single data rate (SDR) signaling. For example, for each clock cycle, one symbol of the signal may be registered.

[0042] In some cases, channels 115 may include one or more command and address (CA) channels 186. CA channels 186 may be configured to transmit commands between external memory controller 105 and memory device 110, including control information associated with the commands (e.g., address information). For example, CA channels 186 may include a read command regarding the address of the desired data. In some cases, CA channels 186 may register on a rising clock signal edge and / or a falling clock signal edge. In some cases, CA channels 186 may include any number of signal paths to decode address and command data (e.g., eight or nine signal paths).

[0043] In some cases, channel 115 may include one or more clock signal (CK) channels 188. CK channels 188 may be configured to communicate one or more common clock signals between external memory controller 105 and memory device 110. Each clock signal may be configured to oscillate between a high state and a low state and coordinate the actions of external memory controller 105 and memory device 110. In some cases, the clock signal may be a differential output (e.g., a CK_t signal and a CK_c signal), and the signal path of CK channel 188 may be configured accordingly. In some cases, the clock signal may be single-ended. CK channel 188 may include any number of signal paths. In some cases, clock signal CK (e.g., CK_t signal and CK_c signal) may provide a timing reference for command and addressing operations of memory device 110 or for other full system operations of memory device 110. Clock signal CK may therefore be variously referred to as control clock signal CK, command clock signal CK, or system clock signal CK. The system clock signal CK may be generated by a system clock, which may include one or more hardware components (eg, oscillators, crystals, logic gates, transistors, etc.).

[0044] In some cases, channels 115 may include one or more data (DQ) channels 190. Data channels 190 may be configured to communicate data and / or control information between external memory controller 105 and memory device 110. For example, data channels 190 may communicate information to be written to memory device 110 (e.g., bidirectionally) or information to be read from memory device 110.

[0045] In some cases, channel 115 may include one or more other channels 192 that may be dedicated to other purposes. These other channels 192 may include any number of signal paths.

[0046] Channel 115 may use a variety of different architectures to couple external memory controller 105 with memory device 110. Examples of various architectures may include a bus, a point-to-point connection, a crossbar switch, a high-density interposer such as a silicon interposer, or a channel formed in an organic substrate, or some combination thereof. For example, in some cases, the signal path may at least partially include a high-density interposer such as a silicon interposer or a glass interposer.

[0047] A variety of different modulation schemes may be used to modulate the signals transmitted over the channel 115. In some cases, a binary symbol (or binary level) modulation scheme may be used to modulate the signals communicated between the external memory controller 105 and the memory device 110. The binary symbol modulation scheme may be an example of an M-ary modulation scheme, where M is equal to two. Each symbol of the binary symbol modulation scheme may be configured to represent one bit of digital data (e.g., a symbol may represent a logical 1 or a logical 0). Examples of binary symbol modulation schemes include, but are not limited to, non-return to zero (NRZ), unipolar encoding, bipolar encoding, Manchester encoding, pulse amplitude modulation (PAM) with two symbols (e.g., PAM2), and the like.

[0048] The system 100 may include or support an injection system 180. The injection system 180 may inject a unique identifier or code, which may be referred to as a device-specific secret (e.g., a unique device secret (UDS), such as a primary UDS or a secondary UDS), into the memory device 110 (e.g., by writing to the memory array 170, which may contain non-volatile memory). The injection system 180 may inject the device-specific secret during fabrication or manufacturing of the memory device 110 or a component of the memory device 110.

[0049] At least some portions of system 100 may be included in a multimedia controller (MMC), which may include an embedded controller and an embedded memory array. Alternatively, the MMC may be a separate structure and coupled to memory device 110 via one or more conductive paths or integrated within the MMC. In some cases, the MMC may receive commands from device memory controller 155 or one or more local memory controllers 165, or may be independent and interface with one or more components (e.g., external memory controller 105, processor 120, I / O controller 135, etc.) using channel 115.

[0050] The system 100 may include or support an FSD manager 182. The FSD manager 182 may be accessed by one or more components of the system 100 (e.g., the memory device 110) and may obtain security descriptors, such as the FSD, for authenticating the memory device 110 or other components of the system 100. The FSD manager 182 may obtain the FSD based on publicly available information, and the FSD stamp may be written to the memory device 110 upon initial boot-up of the memory device 110. The FSD may be used by the system 100 to generate a device alias key (e.g., a private key of a public-private key pairing) for encryption, and the device alias key may be based on the FSD and a device-specific secret.

[0051] Additionally or alternatively, at least some portions of system 100 may be part of or integrated into an IoT device. An IoT device may be deployed and operated by an end user and may be referred to as an end device. Some end users may employ multiple end devices, each of which may be authenticated using a credential accessible by a server and a device alias key (e.g., a private key) generated by the FSD and a device-specific secret, the credential may indicate a public key for authentication.

[0052] In some examples, the system 100 may support security techniques such as a device identifier composition engine (DICE) or a robust IoT (RIoT). Such security techniques may be cryptographic security techniques and may restrict access to device-specific secrets by prohibiting read access to the device-specific secrets and using a cryptographic key derivation function (e.g., a hash function) that depends on the device-specific secrets.

[0053] Figure 2 An example of an authentication process 200 according to an example disclosed herein is described. The authentication process 200 may be implemented with reference to Figure 1 The authentication process 200 may authenticate a terminal device, which may be a reference Figure 1 An example of one or more portions of the described system 100. The terminal device undergoing the authentication process 200 may include a memory device, which may include a reference Figure 1Examples of memory device 110 are depicted as memory die 160 or memory array 170 .

[0054] The terminal device may be an electronic device, such as a smart phone, a tablet computer, a computer, a camera, or other device that sends data packets to other electronic devices and receives data packets from other electronic devices. The terminal device may be an IoT device for automotive technology, such as a sensor in a wireless communication system on a vehicle. The terminal device may be used for industrial purposes in IoT devices, such as smart meters in commercial or residential environments. The terminal device may support various memory architectures, such as NAND, NOR, etc. The terminal device may include an embedded MMC (eMMC) for securely managing data authentication functions. For example, the eMMC may be configured to store one or more cryptographic keys in a protected memory partition. In this regard, the terminal device may be able to access the cryptographic keys, and the eMMC prevents the keys from being removed, replaced, or otherwise modified. Therefore, the embedded structure of the eMMC may provide security features for data transactions occurring between the terminal device and other electronic devices (such as servers that can be accessed by the terminal device). In some cases, the terminal device may adopt DICE or RIoT security technology, and the memory device of the terminal device may be part of a SoC device or may implement a SoC device.

[0055] At 205, a memory device (or a component of an end device or the end device itself) may be injected with device-specific secrets. This may be done by injecting a system (e.g., Figure 1 The device-specific secret may be injected by the injection system 180 of the memory device, and the injection of the device-specific secret may occur during the fabrication or manufacture of the memory device. The device-specific secret may be a UDS associated with and unique to the memory device, such as a primary UDS or a secondary UDS. The device-specific secret may be written to the memory device (e.g., at a memory array, such as Figure 1 The memory array 170 of the memory device, which may contain non-volatile memory), and in some cases, may be written to a read-only portion of the memory device. For example, a device-specific secret may be written to a portion of the memory device, and after writing, the memory device may prohibit write access to the portion of the memory device (e.g., using a latching mechanism). In some cases, read access to the portion of the memory device storing the device-specific secret may also be prohibited in order to maintain the confidentiality (e.g., hiding) of the device-specific secret. Once read access is prohibited, a power cycle or system may be performed to restore access to the portion of the memory device storing the device-specific secret. Using the device-specific secret, the memory device may generate an indicator (sometimes referred to as a CDI), which may be a keyed hash function of the device-specific secret and a hash of the source code of the memory device at boot time.

[0056] Additionally, when the device-specific secret is injected at 205, the same device-specific secret is also uploaded to the private server 211 at 210. The uploading of the device-specific secret at 210 may include uploading the device ID 214, which may be a device ID unique to the memory device. The private server 211 may then store the secret copy 213 and the device ID 214. For example, the private server 211 may store the secret copy 213 and the device ID 214 in a database 212.

[0057] At 215, a credential is generated for authenticating the memory device. The credential may be generated from a security descriptor generated by the FSD generator 220. The generation of the FSD by the FSD generator 220 may depend on one or more of the private key 217 and the user input 230. For example, the device ID 214 may be associated with a private key 217 generated by the FSD generator 220 (e.g., Figure 1The FSD generator 220 may be included in the secret upload 210 along with a security descriptor (e.g., FSD) generated by the FSD manager 182 of the private server 211, which may be part of or implemented within a key management service (KMS), which may be used to generate credentials at 215. In some examples, the FSD generator at 220 may emulate an FSD generator 227, making the FSD generator 227 available at a public server 225. This public server 225 may use a private key 226, which is the same as the private key 217 stored at the private server 211, but may provide verification of geospatial coordinates, time reference, or other publicly available information of the memory device performing the initial connection 235. The private keys at 217 and 226 may be used by the FSD generators 220 and 227 and the data contained in the FSD. The publicly available set of information to be included by the public server 225 and the FSD generator 227 may be listed in the FSD request message 236 from the memory device performing its initial connection 235. In some examples, the publicly available set of information included in the FSD request message 236 may be generated based on input from an end user or another user, such as user input 230. The publicly available information may include an evaluation of the time and date corresponding to when the FSD was generated within a time window defined by the user input 230. For example, if the FSD request 236 includes a time window ending on January 1, 2020, and the public server 225 receives the FSD request message 236 after that date, the public server 225 may send an FSD response 236 indicating an error due to the FSD request message 236 being received after the specified time window. The publicly available information may also include information associated with the terminal device (device type, device name, device brand, device batch or model number, etc.) or information associated with the user or owner of the terminal device (user or owner name, company name, company or customer information, customer details, location of the owner or user, a string associated with the terminal device, etc.). In some cases, the publicly available information may include a default set of information for use by FSD generators 220 and 227 (eg, a default set of parameters for FSD generation).

[0058] Information related to the terminal device or terminal user may be input by the user at 230, which may be optionally input by the user. For example, the user may select a parameter set (e.g., a default set, a set related to the timing and location of FSD generation, random parameters) by which the FSD is generated by the FSD generator 220. The user may enter a character set, a code, or other information that may be used to generate the FSD by the FSD generators 220 and 227. For example, the user may provide a string representing the name of a reseller or the entity of the terminal device. Other information may also be used to generate a credential at 215 and once generated, the credential may be used for authentication at 260 (e.g., the credential may be sent to a server associated with the terminal device or the user of the terminal device for authentication).

[0059] At 235, upon initial connection of the memory device (or a terminal device on which the memory device is implemented), the memory device may access the FSD manager (e.g., Figure 1 240 ) to initiate an FSD request and response message 236. The FSD request and response message 236 may be used to obtain an FSD for a memory device. For example, a memory device may connect to a public server 225 and request an FSD from an FSD generator 227. The FSD generator 227 may collect data (e.g., based on user input 230, default parameters) and sign the data with its private key 226, thereby generating an FSD stamp or other information representing the FSD. The FSD stamp may then be written to the memory device at 240. In some cases, the FSD stamp may be written to multiple memory devices, each of which may be associated with a respective terminal device. Each of the multiple memory devices may have a respective device-specific secret, but may use the same FSD stamp representing the same FSD used for key generation at 245.

[0060] At a continuous connection event (e.g., an attempt to initialize a device connection 244, such as an attempt to connect to a remote server), the memory device may generate a key for authenticating the terminal device at 245 using the FSD stamp written at 240. For example, the memory device may employ a DICE or RIoT key generation technique (e.g., a program executed by the memory device) that generates a device key at 245 using the FSD stamp written at 240. In some cases, the device key generated at 245 may be a device alias key and may include a public and private alias key pair generated using an asymmetric key generation technique. The device key generated at 245 may be based on an indicator (e.g., CDI) generated by the memory device and the FSD indicated by the FSD stamp written at 240.

[0061] At 255, the memory device may be deployed and a connection may be established with a deployment server 258 implemented within or supported by a terminal device operated by an end user (e.g., a customer or client of the memory device). Once in deployment, the terminal device may undergo an authentication procedure at 260 to access a server associated with the end user or terminal device. For example, the terminal device may be authenticated by providing a key generated at 245 to the deployment server 258, which performs authentication of the terminal device at 260. In some cases, the server may store a credential 259 generated at 215 (e.g., the deployment server 258 may obtain the credential 216 from the private server 211) or may otherwise obtain the credential 259, and may use the credential 259 to authenticate the terminal device at 260.

[0062] According to some aspects, the FSD generation techniques herein can allow for simplified credential and key generation for authenticating multiple memory devices. Rather than being based on device-specific information, the FSD can be generated based on publicly available information and optionally provided user input, and can be used to authenticate multiple terminal devices.

[0063] Figure 3 A block diagram 300 is shown of an FSD-based security system 305 that can generate and utilize security descriptors according to examples as disclosed herein. The FSD-based security system 305 can include a security descriptor as described in reference Figure 2 Aspects of the FSD generator described. The FSD-based security system 305 may include a private key 306, a request receiver 310, a generation component 315, a credential generator 320, an ID component 325, a secret manager 330, a transmission manager 335, a cryptographic component 340, and an information identifier 345. Each of these modules may communicate with each other directly or indirectly (e.g., via one or more buses).

[0064] The request receiver 310 may receive a credential request associated with authenticating a terminal device. In some cases, the terminal device is a memory device configured to store data for a host device. In some cases, the terminal device is an IoT device. In some cases, the request is received from the terminal device. In some cases, the request is received from a server for authenticating the terminal device.

[0065] The generation component 315 can generate the FSD based on identifying publicly available information and signing the publicly available information using the private key 306. In some cases, the FSD is independently generated on a server used to generate credentials for authenticating an end device.

[0066] Credential generator 320 may generate credentials based on the FSD and a device-specific secret associated with the terminal device.

[0067] The ID component 325 can determine the ID of the terminal device based on the received request. Figure 2 The same ID as the device ID 214 described in.

[0068] The secret manager 330 may identify a device-specific secret based on an identification of the terminal device, wherein generating the credential is based on identifying the device-specific secret. In some examples, the secret manager 330 may receive the device-specific secret from an injection system configured to inject the device-specific secret into the terminal device. In some examples, the secret manager 330 may identify the device-specific secret based on receiving the device-specific secret.

[0069] The transmission manager 335 may transmit credentials for authenticating the terminal device to a server associated with the authenticating terminal device. In some examples, the transmission manager 335 may transmit the FSD to the terminal device based on transmitting the credentials to the server. In some examples, the transmission manager 335 may transmit the FSD to the terminal device based on publicly available information matching the boundaries set in the request from the terminal device.

[0070] The cryptographic component 340 may generate a cryptographic key pair including a public key and a private key based on the FSD and a device-specific secret associated with the terminal device, wherein the credential includes a public key of the cryptographic key pair.

[0071] The information identifier 345 may identify publicly available information based on receiving the request. In some examples, the information identifier 345 may confirm one or more types of publicly available information to be included in the FSD based on the information in the request, wherein identifying the publicly available information is based on identifying the one or more types of publicly available information. In some examples, the information identifier 345 may identify a default set of publicly available information to be included in the FSD based on the information in the request, wherein identifying the publicly available information is based on identifying the default set of publicly available information. In some cases, the publicly available information includes a geographic region associated with the terminal device, a timestamp associated with activating the terminal device, information about a user of the terminal device, information about an owner of the terminal device, a string associated with an entity of the terminal device, a default parameter set, or any combination thereof.

[0072] Figure 4 A block diagram 400 is shown of a terminal device 405 supporting security descriptor generation according to an example as disclosed herein. The terminal device 405 may be a terminal device as described in reference Figure 1 and 2An example of aspects of the described terminal device. The terminal device 405 may include an FSD manager 410, a secret identifier 415, a password manager 420, an authentication component 425, an event detector 430, and a request transmitter 435. Each of these modules may communicate with each other directly or indirectly (e.g., via one or more buses).

[0073] FSD manager 410 (e.g., Figure 1 The FSD manager 182 of the terminal device receives the FSD through the terminal device. In some examples, the FSD manager 410 can identify publicly available information, wherein the FSD contains publicly available information.

[0074] The secret identifier 415 may identify a device-specific secret stored in a memory of the terminal device based on receiving publicly available information. In some examples, the secret identifier 415 may be received by the terminal device from an infusion system during a manufacturing process of the terminal device, wherein identifying the device-specific secret is based on receiving the device-specific secret.

[0075] Password manager 420 may generate a cryptographic key pair including a public key and a private key based on receiving the publicly available information and identifying the device-specific secret.

[0076] The authentication component 425 can authenticate the terminal device based on the cryptographic key pair.

[0077] The event detector 430 may identify a startup event of the terminal device, wherein generating the cryptographic key pair is based on identifying the startup event.

[0078] The request transmitter 435 may transmit a request for the FSD through the terminal device, wherein receiving the FSD is based on the transmitted request.

[0079] Figure 5 A flowchart illustrating one or more methods 500 including security descriptor generation according to examples as disclosed herein is shown. The operations of the method 500 may be implemented by a FSD-based security system or components thereof as described herein. For example, the operations of the method 500 may be implemented by reference to Figure 3 The described FSD-based security system performs. In some examples, the FSD-based security system may execute instruction sets to control functional elements of the FSD-based security system to perform the described functions. Additionally or alternatively, the FSD-based security system may use dedicated hardware to perform aspects of the described functions.

[0080] At 505, the FSD generator may receive a request to generate a credential associated with an authentication terminal device. The operations of 505 may be performed according to the methods described herein. In some examples, the credential may be generated by reference to Figure 3Aspects of the operations of requesting the receiver to perform 505 are described.

[0081] At 510, the FSD generator may identify publicly available information based on the received request. The operations of 510 may be performed according to the methods described herein. In some examples, the information may be obtained by reference to Figure 3 The described information identifier performs aspects of the operations of 510 .

[0082] At 515, the FSD generator may generate the FSD based on identifying publicly available information. The operations of 515 may be performed according to the methods described herein. In some examples, the FSD may be generated by reference to Figure 3 Aspects of the operations of the generation component execution 515 are described.

[0083] At 520, the FSD generator may generate a credential based on the FSD and a device-specific secret associated with the terminal device. The operations of 520 may be performed according to the methods described herein. In some examples, the credential may be generated by reference to Figure 3 Aspects of the operations of the credential generator execution 520 are described.

[0084] At 525, the FSD generator may transmit the credentials for authenticating the terminal device to a server associated with the authenticating terminal device. The operations of 525 may be performed according to the methods described herein. In some examples, the credentials may be transmitted by reference to Figure 3 Aspects of the operations of the transmit manager 525 are described.

[0085] In some examples, an apparatus as described herein may perform one or more methods, such as method 500. The apparatus may include features, means, or instructions (e.g., a non-transitory computer-readable medium storing instructions executable by a processor) for: receiving a request for credentials associated with authenticating a terminal device; identifying publicly available information based on receiving the request; generating an FSD based on identifying the publicly available information; generating the credentials based on the FSD and a device-specific secret associated with the terminal device; and transmitting the credentials for authenticating the terminal device to a server associated with authenticating the terminal device.

[0086] Some examples of the method 500 and apparatus described herein may further include operations, features, components, or instructions for performing the following operations: determining an identifier of the terminal device based on receiving the request, and identifying a device-specific secret based on the identity of the terminal device, wherein generating the credential may be based on identifying the device-specific secret.

[0087] Some instances of the method 500 and apparatus described herein may further include operations, features, components, or instructions for identifying one or more types of publicly available information to be included in the FSD based on information in the request, wherein identifying the publicly available information may be based on identifying the one or more types of publicly available information.

[0088] Some instances of the method 500 and apparatus described herein may further include operations, features, components, or instructions for identifying a default set of publicly available information to be included in the FSD based on information in the request, wherein identifying the publicly available information may be based on identifying the default set of publicly available information.

[0089] Some examples of the method 500 and apparatus described herein may additionally include operations, features, means, or instructions for transmitting the FSD to the terminal device based on transmitting the credentials to the server.

[0090] Some examples of the method 500 and apparatus described herein may additionally include operations, features, means, or instructions for transmitting the identified publicly available information to the terminal device based on transmitting the credentials to the server.

[0091] Some examples of the method 500 and apparatus described herein may further include operations, features, components, or instructions for generating a cryptographic key pair comprising a public key and a private key based on the FSD and a device-specific secret associated with the terminal device, wherein the credential comprises a public key of the cryptographic key pair.

[0092] Some instances of the method 500 and apparatus described herein may further include operations, features, components, or instructions for receiving a device-specific secret from an injection system configured to inject the device-specific secret into a terminal device, wherein identifying the device-specific secret may be based on receiving the device-specific secret.

[0093] In some instances of the method 500 and apparatus described herein, the publicly available information includes an assessment that the device was located in a defined geographic area when it first connected to a public server that generated the FSD, an assessment that the device first connected to the public server within a predefined time window, information about a user of the terminal device, information about an owner of the terminal device, a string associated with an entity of the terminal device, a default parameter set, or any combination thereof.

[0094] In some examples of the methods 500 and apparatus described herein, the terminal device may be a memory device configured to store data for a host device. In some examples of the methods 500 and apparatus described herein, the terminal device may be an IoT device. In some examples of the methods 500 and apparatus described herein, the request may be received from the terminal device. In some examples of the methods 500 and apparatus described herein, the request may be received from a server for authenticating the terminal device.

[0095] Figure 6 A flowchart illustrating one or more methods 600 for supporting cryptographic key generation according to examples as disclosed herein is shown. The operations of the method 600 may be implemented by a terminal device or components thereof as described herein. For example, the operations of the method 600 may be implemented by a terminal device or components thereof as described herein. Figure 4 The described terminal device performs. In some examples, the terminal device may execute an instruction set to control functional elements of the terminal device to perform the described functions. Additionally or alternatively, the terminal device may use dedicated hardware to perform aspects of the described functions.

[0096] At 605, the terminal device may receive the FSD from the public server. The operation of 605 may be performed according to the method described herein. In some examples, the FSD may be received by the terminal device as described in reference to Figure 1 and 4 Aspects of the operations of the FSD manager execution 605 are described.

[0097] At 610, the terminal device may identify a device-specific ID derived from a secret stored in a memory of the terminal device based on receiving the FSD. The operations of 610 may be performed according to the methods described herein. In some examples, the ID may be obtained by referring to Figure 4 Aspects of the operations of secret identifier execution 610 are described.

[0098] At 615, the terminal device may generate a cryptographic key pair including a public key and a private key based on receiving the FSD and identifying a device-specific ID derived from a device-specific secret. The operations of 615 may be performed according to the methods described herein. In some examples, the cryptographic key pair may be generated by a method such as that described in reference Figure 4 Aspects of the operation of the password manager execution 615 are described.

[0099] At 620, the terminal device may authenticate the terminal device based on the cryptographic key pair. The operations of 620 may be performed according to the methods described herein. In some examples, the terminal device may be authenticated by a method such as that described in reference Figure 4 The authentication component described performs aspects of the operations of 620 .

[0100] In some examples, an apparatus as described herein may perform one or more methods such as method 600. The apparatus may include features, means, or instructions (e.g., a non-transitory computer-readable medium storing instructions executable by a processor) for: receiving an FSD by a terminal device; based on receiving the FSD, obtaining an ID derived from a device-specific secret stored in a memory of the terminal device; based on receiving the FSD and obtaining the ID derived from the device-specific secret, generating a cryptographic key pair including a public key and a private key; and authenticating the terminal device based on the cryptographic key pair.

[0101] Some examples of the method 600 and apparatus described herein may additionally include operations, features, components, or instructions for performing the following operations: identifying a startup event of an end device, wherein generating a cryptographic key pair may be based on identifying the startup event. For security purposes, an ID based on a device-specific secret may not be available to software running at runtime, and therefore, only boot-time software may be able to generate a cryptographic key pair.

[0102] Some examples of the method 600 and apparatus described herein may additionally include operations, features, means, or instructions for transmitting, by a terminal device, a request for an FSD for generating a cryptographic key pair, wherein receiving the FSD generated with publicly available information may be based on transmitting the request.

[0103] Some instances of the method 600 and apparatus described herein may further include operations, features, components, or instructions for performing the following operations: receiving, by a terminal device, a device-specific secret from an injection system during a manufacturing process of the terminal device, wherein identifying the device-specific secret may be based on receiving the device-specific secret.

[0104] Figure 7 A flowchart illustrating one or more methods 700 for supporting cryptographic key generation according to examples as disclosed herein is shown. The operations of the method 700 may be implemented by a terminal device or components thereof as described herein. For example, the operations of the method 700 may be implemented by a terminal device or components thereof as described herein. Figure 4 The described terminal device performs. In some examples, the terminal device may execute an instruction set to control functional elements of the terminal device to perform the described functions. Additionally or alternatively, the terminal device may use dedicated hardware to perform aspects of the described functions.

[0105] At 705, the terminal device may receive an FSD generated using publicly available information. The operations of 705 may be performed according to the methods described herein. In some examples, the FSD may be generated by a terminal device such as the one described in the reference Figure 1 and 4 Aspects of the operations of FSD manager execution 705 are described.

[0106] At 710, the terminal device may obtain an identifier derived from a device-specific secret stored in a memory of the terminal device. The operations of 710 may be performed according to the methods described herein. In some examples, the identifier may be derived from a device-specific secret stored in a memory of the terminal device. Figure 4 Aspects of the operations of secret identifier performance 710 are described.

[0107] At 715, the terminal device may generate a cryptographic key pair including a public key and a private key based at least in part on receiving a firmware security descriptor containing publicly available information and obtaining an identifier derived from a device-specific secret. The operations of 715 may be performed according to the methods described herein. In some examples, the cryptographic key pair may be generated by a method such as that described in reference to Figure 4 Aspects of the operation of the password manager execution 715 are described.

[0108] At 720, the terminal device may authenticate the terminal device based on the cryptographic key pair. The operations of 720 may be performed according to the methods described herein. In some examples, the terminal device may be authenticated by a method such as that described in reference Figure 4 The authentication component described performs aspects of the operations of 720 .

[0109] It should be noted that the methods described above describe possible embodiments, and that the operations and steps may be rearranged or otherwise modified, and other embodiments are possible. Furthermore, parts of two or more of the methods may be combined.

[0110] The information and signals described herein may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof. Some diagrams may show a signal as a single signal; however, one of ordinary skill in the art will understand that the signal may represent a signal bus, where the bus may have a variety of bit widths.

[0111] As used herein, the term "virtual ground" refers to a circuit node that is maintained at a voltage of approximately zero volts (0V) without being directly coupled to ground. Therefore, the voltage of the virtual ground may temporarily fluctuate and return to approximately 0V in a stable state. Virtual ground can be implemented using various electronic circuit elements such as a voltage divider consisting of an operational amplifier and a resistor. Other embodiments are also possible. "Virtual ground" or "virtual ground" refers to connecting to approximately 0V.

[0112] The terms "electronic communication", "conductive contact", "connection" and "coupling" may refer to a relationship between components that supports the flow of electrons between the components. Components are considered to be in electronic communication (conductive contact or connection or coupling) with each other if there is any conductive path between the components that can support the flow of signals between the components at any time. At any given time, based on the operation of the device containing the connected components, the conductive path between the components that are electronically connected to each other (or in conductive contact with each other, or connected to each other, or coupled to each other) may be an open circuit or a closed circuit. The conductive path between the connected components may be a direct conductive path between the components, or the conductive path between the connected components may be an indirect conductive path, which may include an intermediate component such as a switch, transistor or other component. In some cases, the signal flow between the connected components may be interrupted for a period of time, for example, using one or more intermediate components such as a switch or transistor.

[0113] The term "coupled" refers to the condition of moving from an open circuit relationship between components, in which signals are currently unable to communicate between components through conductive paths, to a closed circuit relationship between components, in which signals are able to communicate between components through conductive paths. When a component, such as a controller, couples other components together, the component initiates a change that allows signals to flow between other components via conductive paths that previously did not permit signal flow.

[0114] The term "isolation" refers to a relationship between components where a signal cannot currently flow between the components. Components are isolated from one another if an open circuit exists between them. For example, components separated by a switch positioned between two components are isolated from one another when the switch is open. When a controller isolates two components, the controller implements a change that blocks a signal from flowing between the components using a conductive path that previously permitted the signal to flow.

[0115] The devices discussed herein, including memory arrays, may be formed on semiconductor substrates such as silicon, germanium, silicon-germanium alloys, gallium arsenide, gallium nitride, etc. In some cases, the substrate is a semiconductor wafer. In other cases, the substrate may be a silicon-on-insulator (SOI) substrate, such as silicon-on-glass (SOG) or silicon-on-sapphire (SOP), or an epitaxial layer of semiconductor material on another substrate. The conductivity of the substrate or a sub-region of the substrate may be controlled by doping using various chemical species including, but not limited to, phosphorus, boron, or arsenic. Doping may be performed during the initial formation or growth of the substrate, by ion implantation, or by any other doping method.

[0116] The switch component or transistor discussed herein may represent a field effect transistor (FET) and include a three-terminal device including a source, a drain, and a gate. The terminals may be connected to other electronic components by a conductive material such as a metal. The source and drain may be conductive and may include a heavily doped (e.g., degenerate) semiconductor region. The source and drain may be separated by a lightly doped semiconductor region or channel. If the channel is n-type (e.g., most of the carriers are signals), then the FET may be referred to as an n-type FET. If the channel is p-type (i.e., most of the carriers are holes), then the FET may be referred to as a p-type FET. The channel may be terminated by an insulating gate oxide. Channel conductivity may be controlled by applying a voltage to the gate. For example, applying a positive voltage or a negative voltage to an n-type FET or a p-type FET, respectively, may cause the channel to become conductive. When a voltage greater than or equal to the threshold voltage of the transistor is applied to the transistor gate, the transistor may be "turned on" or "started up". When a voltage less than the threshold voltage of the transistor is applied to the transistor gate, the transistor may be "turned off" or "unstarted".

[0117] The description set forth herein in conjunction with the accompanying drawings describes example configurations and does not represent all examples that may be implemented or within the scope of the claims. The term "exemplary" as used herein means "serving as an example, instance, or illustration" and is not "preferred to" or "superior to" other examples. The specific implementation includes specific details that provide an understanding of the described techniques. However, these techniques may be practiced without these specific details. In some examples, well-known structures and devices are shown in block diagram form to avoid obscuring the concepts of the described embodiments.

[0118] In the drawings, similar components or features may have the same reference label. In addition, various components of the same type may be distinguished by following the reference label with a dashed line and a second label that distinguishes among similar components. If only the first reference label is used in the specification, the description applies to any of the similar components having the same first reference label regardless of the second reference label.

[0119] The various illustrative blocks and modules described in conjunction with the disclosure herein may be implemented or performed using a general purpose processor, a DSP, an ASIC, an FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration).

[0120] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored on a computer-readable medium as one or more instructions or codes or transmitted via a computer-readable medium. Other examples and embodiments are within the scope of the present disclosure and the appended claims. For example, due to the nature of the software, the functions described above may be implemented using software, hardware, firmware, hard wiring, or any combination of these executed by a processor. The features of the implementation functions may also be physically located at various locations, including being distributed so that the various parts of the functions are implemented at different physical locations. In addition, as used herein (included in the claims), as used in a list of items (e.g., a list of items with a phrase such as "at least one of" or "one or more of"), "or" indicates a list containing endpoints, such that a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). In addition, as used herein, the phrase "based on" should not be understood as referring to a closed conditional set. For example, without departing from the scope of the present disclosure, the exemplary steps described as "based on condition A" may be based on both condition A and condition B. In other words, as used herein, the phrase "based on" should be equally interpreted as the phrase "based at least in part on."

[0121] Computer-readable media include both non-transitory computer storage media and communication media including any media that facilitates the transfer of computer programs from one place to another. Non-transitory storage media can be any available media that can be accessed by a general or special computer. By way of example and not limitation, non-transitory computer-readable media may include RAM, ROM, electrically erasable programmable read-only memory (EEPROM), compact disk (CD) ROM or other optical disk storage device, magnetic disk storage device or other magnetic storage device, or any other non-transitory media that can be used to carry or store the desired program code device in the form of an instruction or data structure and can be accessed by a general or special computer or a general or special processor. And, any connection is appropriately referred to as a computer-readable medium. For example, if a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL) or wireless technology such as infrared, radio and microwave is used to transmit software from a website, server or other remote source, then the coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL) or wireless technology such as infrared, radio and microwave are included in the definition of media. As used herein, disk and disc include CD, laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of computer-readable media.

[0122] The description herein is provided to enable one skilled in the art to make or use the present disclosure. Various modifications to the present disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the scope of the present disclosure. Therefore, the present disclosure is not limited to the examples and designs described herein, but is given the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for authenticating a terminal device, comprising: receiving a request for credentials associated with authenticating the terminal device; identifying publicly available information based at least in part on receiving the request; generating a firmware security descriptor based at least in part on identifying the publicly available information; generating the credential based at least in part on the firmware security descriptor and a device-specific secret associated with the terminal device; and The credentials for authenticating the terminal device are transmitted to a server associated with authenticating the terminal device.

2. The method according to claim 1, further comprising: One or more types of publicly available information to be included in the firmware security descriptor are confirmed based at least in part on the information in the request, wherein identifying the publicly available information is based at least in part on confirming the one or more types of publicly available information.

3. The method according to claim 1, further comprising: A default set of publicly available information to be included in the firmware security descriptor is identified based at least in part on information in the request, wherein identifying the publicly available information is based at least in part on identifying the default set of publicly available information.

4. The method of claim 1, further comprising: The firmware security descriptor is transmitted to the end device based at least in part on publicly available information matching boundaries set in the request from the end device.

5. The method of claim 1, further comprising: A cryptographic key pair including a public key and a private key is generated based at least in part on the firmware security descriptor and the device-specific secret associated with the terminal device, wherein the credential includes the public key of the cryptographic key pair.

6. The method of claim 1, further comprising: The device-specific secret is received from an injection system configured to inject the device-specific secret into the terminal device, wherein identifying the device-specific secret is based at least in part on receiving the device-specific secret.

7. The method of claim 1 , wherein the publicly available information comprises a geographic region associated with the terminal device, a timestamp associated with activating the terminal device, information about a user of the terminal device, information about an owner of the terminal device, a string associated with an entity of the terminal device, a default parameter set, or any combination thereof.

8. The method of claim 1, wherein the terminal device is a memory device configured to store data for a host device.

9. The method of claim 1, wherein the request is received from the terminal device. 10 . The method of claim 1 , wherein the firmware security descriptor is independently generated on a server for generating credentials for authenticating the terminal device.

11. The method of claim 1 , further comprising: determining an identifier of the terminal device based at least in part on receiving the request; and The device-specific secret is identified based at least in part on the identifier of the terminal device, wherein generating the credential is based at least in part on identifying the device-specific secret.

12. A method for authenticating a terminal device, comprising: receiving, by the terminal device, a firmware security descriptor generated using publicly available information; obtaining an identifier derived from a device-specific secret stored in a memory of the terminal device; generating a cryptographic key pair comprising a public key and a private key based at least in part on receiving the firmware security descriptor generated with publicly available information and obtaining the identifier derived from the device-specific secret; and The terminal device is authenticated based at least in part on the cryptographic key pair.

13. The method of claim 12, further comprising: The publicly available information is identified, wherein the firmware security descriptor contains the publicly available information.

14. The method of claim 12, further comprising: An activation event of the terminal device is identified, wherein generating the cryptographic key pair is based at least in part on identifying the activation event.

15. The method of claim 12, further comprising: A request is transmitted, by the terminal device, for the firmware security descriptor for generating the cryptographic key pair, wherein receiving the firmware security descriptor generated using publicly available information is based at least in part on transmitting the request.

16. The method of claim 12, further comprising: receiving, by the terminal device, the device-specific secret from an infusion system during a manufacturing process of the terminal device; and The device-specific secret is identified based at least in part on receiving the device-specific secret.

17. A device for authenticating a terminal device, comprising: a receiver configured to receive a request for credentials associated with authenticating the terminal device; A firmware security descriptor generator configured to: identifying publicly available information based at least in part on receiving the request; generating a firmware security descriptor based at least in part on identifying the publicly available information; generating the credential based at least in part on the firmware security descriptor and a device-specific secret associated with the terminal device; and generating a cryptographic key pair comprising a public key and a private key based at least in part on the firmware security descriptor and the device-specific secret associated with the terminal device, wherein the credential includes the public key of the cryptographic key pair; and A transmitter is configured to transmit the credential for authenticating the terminal device to a server associated with authenticating the terminal device.

18. The apparatus of claim 17, wherein the firmware security descriptor generator is further configured to: The device-specific secret is identified based at least in part on an identification of the terminal device, wherein generating the credential is based at least in part on identifying the device-specific secret.

19. The apparatus of claim 17, wherein the firmware security descriptor generator is further configured to: One or more types of publicly available information to be included in the firmware security descriptor are identified based at least in part on information in the request, wherein identifying the publicly available information is based at least in part on identifying the one or more types of publicly available information.

20. The apparatus of claim 17, wherein the firmware security descriptor generator is further configured to: A default set of publicly available information to be included in the firmware security descriptor is identified based at least in part on information in the request, wherein identifying the publicly available information is based at least in part on identifying the default set of publicly available information.

21. The apparatus of claim 17, wherein the transmitter is further configured to: Based at least in part on transmitting the credentials to the server, transmitting the firmware security descriptor to the terminal device.

22. The apparatus of claim 17, wherein the transmitter is further configured to: Based at least in part on transmitting the credentials to the server, the identified publicly available information is transmitted to the terminal device.

23. The device of claim 17, wherein the publicly available information comprises a geographic region associated with the terminal device, a timestamp associated with activating the terminal device, information about a user of the terminal device, information about an owner of the terminal device, a string associated with an entity of the terminal device, a default parameter set, or any combination thereof.

Citation Information

Patent Citations

  • Sticking authencated context based on appearance

    CN1456983A

  • System and method for policy based adaptive application capability management and device attestation

    US10341321B2