Virtual subscriber identity module and virtual smart card

Abstract

The present disclosure relates to virtual subscriber identity modules and virtual smart cards. A system, method, and apparatus for authenticating an endpoint having a secure memory device. For example, based on endpoint identity data representing a configuration of components of the endpoint, including device identities representing the memory device and other components, a card profile can be selected, configured, and / or stored into the secure memory device. The card profile can be used by the endpoint to emulate a physical smart card, and can be considered a virtual smart card, such as a virtual subscriber identity module (SIM) card for accessing cellular connectivity.

Description

[0001] Related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 105,820, filed October 26, 2020, entitled “Virtual Subscriber Identification Module and Virtual Smart Card,” and also claims the benefit of U.S. Provisional Patent Application No. 63 / 156,224, filed March 3, 2021, entitled “Online Security Services based on Security Features Implemented in Memory Devices,” the entire disclosure of which is hereby incorporated by reference.

[0003] This application relates to U.S. Patent Application No. 17 / 005,565, filed August 28, 2020, entitled "Secure Memory System Programming for Verification," which claims the benefit of the following applications filed on the same date: Provisional U.S. Patent Application No. 63 / 059,617, filed July 31, 2020; U.S. Patent Application No. 17 / 080,684, filed October 26, 2020, entitled "Endpoint Authentication based on Boot-Time Binding of Multiple Components"; and U.S. Patent Application No. 4, April 2019, entitled "Onboarding Software on Secure Devices to Generate Device Identities for Authentication with Remote Server." U.S. Patent Application No. 16 / 374,905, published on October 8, 2020, as U.S. Patent Application Publication No. 2020 / 0322134; and U.S. Patent Application No. 17 / 014,203, filed on September 8, 2020, entitled "Customer-Specific Activation of Functionality in a Semiconductor Device," the entire disclosure of which is hereby incorporated by reference. Technical Field

[0004] At least some of the embodiments disclosed herein generally relate to authentication, and more specifically, but not limited to, authentication of communication endpoints with secure storage devices in a network. Background Technology

[0005] The memory subsystem may include one or more memory devices for storing data. The memory devices may be, for example, non-volatile memory devices and volatile memory devices. Generally, a host system can utilize the memory subsystem to store data at the memory devices and retrieve data from the memory devices.

[0006] Standards for Device Identity Synthesis Engine (DICE) and Robust Internet of Things (RIoT) have been developed for data computation for computing device identity recognition and authentication based on cryptographic computation. Summary of the Invention

[0007] In one aspect, this disclosure relates to a memory device comprising: an integrated circuit memory cell formed on one or more integrated circuit dies, including a first memory region of the memory cell configured to store device identity data; a controller configured to generate device identity data representing the memory device based at least in part on a root secret of the memory device, and to control access to the first memory region based on an access control key; and an integrated circuit package configured to enclose the integrated circuit memory cell and the controller; wherein the integrated circuit memory cell is configured to store boot instructions executable by an endpoint, the endpoint having the memory device as one of a plurality of components of the endpoint; and wherein the controller is further configured to store a card profile in the integrated circuit memory cell to emulate the functionality of a smart card based on the card profile.

[0008] In another aspect, this disclosure relates to a method comprising: generating device identity data representing the memory device, at least in part based on a root secret of the memory device, via a controller enclosed in an integrated circuit package of the memory device; storing the device identity data in a first memory region of an integrated circuit memory cell formed on one or more integrated circuit dies enclosed within the integrated circuit package; controlling access to the first memory region via the controller based on an access control key; storing, in a second memory region of the integrated circuit memory cell, an activation instruction executable by an endpoint having the memory device as one of a plurality of components of the endpoint; and writing a card profile into the integrated circuit memory cell via the controller to emulate the functionality of a smart card based on the card profile.

[0009] In another aspect, this disclosure relates to an endpoint comprising: a plurality of components including a memory device and a processor connected to the memory device, wherein the memory device includes: an integrated circuit memory cell formed on one or more integrated circuit dies, including a first memory region of the memory cell configured to store device identity data; a controller configured to generate device identity data representing the memory device at least in part based on a root secret of the memory device, and to control access to the first memory region based on an access control key; and an integrated circuit package configured to enclose the integrated circuit memory cell and the controller; wherein the memory device is configured to store boot instructions executable by the processor in the integrated circuit memory cell; and wherein the endpoint is further configured to store a card profile in the integrated circuit memory cell to emulate the functionality of a smart card based on the card profile. Attached Figure Description

[0010] Embodiments are shown in the figures as examples and not as limitations, and similar reference numerals indicate similar elements in the figures.

[0011] Figure 1 Example computing systems according to some embodiments of the present disclosure are shown.

[0012] Figure 2 The generation of identity data in an integrated circuit memory device according to one embodiment is illustrated.

[0013] Figure 3 This illustrates a technique for controlling the execution of commands in a memory device according to one embodiment.

[0014] Figure 4 This illustrates a technique for verifying the integrity of data stored in a memory device, according to one embodiment.

[0015] Figure 5 This illustrates a security service provided to a client server based on security features implemented in a memory device, according to one embodiment.

[0016] Figure 6 A system and method for configuring and authenticating endpoints of card-based services, according to one embodiment, are shown.

[0017] Figure 7 A card profile of a virtual smart card according to one embodiment is shown.

[0018] Figure 8 A card profile of a Virtual Subscriber Identity Module (SIM) according to one embodiment is shown.

[0019] Figure 9 This illustrates a technique for authenticating memory devices according to one embodiment.

[0020] Figure 10 This illustrates a technique for generating commands to control the secure operation of a memory device, according to one embodiment.

[0021] Figure 11 A method for using a virtual smart card according to one embodiment is shown.

[0022] Figure 12 A method for providing security services based on security features of a memory device, according to one embodiment, is illustrated.

[0023] Figure 13 This illustrates a method for logging into an endpoint of a service subscribed to by an account, according to one embodiment.

[0024] Figure 14 This illustrates a technique for customizing an endpoint using an online firmware store, according to one embodiment.

[0025] Figure 15 This illustrates a technique for directing services to an endpoint via an online service store, according to one embodiment.

[0026] Figure 16 A firmware update method using a firmware store and a security server is shown according to one embodiment.

[0027] Figure 17 This illustrates an endpoint customization method using a service store and a security server according to one embodiment.

[0028] Figure 18 The illustration shows the generation of identity data according to one embodiment to facilitate the monitoring of integrity and / or endpoint activity.

[0029] Figure 19 This illustrates a technique for maintaining the integrity of packets stored in an endpoint, according to one embodiment.

[0030] Figure 20 A system is shown that implements security operations based on tracking endpoint activity, according to one embodiment.

[0031] Figure 21 A method for updating or repairing packets stored in an endpoint is shown according to one embodiment.

[0032] Figure 22 A method for performing security operations based on one or more endpoint-based activities is illustrated according to one embodiment.

[0033] Figure 23 and 24 A system configured to implement subscription sharing among a set of endpoints is shown according to one embodiment.

[0034] Figure 25 A method for facilitating subscription sharing among a set of endpoints is shown according to one embodiment.

[0035] Figure 26 This illustrates a technique for managing endpoint identification according to one embodiment.

[0036] Figure 27 A method for managing endpoint identification is shown according to one embodiment.

[0037] Figure 28 This is a block diagram of an example computer system in which embodiments of the present disclosure can be operated. Detailed Implementation

[0038] At least some aspects of this disclosure relate to a security server and a memory device with security features. The security server is configured to provide online security services in a computer network (e.g., the Internet) based on the security features of the memory device. The host system of the memory device can use the memory and / or storage functions of the memory device to store instructions and / or data for processing and to store processing results.

[0039] Generally, a memory subsystem may include storage devices and / or memory modules. A host system may use a memory subsystem comprising one or more components, such as memory devices for storing data. The host system can provide data to be stored in the memory subsystem and can request data to be retrieved from the memory subsystem.

[0040] For example, a portion of the data stored in the memory device may be instructions, such as instructions programmed for software, firmware, bootloaders, operating systems, routines, device drivers, application packages, etc. These instructions may be stored for use in a computing device implemented using a host system connected to the memory device.

[0041] Another portion of the data stored in the memory device can provide operands or inputs to the instruction when the instruction is executed in one or more processing devices of the host system.

[0042] Another portion of the data stored in the memory device may include the results generated from executing instructions using inputs and / or other inputs stored in the memory device.

[0043] Examples of such computing devices include personal computers, mobile computers, tablet computers, personal media players, smartphones, smart TVs, smart speakers, smart appliances, Internet of Things (IoT) devices, etc.

[0044] Security features implemented in the memory device can be used for secure communication between the memory device and a security server over a computer network. The communication path between the memory device and the security server may be insecure. Communication between the security server and the memory device can verify the identity of the memory device and / or control access to the memory device to prevent and detect impersonation, tampering, theft, and / or insecure operations.

[0045] The combination of the security features of the memory device and the security services of the security server allows parties involved in the use of the memory device and / or the computing device containing the memory device to trust the authenticity of the computing device and / or the memory device and the integrity of the data stored in the memory device, such as instructions to be executed in the computing device and the input of instructions.

[0046] For example, a security server and a storage device can be combined to implement a replacement of the Subscriber Identity Module (SIM).

[0047] A SIM card is typically used to identify a subscriber to cellular services on a telecommunications network. When a SIM card is inserted into a cellular phone, the cellular phone can access the cellular services provided to the subscriber's account; and when a SIM card is inserted into a substitute cellular phone, the subscriber can use the substitute cellular phone to access the cellular services associated with the account.

[0048] The need for a physical SIM card can be eliminated when the identity of a storage device installed in a cellular phone can be securely configured to represent a subscriber. The identity of the storage device can be configured and protected via the storage device's security features and the security services of a security server.

[0049] Generally, a security server can be configured on the Internet to provide security-related services to third-party computers and servers based on security features built into the storage device. These security features are built and encapsulated into the storage device. Security features and security services can be used even when the security implementation of a computing device with the storage device installed is not trusted. Therefore, the security implementation can focus on the security features of the storage device and the design of the security server. By simply using a storage device with security features, the security of computing devices using storage devices can be improved without requiring too much effort from the designers and / or manufacturers of the computing devices.

[0050] Security servers can provide services to verify the identity and / or authenticity of devices, detect counterfeit and / or tampered devices, track and manage device ownership, facilitate the transfer of device ownership / control, facilitate the configuration of computing devices to access third-party servers and / or service networks, and so on.

[0051] Security features of a memory device can be implemented within the integrated circuit (IC) package of the memory device during its manufacture. A memory device may have logic circuitry (or controllers) and memory cells formed on one or more IC dies. At least some of the memory cells in the memory device may be non-volatile, allowing data to be stored in the non-volatile memory cells even after the memory device has been powered off for extended periods (e.g., days, months, or even years). The non-volatile memory of the memory device can be used to store instructions and data for operation of the host system within the memory cells.

[0052] Memory devices may have a unique device secret (UDS). The unique device secret is protected within the memory device such that after the memory device is manufactured, the unique device secret is not transferred outside the memory device and cannot be read by the host system through any interface of the memory device.

[0053] The existence of a unique device secret in a memory device can be verified by a secure server through cryptographic calculations, such as the generation of an encryption key, the generation of a message hash value using an encryption function, and the generation of a message ciphertext encrypted with the encryption key.

[0054] Encrypting a message using an encryption key involves computation of the ciphertext representing the message. The message can be effectively recovered from the ciphertext using the corresponding encryption key by performing a predefined decryption computation. Recovering the message from the ciphertext is generally infeasible without the corresponding encryption key used for decryption. The difficulty level of recovering the message without knowing the corresponding encryption key indicates the security level of the cryptographic computation. The security level largely depends on the length of the encryption key used for encryption and the encryption algorithm used.

[0055] In symmetric encryption, the encryption key used for decryption is the same as the encryption key used for encryption. In asymmetric encryption, the decryption key and encryption key are different and generated in pairs. One of the pairs is used as the private key and therefore as the secret; the other in the pair is used as the public key. It is generally not feasible to calculate the private key from the public key. The difficulty level at which the private key can be recovered from the public key represents the security level of the asymmetric encryption.

[0056] Cryptographic hashing of a message maps the message to a hash value representing the message. However, some information is lost during hashing, making it impossible to recover the message from the hash value. Many messages can map to the same hash value. Generating a modified version of a message that can hash to the same hash value is generally not feasible, especially when the modified version resembles the original message.

[0057] Cryptographic computation for key generation involves calculating an encryption key for symmetric encryption or a pair of encryption keys for asymmetric encryption based on a set of data. The probability of generating the same key or key pair when the same set of data is not available is low. The probability level indicates the strength of the cryptographic computation used for key generation.

[0058] Generally, any cryptographic computation technique used for encryption, hashing, and key generation can be used with storage devices and secure servers. Therefore, this disclosure is not limited to specific encryption, hashing, and / or key generation techniques.

[0059] In addition to a unique device secret, the memory device may also store additional data to represent the data and / or hardware configuration of the memory device and / or the computing device on which the memory device is installed. A portion of this additional data may or may not be kept as a secret of the memory device. The unique device secret and the additional data can be used to generate a secret encryption key representing the identity of the memory device and / or the computing device.

[0060] The logic circuitry (or local controller) of the memory device may implement an encryption engine, an identity engine, and an access controller. The encryption engine of the memory device is configured to perform cryptographic computations (e.g., hashing, encryption / decryption, key generation) within the memory device to support the operation of the identity engine and the access controller. This implementation of the encryption engine within the memory device eliminates the need to rely on an external processor for secure computations within the memory device, thus enhancing security by preventing secrets from being transferred outside the memory device and preventing tampering and theft of the cryptographic computations. Optionally, at least a portion of the cryptographic computations involved in the security features of the memory device may be implemented by storing instructions in the memory device for execution by the host system of the memory device, while striking a balance between the security level and complexity of the memory device's logic circuitry (or local controller).

[0061] The encryption engine of the memory device can be used to apply a cryptographic hash function to a message to generate a hash value, generate a symmetric encryption key or a pair of asymmetric encryption keys from a set of data, generate ciphertext of the message using the encryption key, and / or recover the message from the ciphertext using the encryption key.

[0062] An access controller for a memory device is configured to control the execution of commands received in the memory device using cryptographic keys. For example, permission may be required to request the memory device to execute commands such as read, write, delete, or modify on various portions of the non-volatile memory of the memory device. Permissions may be represented by corresponding cryptographic keys. After receiving a permission command for execution in the memory device, the access controller may use a cryptographic engine to perform a computation if it determines whether the command originates from a sender with a cryptographic key representing permission. After the computation indicates that the sender possesses the cryptographic key and therefore has permission, the access controller allows the command to be executed within the memory device. Otherwise, the access controller may reject, ignore, or discard the command. This type of access control prevents unauthorized access to data stored in the memory device, prevents unauthorized alteration of the memory device, and prevents tampering and / or theft of counterfeit and / or insecure devices forming the memory device.

[0063] Generally, verifying whether the message sender possesses the encryption key involves the verification code used to verify the message. The verification code can take the form of a hash digest, digital signature, hash-based Message Authentication Code (HMAC), or Encrypted Message Authentication Code (CMAC). The verification code is generated using the encryption key and the message as input to cryptographic operations such as hashing, encryption, and / or other computations, making it generally infeasible to generate a verification code without the encryption key or from a modified version of the message. Therefore, when the receiver confirms that the received verification code is valid for the received message and encryption key, the receiver can conclude that the sender possesses the corresponding encryption key and that the received message is the same as the message used to generate the received encryption key.

[0064] In some implementations, the recipient uses the same encryption key as the sender to generate the verification code to perform message verification. For example, the recipient generates the verification code for the received message using the same encryption key and compares the generated code with the received code. If a match is found, the received code is valid for the received message; and the sender can be considered to have the encryption key. Otherwise, the received code is invalid for the received message; the received message has changed since the verification code was generated, or the received code was generated using a different encryption key, or both.

[0065] In some implementations, the recipient performs message verification using the public encryption key in the key pair; and the sender generates the verification code using the private encryption key in the key pair. For example, the verification code can be generated by applying a hash function to the message to generate a hash value of the message. The ciphertext of the hash value obtained by encrypting the hash value using the encryption key can be used as the verification code. The recipient of the message and verification code performs verification using the corresponding decryption key, which is the same as the encryption key when using symmetric encryption and another key in the key pair when using asymmetric encryption. After recovering the hash value from the ciphertext using the decryption key, the recovered hash value can be compared with the hash value of the received message; if a match is found, the received verification code is valid for the received message; otherwise, the received verification code is invalid for the received message. Alternatively, the recipient can perform verification using the encryption key without performing decryption. The recipient can generate a message verification code using the encryption key and compare it with the received verification code.

[0066] In some implementations, the message and encryption key are combined to generate a hash value as a verification code, such as in hash-based message authentication codes (HMAC) techniques. For example, the encryption key can be used to generate two keys. After combining one of the two keys with the message to generate a message modified by the key, a cryptographic hash function can be applied to the key-modified message to generate a hash value, which is further combined with the other key to generate another message. After applying the cryptographic hash function (or another cryptographic hash function) to the other message, a hash-based message authentication code is generated. The message recipient can use the same encryption key to generate a hash-based message authentication code for the received message and compare it with the received hash-based message authentication code. If a match is found, the verification is successful; otherwise, the verification fails.

[0067] Generally, any technology used to generate and verify a message authentication code from a sender, and the encryption key used by the sender to generate the authentication code, can be used to determine whether the sender possesses the encryption key. The receiver will perform verification using an appropriate encryption key, which may be the same as the encryption key used to generate the authentication code, or be in the same asymmetric encryption key pair. Therefore, this disclosure is not limited to specific technologies such as hash digests, digital signatures, and / or hash-based message authentication codes.

[0068] For convenience, the verification code generated using the encrypted key to represent the message and the encrypted key can be collectively referred to as the digital signature of the message signed with the encrypted key. However, it should be understood that the verification code can be generated using various techniques, such as hash-based message authentication codes.

[0069] The memory device can be configured to store an associated encryption key for verifying a signature using an encryption key configured to represent permission to request the memory device to execute a command.

[0070] For example, an access controller may provide the owner of a memory device with a set of permissions that allow the owner to activate or deactivate one or more security features of the memory device, change one or more security settings, parameters, configurations or preferences of the memory device, and / or read data from segments of the memory device that are not readable by other users of the memory device.

[0071] For example, an access controller can grant authorized users of a memory device specific permissions to read, write, erase, or modify specific segments of the memory device.

[0072] When a memory device receives a command that requires access permissions to execute, the access controller can retrieve the corresponding encryption key to verify a verification code or digital signature of the message containing the command. If the verification code received for the received command is successfully verified, the received command is considered to have originated from a sender possessing an encryption key indicating permission to execute the command on the memory device. In response, the access controller allows the execution of the command on the memory device. Otherwise, the access controller blocks the execution of the command.

[0073] The memory device can be manufactured to be initially owned by a security server. Subsequently, the security server can grant and / or transfer partial or full access rights to one or more owners and users during the processing from the memory device assembled into the computing device to the computing device with the memory device for end-user use. The access controller can prevent tampering, theft, and unauthorized access, while providing flexibility to support different access rights transfer patterns for different owners and users, such as manufacturers of component computing devices with memory devices installed, manufacturers of computing devices with component computing devices installed, retailers, enterprise users, end-users, and alternative end-users, etc.

[0074] The identity engine of the memory device is configured to generate data indicating the identity of the memory device and / or the identity of the computing device in which the memory device is installed. To generate the identity data, the identity engine uses an encryption engine to generate a secret encryption key from a unique device secret and other data stored in and / or collected by the memory device (e.g., during the startup process of the computing device). The existence of the secret encryption key in the memory device can be considered evidence that the memory device possesses the unique device secret and other data used to generate the secret encryption key. The existence of the secret encryption key in the memory device can be verified by a secure server via a verification code or digital signature signed using the secret encryption key.

[0075] During the manufacturing of the memory device, a copy of the unique device secret is stored in a secure server and / or securely shared without being exposed. Subsequently, the secure server is configured to derive the same secret encryption key (and / or the corresponding public key when using asymmetric encryption) independently of the memory device, without requiring the memory device to transmit its unique device secret outside the memory device. Therefore, the secure server can verify that the memory device possesses a unique device secret by verifying that the memory device has the secret encryption key; and the secret encryption key, which identifies the memory device, can be changed during the process of integrating the memory device into components, devices, systems, and transferring it among manufacturers, retailers, distributors, companies, and / or end users. Without altering the unique device secret, the memory device entity represented by the secret encryption key can be updated to indicate that the memory device is assembled into components, devices, systems, customized and / or personalized, and / or owned and / or operated by different entities or users.

[0076] Encryption operations and communications can be performed to allow a secure server to verify that the storage device has a secret encryption key.

[0077] For example, the identity data presented by the memory device for verification may include a message indicating a public identifier of the memory device. This public identifier can be used to distinguish the memory device from other memory devices. The identity data may include a verification code or digital signature of the message in the identity data, signed using a secret encryption key. The identity data contains a copy of the message and the verification code or digital signature. Once the verification code and message data are verified by a security server, the security server can conclude that the public identifier provided in the identity data is authentic and that the identity data originates from a memory device with a secret encryption key.

[0078] The secret encryption key for the memory device can be generated using not only the unique device secret of the memory device but also additional data representing aspects of the memory device and / or the computing device on which the memory device is installed. This additional data may represent software, firmware, bootloader, applications, trace data stored in the memory device, or identifiers of computing device components in the computing device at the computing device's most recent boot time. If this additional data has been changed, the identity engine generates a modified secret encryption key. Therefore, a verification code generated using the modified secret encryption key will fail verification performed at the secure server. Thus, verification of the verification code generated by the identity engine also verifies the integrity and authenticity of the hardware / software / data composition of the memory device and the computing device on which the memory device is installed.

[0079] Authentication of the memory device and / or its host system can detect counterfeit, tampered, and stolen / lost devices. Based on a request from the owner, the security server can configure a stolen / lost device to operate in one of several degraded modes, such as unbootable, unreadable, encrypting / erasing data in non-volatile memory, self-destruction of the memory / storage function of the memory device, etc.

[0080] The security server is configured with an information database for verifying identity data generated by the identity engine of the memory device. The database allows the security server to generate a corresponding secret encryption key (and / or a corresponding public key when using asymmetric encryption) for the memory device. The encryption key can be generated by the security server without requiring the memory device to transmit its unique device secret outside the memory device after its manufacture. The encryption key can be generated, at least in part, based on additional data available after the memory device is manufactured.

[0081] The security server can store encryption keys representing the owner's permissions on the storage device. Using these encryption keys, the security server can generate commands to transfer ownership of the storage device and configure and / or transfer selected permissions, causing selected commands to be executed on the storage device. After reporting a lost / stolen computing device, the security server can detect usage of its storage device during storage device verification, as well as requests for services from third-party servers.

[0082] For example, when a third-party server receives a service request from a computing device with a storage device, the third-party server forwards identity data generated by the storage device from the computing device to a security server for verification. If the identity data is verified by the security server, the third-party server can provide the service to the computing device; otherwise, the service request can be rejected, discarded, or ignored.

[0083] When requested by an authorized party, the security server can sign a command or generate a verification code for the command to grant or revoke access to the non-volatile memory of the storage device. The command, signed by the authorized party, is forwarded to the storage device for execution. The signed command contains a message with the command and a verification code signed / generated using an encryption key representing the authority to execute the command on the storage device.

[0084] A memory device can be installed within a computing device as part of the computing device's identity and provide main memory / storage capacity. For example, instructions and associated data to be executed within the computing device can be stored in the memory device and protected from damage, alteration, and / or theft by the memory device's security features. Because the identity data generated by the memory device's identity engine is at least partially based on instructions / data stored in the memory device, the integrity and / or authenticity of the instructions and data used by the computing device are verified at least during the process of verifying the identity of the memory device and / or the computing device.

[0085] The security services provided by secure servers remove the security protections that third-party servers provide to operating and computing devices. Using storage devices and the services of secure servers can prevent unauthorized access without requiring significant effort from computing device manufacturers and third-party server operators. Therefore, third-party servers can operate using their core capabilities to provide their respective services without compromising security.

[0086] Third-party servers can use the services provided by the secure server to offer services to their subscribers without requiring subscribers to manually configure the computing device they are using. For example, subscribers can use their computing device to access their subscribed cellular services without inserting a physical SIM card into the computing device and / or performing other operations to customize the computing device for use with their subscriber account.

[0087] Subscribers can be identified by an account. When a subscriber purchases a computing device, ownership of the computing device is transferred to the subscriber via a secure server. Security features of the storage devices configured within the computing device are used to generate the device identity. When the computing device connects to a third-party server to obtain services, the third-party server requests verification of the device identity from the secure server. Based on ownership of the computing device and the account, the computing device can be dynamically linked to the account, enabling the computing device to access services provided by third parties using the account without requiring manual configuration of the computing device.

[0088] For example, during the verification of a computing device's identity, the owner / subscriber of the computing device is identified through the ownership management service of the security server. Once the owner / subscriber is identified, the subscriber identity can be built into the computing device's device identity or associated with the device identity in the security server's database. Subsequently, while verifying the device identity, services in the subscriber's account can be provided to the computing device by a third party without the subscriber explicitly directing / requesting services to the computing device.

[0089] Optionally, the computing device may establish a separate certificate with a third-party server, so that the third-party server does not need to contact the security server each time the computing device connects to the third-party server to obtain services.

[0090] Figure 1 Example computing systems according to some embodiments of the present disclosure are shown.

[0091] exist Figure 1 In this context, the integrated circuit memory device 130 has the security features described above.

[0092] Secure memory device 130 may store a unique device secret 101 for its authentication. In one instance, the unique device secret 101 is injected into memory device 130 within a secure facility and stored in a register of memory device 130. In another instance, the unique device secret 101 may be obtained from a Physically Unclonable Function (PUF) of memory device 130. The unique device secret 101 may be obtained via a secure facility and registered in a secure server 140. For example, the secure facility may be part of the manufacturing facility for memory device (e.g., 130). After memory device 130 is manufactured and / or leaves the secure facility, the unique device secret 101 in memory device 130 is not accessible via any interface of memory device 130 (e.g., host interface 147). Therefore, after the manufacture of memory device 130, the unique device secret 101 in memory device 130 is sealed within the integrated circuit package of memory device 130. The unique device secret 101 is protected within the security server 140 using robust security measures (e.g., using a hardware security module (HSM)) to prevent theft and unauthorized access.

[0093] The memory device 130 includes logic circuitry or a local controller that implements the encryption engine 107. The encryption engine 107 can perform cryptographic calculations, such as hashing, key derivation, encryption, and / or decryption, without relying on processing capabilities outside the memory device 130, such as the processing unit 118 of the host system 120.

[0094] For example, the encryption key 105 may be generated at startup based on a method specified by the Device Identity Synthesis Engine (DICE) and Robust Internet of Things (RIoT) standards, or another method. This key is based on a combination of a unique device secret 101 and device information 121 stored and / or obtained in memory cells 103 of memory device 130. Device information 121 may contain non-secret data that can be obtained by entities other than the security server 140 and memory device 130. To enhance security, device information 121 may include time-related information.

[0095] For example, encryption key 105 may contain two pairs of asymmetric encryption keys. The first pair of asymmetric keys is called the device identification key; and the second pair of asymmetric keys is called the alias key. The private device identification key is used to authenticate the authenticity of the alias key, thus reducing its use and mitigating its risk. The alias key can be used for more transactions / communications; and the alias key can be replaced more frequently than the device identification key to improve security, since the alias key is used more frequently and therefore poses a risk. For example, the private device identification key can be generated at startup and used to sign certificates, such as certificates for alias public keys; then, the private device identification key is immediately deleted from the memory device 130 to protect its confidentiality.

[0096] Generally, one of the encryption keys 105 generated using the unique device secret 101 and device information 121 can be used as the secret and identity of the memory device 130 to be verified by the security server 140.

[0097] For example, authentication of memory device 130 can be performed by verifying that memory device 130 has a secret encryption key 105. The presence of secret encryption key 105 in memory device 130 can be regarded as evidence that memory device 130 has a unique device secret 101 and stores an undisturbed version of non-secret data.

[0098] Using encryption engine 107, memory device 130 can prove that it possesses secret encryption key 105 without transmitting secret encryption key 105 and / or unique device secret 101 outside of memory device 130. For example, memory device 130 can use secret encryption key 105 to digitally sign a certificate or message to provide a verification code for the message along with secret encryption key 105. When security server 140 successfully verifies the verification code, security server 140 can conclude that memory device 130 possesses secret encryption key 105 and therefore has an identity represented by unique device secret 101.

[0099] Memory device 130 includes a host interface 147 for receiving commands from host system 120. The controller 116 of the host system can send commands to memory device 130 to request reading data from memory cell 103, writing data to memory cell 103, erasing data from a portion of memory cell 103, modifying data in a portion of memory cell 103, activating security features of memory device 130, configuring parameters related to security features in memory device 130, etc. At least some of the commands require permissions represented by an encryption key 106 stored in security server 140. An encryption key 106, which can be used to sign commands, is considered to indicate permission to request memory device 130 to execute commands.

[0100] The memory device 130 includes an access controller 109 configured to use an encryption engine 107 to verify a verification code generated using an encryption key 106 representing permissions associated with a command. If the command received has a valid verification code, the access controller 109 allows the memory device 130 to execute the command; otherwise, the command may be rejected, ignored, or discarded.

[0101] When the memory device 130 is manufactured, one or more associated encryption keys 105 are stored in the memory device 130 to provide ownership rights to the security server 140. Using the ownership rights, the security server 140 can sign commands used to execute in the memory device 130 to activate or deactivate security features, trigger the replacement of the secret encryption key that identifies the memory device 130, replace the encryption key used by the access controller 109 to verify the rights to execute one or more commands in the memory device 130 for one or more areas of the memory cell 103, and so on.

[0102] Optionally, after authenticating the identity of the authorized requester, the security server 140 may use an encryption key to sign the command to generate a verification code or digital signature for the command, enabling the requester to send the command with the verification code to the host interface 147 of the memory device 130, so that the command can be executed within the memory device 130.

[0103] Optionally, the security server 140 may grant specific permissions to an entity by replacing the encryption key 105 in the storage device 130, or by providing the entity with a corresponding encryption key 106 representing the permissions.

[0104] Typically, memory device 130 is connected to host system 120 to form endpoint 150 in a communication network 110, such as the Internet. Generally, endpoint 150 is a computing device. Examples of endpoint 150 include personal computers, mobile computers, personal media players, tablet computers, smartphones, smart TVs, smart speakers, smart appliances, Internet of Things (IoT) devices, etc.

[0105] The memory unit 103 of the memory device 130 can provide storage / memory capacity for the host system 120 to store instructions and data for implementing the functions of the endpoint 150. For example, the processing unit 118 of the host system 120 is configured to execute instructions loaded from the memory device 130 to initiate and perform operations.

[0106] The host system 120 may include a network interface 114 or another communication device to communicate with one or more of the client servers 141, ..., 143, thereby receiving services from the client servers 141, ..., 143.

[0107] A service request sent from endpoint 150 to client server 141 may include identity data generated by encryption engine 107 of storage device 130. Client server 141 may request security server 140 to verify the verification code contained in the identity data.

[0108] In addition to authenticating the identity of the storage device 130, the security server 140 can also provide security services to manage permissions for operating the storage device 130, configuring or changing the security features or settings of the storage device 130, detecting lost / stolen devices, revoking the activation of lost / stolen devices, and so on.

[0109] Memory device 130 and / or endpoint 150 may have a non-secret unique identifier 111. The unique identifier 111 can be used to uniquely identify memory device 130 and / or endpoint 150 among a group of memory devices and / or endpoints.

[0110] For example, the unique identifier 111 of the memory device 130 may include the manufacturer part number (MPN) of the memory device 130 and / or the serial number of the memory device 130. For example, the unique identifier 111 of the memory device 130 may include the public key of a pair of asymmetric encryption keys that are at least partially based on the unique device secret.

[0111] To authenticate that the memory device 130 and / or endpoint 150 have an identity represented by a unique identifier 111, the security server 140 verifies a message containing the unique identifier 111 (and other data 127) via a verification code signed using the memory device's secret encryption key 105. The secret encryption key 105 in the memory device 130 is generated using a unique device secret 101 in the memory device; and a corresponding encryption key 106 for verifying the verification code signed using the memory device 130's secret encryption key 105 is generated in the security server 140 from the corresponding unique device secret 101.

[0112] The secret encryption key 105 of the memory device 130 used to prove the identity of the memory device 130 may be generated not only based on the unique device secret 101 but also based on the device information 121 accessible to the memory device 130.

[0113] For example, device information 121 may include hash values ​​of instructions and / or data stored in memory unit 103. Furthermore, device information 121 may include tracking data stored in memory unit 103 for personalizing / customizing memory device 130 and / or endpoint 150 during component assembly to build endpoint 150. Additionally, device information 121 may include identification information for other components in endpoint 150, such as identification of controller 116, identification of processing device 118, identification of network interface 114, identification of additional software or data packets of endpoint 150 not stored in memory device 130, and / or identification and / or hash values ​​of firmware configured to control / operate memory device 130. During startup, the identification data may be collected as device information 121 for generating a secret encryption key 105 for memory device 130.

[0114] During the registration process, when the memory device 130 is configured to have device information 121, a copy of the device information 121 is uploaded to the security server 140 for association with the unique identifier 111 of the memory device 130 and / or endpoint 150. Registration of the device information 121 allows the identity of the memory device 130 to be linked to the data, software, and / or hardware configuration represented by the combination of the unique device secret 101 and the device information 121.

[0115] Figure 2 This illustrates the generation of identity data in an integrated circuit memory device according to one embodiment. For example, Figure 2 The technology can Figure 1 Implemented in the computing system.

[0116] exist Figure 2 In the middle, memory device 130 (e.g., such as Figure 1 The encryption engine 107 of the device is used to generate at least a secret key 137 using its unique device secret 101 and device information 121.

[0117] For example, when using asymmetric encryption, secret key 137 is the private key of encryption key pair 135. The associated public key 139 is generated together with the private key using encryption engine 107.

[0118] Alternatively, when using symmetric encryption, the secret key 137 can be generated and used without having the public key 139 and the key pair 135.

[0119] In some implementations, multiple key pairs 135 are generated and used. For example, when using a Device Identity Synthesis Engine (DICE) and a Robust Internet of Things (RIoT) approach, the first asymmetric key pair is referred to as the Device Identification Key; and the second asymmetric key pair is referred to as the Alias ​​Key. The private Device Identification Key can be used to authenticate the authenticity of the Alias ​​Key, and then immediately deleted and cleared from the memory device 130 and / or endpoint 150 to protect its confidentiality, particularly when the generation or use of the private Device Identification Key occurs at least partially in the host system 120. The Alias ​​Key can be used to authenticate other transactions and / or communications. For example, the private Device Identification Key may be generated at startup time and used to sign certificates, such as certificates for alias public keys, and then deleted. After verifying or confirming the identity of the memory device 130 and the authenticity of the public alias Key using a certificate signed with the private Device Identification Key as the secret key 137, the private alias Key can be used as the secret key 137 of the memory device 130 in subsequent operations until endpoint 150 restarts.

[0120] For example, the data 123 of device information 121 stored in memory unit 103 may include a set of instructions (e.g., software, firmware, operating system, application) to be executed by a processing device 118 of host system 120 connected to host interface 147 of memory device 130.

[0121] For example, data 123 may contain the cryptographic hash value of the set of instructions. For example, a known hash value of the set of instructions may be stored in memory unit 103; and the current hash value of the set of instructions may be calculated and compared with the known hash value. If the two hash values ​​match, the integrity of the set of instructions is verified; and the hash value of the integrity of the set of instructions may be used as part of the device information 121 for calculating the secret key 137.

[0122] Alternatively, the current hash value of the set of instructions stored in memory unit 103 can be directly used in the calculation of secret key 137. If the instructions have been changed (e.g., due to data corruption and / or tampering or theft), then the security server 140 will fail to verify secret key 137.

[0123] Optionally, data 123 may include an identification of the set of instructions, such as a hash value of the source code of the instructions, the name of the software / firmware package represented by the instructions, the version number of the package and / or the release date, etc.

[0124] Optionally, data 123 may include trace data stored in memory cell 103 during the process of building and / or customizing endpoint 150 containing memory device 130. For example, when memory device 130 is assembled into a component device (e.g., a memory subsystem), a trace data indicating the manufacturer, model, and / or serial number of the component device is stored in memory cell 103 as part of device information 121. Subsequently, when the component device is assembled into endpoint 150, a trace data is added to memory cell as part of device information 121. Additional trace data may be added to memory cell 103 as part of device information 121 to reflect the history of memory device 130 used to personalize the identity of memory device 130.

[0125] Optionally, device information 121 may further include data 125 received from host system 120 connected to host interface 147 of memory device 130.

[0126] For example, endpoint 150 may have host system 120 and memory device 130. Some components in host system 120 may be removed or replaced. Upon startup of endpoint 150, a portion of the instructions stored in memory cell 103 are executed to collect data 125 about components present in host system 120 at startup time. Thus, device information 121 may represent a specific configuration of the software / data and hardware combination of memory device 130 and / or endpoint 150. A secret key 137 generated based on device information 121 and a unique device secret 101 represents the identity of memory device 130 with said specific configuration.

[0127] To verify the identity of memory device 130 and / or endpoint 150, encryption engine 107 generates verification code 133 from message 131 and secret key 137.

[0128] As discussed above, the verification code 133 for the secret key 137 and message 131 can be constructed and / or verified using various techniques, such as hash digests, digital signatures or hash-based message authentication codes, symmetric encryption and / or asymmetric encryption. Therefore, the verification code 133 is not limited to a specific implementation.

[0129] Optionally, message 131 may include user identification, such as name, email address, registered user name, or another identifier of the owner or authorized user of the endpoint 150 where identity data 113 is generated.

[0130] Optionally, a portion of message 131 may be provided in encrypted form. For example, the message may be encrypted using the public key of security server 140, making it inaccessible to third parties.

[0131] Message 131 may be a certificate presenting a unique identifier 111 for memory device 130 and / or endpoint 150. Message 131 may further present other data 127, such as a counter value maintained in memory device 130, a password random number, and / or other information regarding the verification of identity data 113. Memory device 130 may monotonically increment the counter value to invalidate identity data with a low counter value to prevent replay attacks.

[0132] In some implementations, data 127 may include a portion of device information 121 used to generate secret key 137.

[0133] In some implementations, secret key 137 is a private alias key in a pair of asymmetric keys. Data 127 contains a certificate presenting the corresponding public alias key in the pair of asymmetric keys. The certificate presenting the public alias key is signed using a device identification key of memory device 130. The public alias key can be used to verify the verification code 133 of message 131 and the private alias key used as secret key 137. Once security server 140 verifies the certificate presenting the public alias key, which is signed using the device identification key of memory device 130 and provided as a portion of data 127, security server 140 can use the public alias key to verify the verification code 133 signed using the private alias key as secret key 137. In this implementation, security server 140 can use the public alias key provided in message 131 to verify verification code 133 without having to regenerate the pair of alias keys; and memory device 130 can use data not yet known to security server 140 to generate alias key pair 135.

[0134] Certificates that present public alias keys can Figure 2 The method of generating and verifying the secret key 137 is as follows: the secret key 137 is a device identification key generated using device information 121 and a unique device secret 101. Optionally, the memory device 130 initially provides a certificate with a public alias key to the security server 140. Subsequently, the memory device 130 may use a private alias key as the secret key 137, and the message 131 may not contain the public alias key, or the message 131 may not contain a certificate with a public alias key.

[0135] The data 127 in the message 131, which is signed to generate the verification code 133, may contain a challenge. For example, to challenge the memory device 130 to prove that it possesses the secret key 137, a random data item may be presented as part of the data 127 to be signed using the secret key 137. In some embodiments, a monotonically increasing counter value may be used as the challenge.

[0136] Furthermore, verifying the identity of the memory device 130 may involve using multiple secret keys and a verification code signed with the secret keys. For example, a device identification secret key can be used to initially establish the authenticity of the alias secret key and the identity of the memory device 130; and subsequently, the alias secret key can be used to verify the authenticity of the identity of the memory device 130. Generally, the device identification secret key and the alias secret key can be based on asymmetric or symmetric encryption, because the security server 140 can generate the corresponding encryption key generated by the memory device 130.

[0137] To enhance security, the memory device 130 does not use processing power outside of the memory device 130 to generate a copy of the secret key 137, nor does it transmit the secret key 137 outside the memory device 130. The generation and use of the secret key 137 are performed using the logic circuitry of the encryption engine 107 sealed within the memory device 130.

[0138] Alternatively, the operation of generating and using the secret key 137 can be implemented via a set of instructions stored in memory unit 103 and loaded into processing device 118 of host system 120 for execution. For enhanced security, the secret key 137 is not transmitted in plaintext across host interface 147; and the instructions can be configured to clear the secret key 137 from host system 120 after generation and / or after use.

[0139] Identity data 113 may be generated in response to power-on of memory device 130, in response to a request received in host interface 147, and / or in response to initiation of endpoint 150 (e.g., by executing a bootloader stored in memory unit 103). Data 127 may contain a count value maintained in memory device 130. The count value increments when the operation of generating identity data 113 is performed. Therefore, a version of identity data 113 having a certain count value invalidates a previous version of identity data 113 having a count value lower than said count value.

[0140] Figure 3 This illustrates a technique for controlling the execution of commands in a memory device according to one embodiment. For example, Figure 3 The technology can Figure 1 Implemented in the computing system and with Figure 2 The technology is used together.

[0141] exist Figure 3 In the process, when the controller 116 of the host system 120 sends a command 155 to the host interface 147 of the memory device 130, the access controller 109 determines whether the sender of the command 155 has the authority to request the memory device 130 to execute the command 155.

[0142] Encryption key 145 is configured to represent permissions. The sender of command 155 can generate verification code 153 from encryption key 145 and message 151 containing command 155.

[0143] As discussed above, the verification code 153 for the encryption key 145 and message 151 can be constructed and / or verified using various techniques, such as hash digests, digital signatures or hash-based message authentication codes, symmetric encryption and / or asymmetric encryption. Therefore, the verification code 153 is not limited to a specific implementation.

[0144] Access controller 109 uses the corresponding access control key 149 to verify the verification code 153 submitted to host interface 147 for command 155. Access controller 109 uses encryption engine 107 to generate a verification result 159 for the received message 151 and the received verification code 153. Based on the verification result 159, access controller 109 may selectively allow command 155 to be executed in memory device 130 or prevent the execution of command 155.

[0145] For example, access control key 149 may be one of the encryption keys 105 stored in memory device 130. Different access control keys can be used to control different permissions for executing different commands and / or for executing commands acting on different segments of memory unit 103.

[0146] For example, encryption key 145 can be stored in security server 140 to grant associated permissions to security server 140.

[0147] In one embodiment, the security server 140 is configured to generate a verification code 153 representing the entity in response to an entity requesting a verification code 153 to execute a command 155 in the memory device 130.

[0148] Optionally, encryption key 145 is generated during the verification of identity data 113 generated using secret key 137; and a secret known between memory device 130 and security server 140 (e.g., secret key 137) allows session key generation as encryption key 145, representing the authority to execute selected commands in memory device 130 during a communication session with time limits. Optionally, the period of device power-on can be used as a session delimiter, allowing a new count value to be generated during the next power cycle, thereby enabling the generation of a new session key.

[0149] Encryption key 145 can be configured to be valid for a short period after verifying identity data 113 and establishing a session key. After security server 140 verifies that the entity is authorized to execute command 155 in memory device 130, security server 140 can generate verification code 153 and provide verification code 153 to the entity. The entity can then send message 151 and verification code 153 to host interface 147. Once access controller 109 of memory device 130 determines that verification code 153 is valid using encryption engine 107 and access control key 149, verification result 159 allows memory device 130 to execute the received command 155; otherwise, access controller 109 can reject or ignore the received command 155.

[0150] In another embodiment, after the security server 140 configures the access control key 149 in the memory device 130, the security server 140 may provide the entity with an encryption key 145 representing the permission to execute command 155 in the memory device 130.

[0151] Message 151 may contain data 157 indicating restrictions on the request to execute command 155.

[0152] For example, data 157 may include an execution count value maintained in memory device 130, making CAPTCHAs generated for lower counts invalid.

[0153] For example, data 157 may contain a password random number created for a specific instance of the request to execute command 155, so that verification code 153 cannot be reused for another instance.

[0154] For example, data 157 could contain a time window in which CAPTCHA 153 is valid.

[0155] For example, data 157 may contain an identification of a memory region in which command 155 can be executed.

[0156] For example, data 157 may contain operation types that allow command 155 to be executed in memory device 130.

[0157] Figure 4 This illustrates a technique for verifying the integrity of data stored in a memory device, according to one embodiment. For example, Figure 4 The technology can be used Figure 1 The memory device 130, and with Figure 2 and / or Figure 3 The technologies are used in combination.

[0158] exist Figure 4 In the memory device 130, memory cell 103 stores not only content 161 but also the hash value 163 of content 161. To determine the integrity state 165 of content 161, encryption engine 107 applies a cryptographic hash function to content 161 to generate a current hash value for content 161; and encryption engine 107 compares the current hash value with the stored hash value 163 to determine if they are the same. If they are the same, then the integrity of content 161 required to verify the stored hash value 163 is confirmed.

[0159] Hash value 163 can be stored as part of device information 121 used to generate secret key 137 to verify the identity of memory device 130.

[0160] Content 161 and hash value 163 are stored in different segments of memory device 130. Access controller 109 provides and / or enforces different levels of permissions to access content 161 and hash value 163.

[0161] For example, the manufacturer of endpoint 150 may store content 161 in memory unit 103, allowing the processing unit 118 of host system 120 in endpoint 150 to run programs or routines within content 161 to provide the intended functionality of endpoint 150. Additionally, the manufacturer and / or security server 140 may store hash value 163 in a separate segment for integrity checks. End users of endpoint 150 can access and use content 161 in the memory unit, but cannot access hash value 163. If content 161 is corrupted or tampered with, encryption engine 107 may detect the change and generate an integrity state 165, causing access controller 109 to block access to content 161. When the manufacturer has an updated version (or replacement) of content 161, the manufacturer may perform an update in memory unit 103 and issue a command 155 with a verification code 153 to update hash value 163. Optionally, security server 140 may generate verification code 153 in response to a request from the manufacturer.

[0162] Device information 121 and encryption key 105 in memory device 130 can be stored in a secure segment of memory device 130 and protected via access controller 109 by owner rights represented as encryption key 106 stored in security server 140.

[0163] Different secrets (e.g., unique device secret 101, secret key 137) and contents (e.g., device information 121, content 161) may be protected with different security levels and / or using different security strategies to balance security and usability.

[0164] Unique device secret 101 can be protected with the highest level of security within memory device 130. For example, once memory device 130 leaves the secure manufacturing facility and / or after the manufacturing operations of memory device 130 are completed, unique device secret 101 cannot be changed via commands to host interface 147 (and / or any interface of memory device 130). Preferably, unique device secret 101 is only accessible by encryption engine 107 during the generation of a secret key (e.g., 137) used to represent the identity of memory device 130 and / or endpoint 150. For example, unique device secret 101 can be configured to be available only for a limited time upon endpoint 150 startup.

[0165] For example, a device identification key can be protected by minimizing its use. An alias identification key is more secure than a device identification key and is replaced more frequently. Different operations and / or permissions can be used to replace both the device identification key and the alias identification key.

[0166] Figure 5 This illustrates a security service provided to a client server based on security features implemented in a memory device, according to one embodiment.

[0167] For example, Figure 5 The security services shown can be based on Figure 2 , 3 and / or the security features shown in 4 Figure 1 Implemented in the computing system.

[0168] exist Figure 5 In this configuration, client server 141 is set to provide services to computing devices, such as... Figure 1 The endpoint 150 of the memory device 130 connected to the host system 120.

[0169] In order to request services from client server 141, host system 120 (e.g., executing instructions retrieved from memory device 130) requests identity data 113 from memory device 130. For example, identity data 113 can be... Figure 2 It is generated in the manner shown in the figure.

[0170] The host system 120 embeds the identity data 113 in the request 171 transmitted to the client server 141.

[0171] To determine whether endpoint 150 is entitled to the service, client server 141 extracts identity data 113 from request 171 and generates request 173 for security server 140 to provide security services based on identity data 113.

[0172] Security server 140 may perform authentication of identity data 113, determine the authenticity of storage device 130 and / or endpoint 150, and provide the result to client server 141 in response 174. Based on the result, client server 141 may provide response 172 to host system 120.

[0173] For example, response 174 may indicate whether identity data 113 is from a counterfeit device, or from a device in which data 123 or content 161 related to the identity of endpoint 150 and / or memory device 130 has been altered, damaged, changed or tampered with, or from a lost or stolen device.

[0174] In some implementations, request 173 may identify a command 155 to be executed in memory device 130. After verifying identity data 113 and verifying the client server 141 and / or endpoint 150's permission to request command 155 to be executed within memory device 130, security server 140 may use encryption key 145 to generate a verification code 153 for command 155 and provide verification code 153 to client server 141 in response 174. Using the security service, client server 141 is relieved of the security burden associated with the management of permissions and the encryption key 145 representing those permissions.

[0175] Optionally, response 174 may include an encryption key 145 representing permission to execute command 155 in memory device 130. To reduce the security burden on client server 141, encryption key 145 may be configured to expire after a short period of time.

[0176] Optionally, when the identity data 113 is determined to be associated with a lost or stolen device, the response 174 may include a command 155 and / or its verification code 153, such that when the command 155 is executed in the memory device 130, the access controller 109 may disable at least some features that the host system 120 can access via the host interface 147.

[0177] For example, after command 155 is executed in memory device 130, access controller 109 can be configured to disable the bootloader stored in memory cell 103 of memory device 130.

[0178] For example, command 155 can cause access controller 109 to block access to one or more segments of memory cell 103.

[0179] For example, command 155 may require access controller 109 to have permission to access one or more segments of memory unit 103, the permission being represented by a new encryption key 106 stored in security server 140.

[0180] For example, command 155 can cause access controller 109 to corrupt the data in one or more segments by clearing the decryption key used to decrypt data stored in one or more segments of the memory cell.

[0181] For example, command 155 can cause memory device 130 to self-destruct and be irreversibly damaged.

[0182] Instructions retrieved from memory unit 103 for execution in host system 120 may include an acceptable command 155 as a routine that responds to memory device 130 by providing identity data 113. In some embodiments, client server 141 may provide a connection that allows security server 140 to send command 155 to memory device 130 for execution.

[0183] The technologies discussed above can be used to implement new ways of authenticating service subscribers.

[0184] For example, memory device 130 can be configured to generate a multi-factor device platform identity for endpoint 150 with improved security. The identity can be generated by combining: a unique device secret 101 of memory device 130, platform source code of one or more applications running on endpoint 150 to establish a secure connection to a service or network (e.g., client server 141 or 143), and a unique identifier for network interface 114 or communication device. For example, the unique identifier could be the identifier of a modem installed on endpoint 150 to communicate over communication network 110. For example, the multi-factor device platform identity can be based at least in part on the International Mobile Equipment Identity (IMEI) number of endpoint 150 configured to access cellular services. For example, when endpoint 150 involves a vehicle, the multi-factor device platform identity can be based at least in part on the Vehicle Identification Number (VIN). Such a strong identity can be used in conjunction with cloud-based Subscriber Identity Module (SIM) functions in login, network access to cloud services (e.g., cellular subscription services), and registration.

[0185] The security features of the secure server 140 and the storage device (e.g., 130) provide a secure storage device technology platform. The platform can be configured to support authentication of endpoint 150 by measuring data stored in memory cells 103 of the secure storage device (e.g., 130). Additional network security protection for the endpoint can be achieved by controlling access to content 161 stored in the storage device (e.g., 130). Access control can be implemented through secure hardware manufacturing operations and password-based permission controls, as described above. Figures 1 to 5 As discussed above, platforms equipped with such memory devices (e.g., 130) can achieve a sufficient level of network security protection to support cloud-based virtual SIM solutions and no longer require a physical SIM card on endpoint 150 to access cellular connectivity.

[0186] A secure storage device technology platform may include a combination of a secure storage device (e.g., 130) and software that meets DICE RIoT requirements for generating identity data 113 for an endpoint (e.g., 150) initiated using the secure storage device. This identity data 113 for endpoint 150 is generated based on the identity of the secure storage device 130 used to initiate endpoint 150 and other factors. This identity data 113 may be passed to client server 141 during login (e.g., service registration). Client server 141 may communicate with security server 140 to verify the identity of endpoint 150. When identity data 113 is verified, client server 141 can trust endpoint 150 to be authentic and therefore registers the service with endpoint 150.

[0187] For example, such a service could be a cellular connection typically registered to a physical SIM card. Identity data 113, verified by a secure storage device technology platform and protected by secure login, can provide endpoint (e.g., 150) identification in a manner as secure as or more secure as using a physical SIM card to identify the endpoint. A cloud-based virtual SIM can be bound to identity data 113 verified by the secure storage device technology platform throughout the service subscription lifecycle.

[0188] Typically, service networks (e.g., payment card networks, cellular communication networks) identify subscribers via smart cards. Traditional smart cards are configured as integrated circuit chips embedded in a plastic card. The integrated circuit chip in the smart card stores data identifying the customer's account and may optionally store data related to services provided to the account by the service network. The integrated circuit chip can be read via metal contacts configured on the surface area of ​​the plastic card and / or the wireless transceiver.

[0189] For example, a Subscriber Identity Module (SIM) (also known as a SIM card) is a type of smart card. SIM cards are typically used in mobile phones to identify an account used to access cellular communication network services. When a SIM card is attached to a mobile phone, the cellular communication network provides services to the mobile phone based on the account identified by the SIM card. When a SIM card is attached to a replacement mobile phone, the replacement mobile phone can access the services configured for the account.

[0190] For example, a SIM card can store a mobile subscriber identity, such as an International Mobile Subscriber Identity (IMSI) number. Mobile / cellular network operators can assign authentication keys to the IMSI number and the SIM card. The SIM card stores the authentication key. The SIM card can be authenticated based on a digital signature signed using the authentication key. After the SIM card is authenticated, a mobile phone with the SIM card can receive mobile / cellular services in an account associated with the mobile subscriber identity.

[0191] The Europay MasterCard Visa (EMV) card is another example of a smart card. EMV cards can be used to receive financial services within a payment card processing network to access bank accounts such as debit and credit accounts.

[0192] The integrated circuit memory device 130 can be configured to prevent unauthorized access to its memory cells 103 and to ensure the unique identity of the memory device 130 itself and / or the endpoints 150 on which the memory device 130 is installed. Figure 6 As shown, the secure storage device 130 with security features can be used to implement the functions of smart cards such as SIM cards and EMV cards using data remotely supplied to the secure storage device and / or data stored in a secure server.

[0193] Figure 6 A system and method for configuring and authenticating endpoints of card-based services, according to one embodiment, are shown.

[0194] For example, Figure 6 Systems and methods that can be used Figures 2 to 5 The technology in Figure 1 Implemented in the computing system.

[0195] exist Figure 6 In this context, the memory device 130 can use a device with... Figures 1 to 5 The integrated circuit memory device 130 implements security features. The access controller 109 of the memory device 130 can use one or more access control keys 213 to control read and write operations to at least some memory regions in the memory device 130.

[0196] For example, memory device 130 is initially manufactured with access control key 213, allowing security server 140 to have full access to memory regions within memory device 130. Memory device 130 is further manufactured to include at least a portion of device identity data 211 that uniquely identifies memory device 130 among a group of memory devices.

[0197] For example, device identity data 211 can be used Figure 2 The technology shown in the figure is generated.

[0198] For example, during the manufacture of memory device 130, the root secret of memory device 130 (e.g., unique device secret 101) is loaded into security server 140 during the operation of memory registration 231. The root secret may be a number generated by a physically unclonable function (PUF) of memory device 130, or a random number selected and stored in memory device 130 during its manufacture. Security server 140 may include a key management server configured to manage encryption keys for secure memory devices (e.g., 130). The root key may be considered and / or used as a secret encryption key. The root secret may be obtained from memory device 130 during its manufacture, or injected into memory device 130 for use in memory registration 231. Preferably, the manufacture of memory device 130 is such that the root secret is not provided outside of memory device 130 after its manufacture.

[0199] Device identity data 211 may be a root secret that is not disclosed, altered, or provided outside of the memory device 130.

[0200] After the memory device 130 leaves the manufacturing facility, the root secret and other secrets in the device identity data 211 cannot be accessed via the communication interface (e.g., host interface 147) of the memory device 130. Because the memory device 130 implements a set of data access policies to prevent secret leakage and data tampering stored in the access-protected area of ​​the memory device 130, the memory device 130 can be considered a secure memory device. The secure server 140 stores information that can mimic the computation performed by the memory device 130 to generate derived secrets independently of the memory device 130. Therefore, the secure server 140 can regenerate the derived secrets of the memory device 130 without the memory device 130 transmitting the derived secrets via its communication interface (e.g., host interface 147).

[0201] For example, the root secret of memory device 130 can be implemented via a Physically Unclonable Function (PUF). The root secret of memory device 130 can be retrieved from memory device 130 and stored in security server 140 for memory registration 231 during the manufacture of memory device 130. The root secret can be used to generate derived secrets from device identity data 211. For example, the PUF can be used to derive a Diffie-Hellman key pair; and the Diffie-Hellman key pair can be used to create a unique device secret (UDS) 101 that can be securely shared between the device and the security server.

[0202] For example, device identity data 211 can be used Figure 2 The technology generated.

[0203] The derived secret is generated in a manner (e.g., based on a cryptographic hash function, random numbers, and / or monotonic count values) such that the root secret cannot be computed from the derived secret and / or other information used to generate the derived secret. For example, the derived secret may contain a private key of a pair of asymmetric encryption keys. For example, the derived secret may contain a symmetric encryption key.

[0204] Device identification data 211 may include a non-secret public identifier for memory device 130, such as the serial number of memory device 130, a unique identifier for memory device 130, and / or the public key of a pair of asymmetric encryption keys, etc. The public identifier can be used to uniquely identify memory device 130 among a group of memory devices without revealing the secret of memory device 130; and the secret of memory device 130 can be used to authenticate / confirm that memory device 130 is identified by the public identifier.

[0205] After the memory device 130 leaves the manufacturing facility, a derived secret in the device identity data 211 can be generated and / or replaced. An access control key 213 can be used to control the execution of operations that generate and / or replace the derived secret to prevent tampering. For example, the derived secret may contain an encryption key and / or certificate generated according to the Device Identity Synthesis Engine (DICE) standard.

[0206] During memory registration 231, at least the root secret of memory device 130 is stored in security server 140 in association with the public identifier of memory device 130. During the manufacturing process of memory device 130, the root secret of memory device 130 is known in a secure environment between memory device 130 and security server 140 during memory registration 231. Subsequently, additional information used to generate derived secrets may be disclosed without compromising the confidentiality of the derived secrets. The derived secrets can be used for the authentication of memory device 130 and may optionally be replaced.

[0207] Access control key 213 is configured to prevent unauthorized access to and / or manipulation of secrets in device identity data 211. For example, once access control key 213 is configured in memory device 130, the secrets are restricted to use by encryption engine 107 (e.g., regenerating derived secrets and / or generating digital signatures). For example, commands / requests received in host interface 147 of memory device 130 need to be digitally signed in a manner verifiable using access control key 213, such as... Figure 3 As shown in the diagram. If the digital signature applied to a command / request is invalid according to access control key 213, then the command / request may be rejected and / or ignored.

[0208] For example, access control key 213 can be used to authenticate the digital signature of an application on a command to perform a specific operation related to device identity data 211, such as replacing an encryption key or an asymmetric encryption key pair.

[0209] In addition, one or more additional access control keys 213 can be used to authenticate the digital signatures of the owner and / or authorized users of the memory device 130. Different authorized users may be restricted to accessing different areas of the memory device to perform specific operations (e.g., write, erase, read). The owner and other authorized users may have different scopes and / or permissions to operate the memory device 130.

[0210] Security server 140 can be configured as the initial owner of storage device 130. For example, the public key of security server 140 can be initially stored in storage device 130 as owner access control key 213 to provide owner permissions for commands signed using the private key of security server 140. After storage device 130 is delivered to a client, the client's public key can be stored as a replacement for owner access control key 213 to transfer owner permissions to the client.

[0211] Optionally, certain security features of the memory device 130 may be activated by a customer. Some aspects of the memory device 130 relating to the activation of security features can be found in U.S. Patent Application No. 17 / 014,203, filed September 8, 2020, entitled "Customer-Specific Activation of Functions in a Semiconductor Device," the entire disclosure of which is hereby incorporated by reference.

[0212] Endpoint 150 may be configured to include memory device 130 and other components 187. During the construction 233 of endpoint 150, memory device 130 is installed / assembled into endpoint 150; and soft module 217 and trace data 215 may be stored in memory device 130.

[0213] For example, soft module 217 may include a boot loader for endpoint 150, firmware for memory device 130 and / or a memory subsystem containing memory device 130, or an operating system or software application for endpoint 150. Soft module 217 may include instructions and data configured to perform functions. Instructions may be executed by logic circuitry of memory device 130, a controller of the memory subsystem on which memory device 130 is installed, and / or a processing unit 118 of the host system 120 of memory device 130 and / or the memory subsystem.

[0214] During endpoint construction 233, endpoint registration 235 may be performed to store tracking data 215 in security server 140 and / or storage device 130. Tracking data 215 may be part of the configuration and / or identity of endpoint 150.

[0215] For example, trace data 215 may contain the hash value of soft module 217 calculated using a cryptographic hash function. For example, trace data 215 may contain a secret assigned to endpoint 150.

[0216] Counterfeit endpoint 150 lacks tracking data 215 and cannot pass endpoint authentication 239, which relies on tracking data 215. Therefore, system security is improved. Further details and examples of the technology relating to tracking data 215 can be found in U.S. Patent Application No. 17 / 005,565, filed August 28, 2020, entitled "Secure Memory System Programming for Host Device Authentication," the entire disclosure of which is hereby incorporated by reference.

[0217] Endpoint identity data 188 can be used Figure 2 The technology generates the endpoint 150 to represent its configuration at startup time. For example, endpoint identity data 188 may include a certificate (e.g., message 131) generated based on a combination of a portion of device identity data 211, tracking data 215, and identification data of other components present at startup endpoint 150 (e.g., network interface 114, processing device 118, controller 116).

[0218] Device identity data 211 and / or endpoint identity data 188 may include one or more certificates generated using a Device Identity Synthesis Engine (DICE) according to standards developed by the Trusted Computing Group (TCG), which combine hardware secrets and source code to form a trusted identity. Further details and examples of techniques for generating device identities can be found in U.S. Patent Application No. 16 / 374,905, filed April 4, 2019, entitled “Login Software on a Secure Device for Generating Device Identity to Utilize Remote Server Authentication,” and published October 8, 2020, as U.S. Patent Application Publication No. 2020 / 0322134, the entire disclosure of which is hereby incorporated by reference.

[0219] The virtual card registration 237 operation can be performed to configure endpoint 150 for services on card-based service network 225, such as mobile / cellular communication networks, bank card processing networks, etc.

[0220] For example, endpoint 150 can connect to card server 223 to request card profile 219 of endpoint 150, represented by device identity data 211. To request card profile 219, endpoint 150 transmits the common portion of endpoint identity data 188 to card server 223. Card server 223 forwards endpoint identity data 188 to security server 140 for authentication 239 of endpoint 150. For example, a combination of... Figure 2 The discussion covers authentication technologies.

[0221] Once the security server 140 verifies that the endpoint identity data 188 is formed using the correct combination of the device identity data 211, tracking data 215, and other data of the endpoint 150 submitted and / or recorded in the security server 140 during endpoint registration 235, the card server 223 may allocate and / or store the card profile 219 to the storage device 130, or associate the card profile 219 with the endpoint identity data 188.

[0222] Virtual card registration 237 can be performed via a protected software module 217 in the storage device 130 and / or via a security manager, ensuring that the card profile 219 stored in the storage device 130 cannot be tampered with. Optionally, the security server 140 can generate a verification code for command 155 to write the card profile 219 into a secure segment of the storage device 130. Write permissions to the secure segment can be controlled via an encryption key stored in the security server 140. For example, the access controller 109 can use an access control key 213 corresponding to the card server 223 or the security server 140 to control the storage and / or replacement of the card profile 219 in the storage device 130.

[0223] In addition, the memory device 130 can Figure 4 The method shown verifies the integrity of the card profile and / or the software module 217 responsible for using the card profile 219.

[0224] When card profile 219 is protected in memory device 130 in endpoint 150, memory device 130 and / or endpoint 150 can operate in a manner equivalent to a corresponding smart card installed in endpoint 150. Card profile 219 securely attached to device identity data 211 can be considered a virtual smart card.

[0225] In some implementations, the soft module 217 is configured to use the encryption functions and / or processing capabilities of the logic circuitry of the integrated circuit memory device 130 to implement the encryption operations involved in the use of the card profile 219. For example, the card profile 219 may contain an authentication key; and the soft module 217 may be configured to generate a digital signature for authenticating / verifying the authentication key contained in the card profile 219.

[0226] For example, card file 219 can be like Figure 7 and Figure 8 As shown in the image.

[0227] Figure 7 A card profile of a virtual smart card according to one embodiment is shown.

[0228] exist Figure 7In the card profile 219, card data 241 and soft card module 243 may be included. Optionally, soft card module 243 may be installed as part of soft module 217 stored in memory device 130.

[0229] Card data 241 may include identification of the smart card (e.g., a virtual card), account, and / or subscriber. For example, card data 241 may identify the type of smart card, the service subscribed to by the account / card, and / or customer data related to the service (e.g., balance, transaction history, messages, etc.). In some implementations, card data 241 may include the same set of data stored in the physical smart card (e.g., an integrated circuit chip embedded in a plastic card configured according to the Universal Integrated Circuit Card (UICC) standard).

[0230] The soft card module 243 may contain instructions for manipulating card data 241 via the encryption engine 107 of the memory device 130. For example, the computational functions of an integrated circuit chip for a specific type of smart card can be implemented by executing the soft card module 243 via the secure memory device 130. The soft card module 243 allows the endpoint 150 to simulate computational operations of a physical smart card.

[0231] Figure 8 A card profile of a Virtual Subscriber Identity Module (SIM) according to one embodiment is shown.

[0232] exist Figure 8 In the card profile 245, card data 241 is included, such as Integrated Circuit Card Identifier (ICCI) 251, Mobile Device Identification Number 253, International Mobile Subscriber Identification Number 255, Authentication Key 257 assigned to International Mobile Subscriber Identification Number 255, and Service Data 247 relating to Mobile / Cellular Communication Services for International Mobile Subscriber Identification Number 255.

[0233] In conventional mobile phones using traditional SIM cards, the Integrated Circuit Card Identifier (ICCI) 251 is used to identify a SIM card among a group of SIM cards. The Mobile Equipment Identity Number 253 (e.g., in the form of an International Mobile Equipment Identity (IMEI) number or an IMEI Software Version (IMEISV)) is used to identify a mobile phone among a group of mobile phones. The International Mobile Subscriber Identity (IMSI) number is used to identify a subscriber / customer / account within a group. When the card profile 245 is attached to the endpoint 150, such numbers in the card profile 245 can be used for similar functions. For example, when the endpoint 150 is a mobile phone without a physical SIM card, the card profile 245 can be used as a virtual SIM card to identify the card, subscriber, and endpoint / mobile phone. For example, the Integrated Circuit Card Identifier (ICCI) 251 corresponds to and / or represents the device identity data 211 of the memory device 130; the Mobile Equipment Identity Number 253 corresponds to and / or represents the endpoint identity data 188 of the endpoint 150; and the International Mobile Subscriber Identity Number 255 represents a subscriber / customer / account in a mobile / cellular communication network.

[0234] For example, authentication key 257 is a secret assigned to International Mobile Subscriber Identity Number 255. When endpoint 150 requests a connection in a mobile / cellular network using International Mobile Subscriber Identity Number 255, the mobile / cellular network operator can look up authentication key 257 in a database and challenge endpoint 150 to prove it possesses authentication key 257. The security challenge may involve digitally signing a message containing a random number (RAND) using authentication key 257. The response to the security challenge may include a portion of the digital signature used for verification by the mobile / cellular network operator. The operator independently signs the message using the corresponding authentication key 257 associated with International Mobile Subscriber Identity Number 255 in the database. If the response matches the response calculated by the mobile / cellular network operator, the digital signature is verified; and therefore, endpoint 150 is considered to possess authentication key 257 assigned to International Mobile Subscriber Identity Number 255 and is eligible to receive services associated with International Mobile Subscriber Identity Number 255. Furthermore, a symmetric encryption key can be derived from the digital signature to protect communication between endpoint 150 and the mobile / cellular network in subsequent communication sessions.

[0235] For example, when SIM card profile 245 is installed in endpoint 150, endpoint 150 can communicate with the mobile / cellular network operator to request connection and respond to security challenges using the same protocol used by mobile phones with physical SIM cards. Therefore, the mobile / cellular network does not need to distinguish between endpoint 150 with SIM card profile 245 (which functions as a virtual SIM card) and other mobile phones with physical SIM cards.

[0236] Optionally, the card profile 245 may include an authentication module 259 configured to be executed by the encryption engine of the secure storage device 130 and / or the processing device 118 of the endpoint 150 to perform cryptographic calculations during the use of the card profile 245, such as generating responses to security challenges and / or symmetric encryption keys for a communication session.

[0237] exist Figure 6 In this context, after virtual card registration 237, endpoint 150 can use card profile 219 to receive services from card-based service network 225 to identify subscribers / customers / accounts. For example, card-based service network 225, initially configured to provide services to conventional smart cards, can seamlessly further provide services to endpoints (e.g., 150) that have implemented virtual smart cards by storing card profiles (e.g., 219) in a secure storage device (e.g., 130).

[0238] Optionally, endpoint 150 may be configured to perform communication with card-based service network 225 in the same manner as a mobile device having a physical smart card (e.g., SIM card) or a smart card (e.g., EMV card).

[0239] For example, endpoint 150 can be used as a smart card for a card reader. Endpoint 150 may include metal contacts for connecting to a card reader. For example, endpoint 150 may include a transceiver equivalent to a wireless smart card reader. Alternatively, additional card readers can be configured in the card-based service network 225 to read virtual cards from endpoint 150 using alternative communication connections. Examples of alternative connections may include near field communication (NFC) connections, Bluetooth connections, Wi-Fi connections, universal serial bus (USB) connections, etc.

[0240] In another example, endpoint 150 can be used as a mobile station with a built-in card reader to read smart cards inserted into the mobile station, such as mobile phones with SIM cards. Endpoint 150 can communicate with the card-based service network 225 to access service 227 using the same communication protocol as a mobile station with a physical SIM card.

[0241] Optionally, card profile 219 may be stored in card server 223 in association with endpoint identity data 188. Endpoint 150 may use endpoint identity data 188 to access service 227 in card-based service network 225. In response, card-based service network 225 may communicate with card server 223 to identify card profile 219 based on endpoint identity data 188. Furthermore, based on endpoint identity data 188, card server 223 may communicate with security server 140 to perform endpoint authentication 239 to verify that endpoint 150 had secure storage device 130 at the time of virtual card registration and had the same configuration represented by the combination of trace data 215, soft module 217, and component 187. When endpoint 150 is tampered with and / or modified, the change may be detected in status check 229 and / or endpoint authentication 239; in response, card-based service network 225 may refuse the request to access service 227.

[0242] Optionally, virtual card registration 237 can be performed promptly in conjunction with a request from access service 227. In response to the request, endpoint identity data 188 is verified via endpoint authentication 239. After successful endpoint verification, card profile 219 can be associated with endpoint identity data 188 and / or stored in memory device 130.

[0243] In some implementations, card server 223 is implemented as part of security server 140.

[0244] In some implementations, card server 223 is implemented as part of a network operator of card-based service network 225.

[0245] For example, Figure 6 The system can be used to simplify, secure, and accelerate the large-scale global deployment of Internet of Things (IoT) devices and a rich ecosystem of IoT services. For example, a Virtual Subscriber Identity Module (SIM) card can be used by IoT devices (e.g., endpoint 150) to connect to the Internet via mobile / cellular communication networks.

[0246] Security server 140 can be used as a memory-based security-as-a-service platform for endpoints such as IoT edge devices (e.g., 150). Card servers can be used to provide cellular connectivity solutions for such endpoints. Figure 6 The combination shown can create a universal end-to-end solution for zero-contact login of cellular-connected IoT devices to cloud services.

[0247] The complexity of enterprise IoT implementation plans presents challenges for the large-scale global deployment of IoT devices. These challenges include implementation difficulties related to cellular connectivity and network security. Compared to wireless LANs (e.g., Wi-Fi), cellular connectivity offers significant advantages for IoT deployment, such as longer range, better outdoor performance, stronger security, and existing global infrastructure. The requirement for physical SIM cards and contracts with mobile / cellular network operators slow down the adoption of cellular connectivity by IoT devices. Figure 6 The solution shown addresses this type of challenge.

[0248] A virtual SIM card, implemented by securely associating card profile 219 with endpoint identity data 188 and / or device identity data 211, eliminates the need for a physical SIM card. The deployment of virtual SIM cards provides highly scalable IoT security, cloud-based SIM management, secure contactless device registration and IoT service login, seamless global connectivity, and instant SIM activation.

[0249] like Figure 6 The solution shown is particularly advantageous for the industrial, infrastructure, automotive, aviation, transportation, and logistics sectors, which require borderless long-range connectivity for portable devices, even in the most remote locations, free from the limitations of border and short-range Wi-Fi networks.

[0250] like Figure 6 The system shown can greatly simplify flexible global connectivity and provide a wealth of possibilities for innovation in the IoT market.

[0251] The use of physical smart cards requires that the card identity and / or device identity be tightly paired with the services provided by the network (e.g., 225) during manufacturing to prevent device insecurity, operational insecurity, fraud and / or impersonation.

[0252] The Security Server 140 can be used to implement contactless authentication and late-stage certificate binding for third-party services, enabling end users to freely and securely access a wider variety of third-party IoT services.

[0253] The secure server 140 and / or card server 223 can be used to securely install software modules to customize IoT devices. For example, an online software module store can be provided to allow software modules to be stored in endpoint 150 and customized in a manner similar to the functional provisioning of different types of smart cards and / or SIM cards discussed above. This customization allows businesses to access vendor-agnostic IoT services to leverage and experiment with intelligent features and data insights in new ways.

[0254] With sophisticated malicious behavior and hacking attacks on devices ranging from IoT fish tanks to baby monitors, the threat environment is becoming increasingly dangerous, and cybersecurity has consistently been a weak link in IoT adoption. A secure server 140 can provide a security-as-a-service solution supported by security features implemented in a storage device (e.g., 130) that controls access and device identity data 211. Through its silicon root of trust, the secure storage device 130 provides a unique level of protection for the lowest layer of IoT software—from the boot process onwards—and possesses strong encrypted identity and security features inherent in the storage device 130 itself.

[0255] For example, a security-as-a-service implemented via a combination of security features embedded in a security server 140 and a secure storage device (e.g., 130) may include verifying the authenticity of a storage device (e.g., 130) that claims to have a public identifier by verifying whether the storage device (e.g., 130) has a root secret recorded via storage registration 231 during the manufacture of the storage device 130.

[0256] For example, Security as a Service may optionally further include identifying the owner of the storage device 130 based on an encryption key corresponding to an access control key 213 implemented to provide owner privileges.

[0257] For example, Security as a Service may optionally further include identifying the service provider of endpoint 150, which has storage device 130, based on the owner / manufacturer of storage device 130, before distributing endpoint 150 to end users / customers. Based on the service provider, security server 140 may download software modules 217 associated with the services provided by the service provider to customize endpoint 150. For example, customization may be performed during endpoint registration 235. Optionally, end users or enterprise users may select service providers; and security server 140 and / or card server 223 may push software modules 217 to storage device 130. Furthermore, in response to endpoint authentication 239, security server 140 may automatically push software updates to storage device. Thus, security vulnerabilities of field endpoints (e.g., 150) can be automatically reduced and / or minimized without additional effort from the individual OEMs of endpoints (e.g., 150).

[0258] For example, security-as-a-service may optionally further include tracking of lost / stolen devices. In response to endpoint authentication 239 registered as lost or stolen in security server 140, security server 140 may request access controller 109 of storage device 130 to disable access to a specific memory region and / or erase data from that specific memory region. In some cases, access controller 109 may disable normal operation of endpoint 150 by restricting access to resources such as bootloaders, operating systems, and applications. In some cases, access controller 109 may perform operations that irreversibly damage the memory functionality of storage device 130.

[0259] For example, Security as a Service may optionally further include an auditing service for the integrity of endpoint 150. For instance, storage device 130 may construct endpoint identity data 188 based on the cryptographic hash value of software module 217 stored in storage device 130, such that when software module 217 is changed, security server 140 can verify whether the current software module 217 is a valid distribution from the appropriate vendor. When software module 217 is found to be corrupted, tampered with, and / or damaged, security server 140 may initiate an update operation to repair the software module using a valid distribution from an online software store.

[0260] When an updated version of software module 217 becomes available, security server 140 can recalculate endpoint identity data 188 for authentication of endpoint 150. Therefore, when endpoint 150 has an outdated version of software module 217, security server 140 can detect the existence of the outdated version and request / initiate an update to software module 217 over the air. Optionally, security server 140 can track the configuration change history of endpoint 150 that affects endpoint identity data 188. For example, when requested, security server 140 can communicate with storage device 130 to restore a previous configuration.

[0261] For example, Security as a Service may optionally further include a device tracking service, which may provide the owner of endpoint 150 with activity data corresponding to the owner's access control key 213 (or another authorized user corresponding to another access control key). For example, the activity data may include location data and the usage of endpoint 150 in various services from the card-based service network 225.

[0262] Endpoint identity data 188 may contain the public identity of endpoint 150, such as an International Mobile Equipment Identity (IMEI) number (e.g., Mobile Equipment Identity Number 253). Subscription to services (e.g., cellular connectivity) on card-based service network 225 using the public identity of endpoint 150 can be pre-registered on card server (223) without using endpoint 150. For example, an IMEI number may be associated with International Mobile Subscriber Identity Number 255 in the database of card server 223.

[0263] When endpoint 150 attempts to connect to the card-based service network 225, endpoint 150's public identity (e.g., IMEI number) is authenticated using endpoint identity data 188 in endpoint authentication 239. In response, a subscription registered to International Mobile Subscriber Identity Number 255 is identified and used to generate a card profile 219 to bind the card profile 219 to endpoint 150. The binding may take the form of storing the card profile 219 in a secure storage device 130 within endpoint 150. Alternatively, the binding may take the form of associating the card profile 219 with endpoint identity data 188 in a database of card server 223.

[0264] In some cases, a group of endpoints (e.g., owned by an enterprise client) can share a reduced number of virtual SIM cards for cellular connectivity. For example, an enterprise client's IoT devices may not require simultaneous cellular connectivity. When an enterprise client endpoint 150 requires cellular connectivity, a virtual SIM card availability profile 219 is dynamically "installed" for endpoint 150 after endpoint authentication 239 during a communication session, so that it can be used for cellular services in a timely manner. When the communication session ends, the virtual SIM card can be used by another endpoint of the enterprise client. A physical SIM card can be moved from one mobile phone to another to allow different mobile phones to access cellular services registered to the same SIM card. However, physically moving a SIM card from one mobile phone to another is inefficient and not feasible for large-scale deployment. The on-demand installation of a virtual SIM card overcomes the limitations of a physical SIM card and provides improved security via endpoint authentication 239 before the virtual SIM card is installed.

[0265] For example, this instant installation of a virtual SIM card can be used to facilitate infrequent or one-time use of cellular connectivity. For example, cellular connectivity can be used to perform over-the-air firmware / software updates. For example, cellular connectivity can be used to periodically report the status of endpoint 150 (e.g., daily, weekly, or monthly). For example, endpoint 150 can report its health and / or location in relation to warranty service based on endpoint 150's location.

[0266] For example, Security as a Service may optionally further include an identity service that allows the public identity of endpoint 150 to be changed in a secure manner. For example, a group of endpoints of an enterprise client may share a reduced number of IMEI numbers. When endpoint 150 attempts to connect to the card-based service network 225 using an alternative public identity number from endpoint identity data 188, card server 223 and / or security server 140 may perform endpoint authentication 239, assign an unused IMEI number to endpoint 150, and associate card profile 219 with the IMEI number assigned to endpoint 150, so that endpoint 150 can obtain services from network 225 as a device represented by the IMEI number.

[0267] When such a secure memory device 130 is used in conjunction with the security-as-a-service provided by the secure server 140, the original equipment manufacturer (OEM) of the endpoint (e.g., 150) can provide security by assembling the secure memory device 130 into the endpoint (e.g., 150) without performing its separate security operations, such as secure key injection, designing and implementing secure elements, hardware components, or dedicated system-on-a-chip (SoC) features. Therefore, the secure server 140 and the secure memory device (e.g., 130) can provide plug-and-play security for OEMs of IoT devices (e.g., endpoint 150).

[0268] The services of security server 140 can be used to authenticate, activate, and manage secure storage devices (e.g., 130) at the edge after deployment. This capability can be extended throughout the entire lifecycle from the manufacturing supply chain to field installation and management to achieve platform hardening and device protection.

[0269] Figure 9 This illustrates a technique for authenticating memory devices according to one embodiment. For example, Figure 9 The technology can be used to... Figure 2 Identity data implementation Figure 5 Security services.

[0270] pass Figure 9 The authentication process can establish a session key 263 to protect communication between the security server 140 and the storage device 130, without trusting the client server 141 to handle security to protect the secrets of the storage device 130. Optionally, the session key 263 can be used by the access controller 109 to enforce permissions for a selected command 155 requested to be executed in the storage device 130.

[0271] exist Figure 9 In this process, the client server 141 may send a request 271 to the storage device 130 for the identity data 113 of the storage device 130.

[0272] Request 271 may include a password random number 267. For example, the password random number 267 may be generated by the security server 140 in response to a request from the client server 141, or it may be generated by the client server 141 and shared with the security server 140 for request 271. Alternatively, the memory device 130 may generate the password random number 267 in response to request 271 and provide a corresponding response 273 containing the password random number 267.

[0273] In response to a request 271 for identity data 113 of memory device 130, memory device 130 provides a response 273 containing a message containing a unique identifier 111 that identifies memory device 130.

[0274] A verification code 133 is generated for the message provided in response 273 using the secret key 137 of the memory device 130. As discussed above, the verification code 133 can be implemented using techniques such as hash digests, digital signatures, and / or hash-based message authentication codes. Verification of the verification code 133 can be performed by the security server 140 using the corresponding encryption key 106 stored in association with the unique identifier 111.

[0275] To protect response 273 and / or verification code 133 from security attacks (e.g., reusing response 273 and / or attempting to recover key 137), verification code 133 is generated for message 131 containing unique identifier 111, counter value 265, and password random number 267. Counter value 265 is obtained from counter 261 in memory device 130. The value of counter 261 increases monotonically. For example, counter 261 can be used to store a count representing a count of requests received for identity data and / or other data items or operations related to security. Therefore, a response containing a counter value 265 lower than the previously seen counter value can be considered invalid. Password random number 267 is used once in the generation of response 273 and is discarded by memory device 130. Response 273 does not need to explicitly include password random number 267 if it has been previously provided to or generated by security server 140.

[0276] Client server 141 forwards response 273 to security server 140 to request authentication of storage device 130. Using the unique identifier 111 provided in response 273, security server 140 can locate the corresponding encryption key 106 to verify verification code 133. For example, the corresponding encryption key 106 could be a secret key 137, or the corresponding public key when using asymmetric encryption.

[0277] Based on the verification of CAPTCHA 133, security server 140 provides authenticity indicator 275 to client server 141. Authenticity indicator 275 indicates whether storage device 130 is authentic. For example, security server 140 may generate and provide a certificate signed by security server 140 to extend the certificate chain of storage device 130 back to the verifier (e.g., the security server). Optionally, security server 140 may allow the download of a Certificate Signing Request (CSR), which allows the requester to use a Certificate Authority (CA) of their choice (instead of security server 140).

[0278] Through authentication via memory device 130, memory device 130 and security server 140 can establish a session key 263 for communication with each other in subsequent communication sessions. The session may be limited to a predetermined period of time following verification of response 273 or verification code 133. After said period, session key 263 expires and can therefore be corrupted or discarded. Furthermore, a subsequent request for identity data can terminate a previous session that began with a previous request for identity data.

[0279] Session key 263 may be generated at least in part based on a secret generated between the security server 140 and the memory device 130 that is known but not available for use in the communication channel between the security server 140 and the memory device 130.

[0280] For example, session key 263 can be derived at least in part from secret key 137. Furthermore, session key 263 can be derived at least in part from counter value 265 and / or password random number 267. Optionally, session key 263 can be derived at least in part from verification code 133. For example, verification code 133 and secret key 137 can be combined to generate session key 263.

[0281] In some implementations, the session key 263 is independent of the verification code 133; and the verification code 133 can be generated using the session key 263 derived from a secret key 137 or another secret known between the security server 140 and the memory device 130.

[0282] Figure 10 This illustrates a technique for generating commands to control the secure operation of a memory device, according to one embodiment. For example, Figure 9 The technology can be used to... Figure 3 and 10 Technical implementation Figure 5 Security services.

[0283] For example, after client server 141 requests permission to execute command 155 in memory device 130 using client permission data 283 for verification, security server 140 may provide client server 141 with verification code 153 for command 155 in response to request 281 from client server 141.

[0284] Figure 9 and Figure 10 Some communications can be combined. For example, in some cases, request 281 may include identity data 113 provided by memory device 130 as a response 273 to request 271 from memory device 130.

[0285] After client server 141 sends identification command 155 and a request 281 for memory device 130, if it is determined that client server 141 has the authority to control or operate memory device 130 using command 155, then security server 140 may generate a verification code 153 for command 155. Request 281 may include a unique identifier 111 of the memory device 130 that will execute command 155. For example, unique identifier 111 may be extracted by client server 141 from the response 273 to the request 271 for identity data of memory device 130 and / or the authenticity indicator 275 provided by security server 140.

[0286] As discussed above, verification code 153 can be implemented using techniques such as hash digests, digital signatures, and / or hash-based message authentication codes. Verification of verification code 153 can be performed by access controller 109 using access control key 149 of command 155. Verification code 153 can be generated using encryption key 277 stored in security server 140, which represents the authority to execute command 155 in memory device 130. For example, when encryption via asymmetric encryption is not used, encryption key 277 can be access control key 149; alternatively, when asymmetric encryption is used, access control key 149 is the public key in a key pair, and encryption key 277 is the private key in the key pair.

[0287] In one embodiment, access control key 149 and encryption key 277 are pre-configured for permissions on command 155. In another embodiment, access control key 149 and encryption key 277 are based on session key 263. For example, session key 263 can be used as access control key 149 and encryption key 277 for access control of command 155. In some embodiments, session key 263 is a key in a pair of asymmetric keys that can be used to implement encryption key 277 and access control key 149 involving encryption performed using asymmetric encryption.

[0288] When verification code 153 is based on session key 263, verification code 153 expires when session key 263 expires, which prevents verification code 153 from being reused outside of sessions where session key 263 is valid.

[0289] The message 151 provided in request 285 may include command 155 and password random number 287. Password random number 287 is arranged for command 155 / request 285 and is therefore different from password random number 267 used for transmitting identity data of memory device 130.

[0290] For example, in response to request 281, security server 140 may generate a random password number 287 and use it to generate verification code 153. The random password number 287 may include verification code 153 for client server 141 to generate request 285. Alternatively, client server 141 may generate the random password number 287 and provide it to security server 140 along with request 281. Alternatively, to generate request 281, client server 141 may request the random password number 287 from security server 140.

[0291] After client server 141 sends request 285 with verification code 153 obtained from security server 140, memory device 130 uses access control key 149 to verify the verification code 153 contained in message 151 of request 285. If verification code 153 is valid, then access controller 109 allows memory device 130 to execute command 155; otherwise, access controller 109 may prevent execution of command 155 in memory device 130.

[0292] For example, command 155 can be configured to activate the security features of memory device 130.

[0293] For example, command 155 can be configured to replace access control key 149 or secret key 137 in memory device 130. For example, the new secret key 137 can be generated using additional non-secret data provided during the manufacture of the computing device, which has memory device 130 installed but was not available at the time of its manufacture. For example, the new access control key 149 can be configured to grant a set of permissions to client server 141.

[0294] After executing command 155, memory device 130 provides a response 289 that can be forwarded by client server 141 to security server 140. Security server 140 can determine whether response 289 is correct. For example, memory device 130 can sign the response using session key 263 for verification by security server 140.

[0295] In some implementations, a replacement secret key for replacing the existing secret key 137 of the memory device 130 is generated independently by the memory device 130 and the security server 140 from a secret (e.g., a unique device secret 101) exchanged via the client server 141 and additional data. Optionally, the additional data may be protected by encryption performed using session key 263.

[0296] In some implementations, the secret key is replaced and transmitted from the storage device 130 to the security server 140 in an encrypted form using the ciphertext generated by the session key 263.

[0297] Figure 11 A method for using a virtual smart card according to one embodiment is shown. For example, Figure 11 The method can be used Figure 9 and 10 The technology in Figure 6 The above-mentioned combination is shown. Figure 1-5 The security features of the security server 140 and the storage device 130 discussed are implemented in the system.

[0298] At block 301, device identity data 211 representing the memory device 130 is generated by logic circuitry or a controller enclosed in the integrated circuit package of the memory device 130, based at least in part on the root secret of the memory device 130.

[0299] For example, memory device 130 may have a physically unclonable function (PUF) to generate a root secret.

[0300] For example, logic circuits or controllers may include a cryptographic engine configured to perform cryptographic computations without using a processor outside the integrated circuit package.

[0301] At frame 303, memory device 130 stores device identity data 211 in a first memory region of an integrated circuit memory cell formed on one or more integrated circuit dies enclosed within an integrated circuit package.

[0302] At block 305, the logic circuit controls access to the first memory region based on access control key 213.

[0303] At block 307, memory device 130 stores in a second memory region of an integrated circuit memory cell a boot instruction executable by one of a plurality of components having memory device 130 as an endpoint 150.

[0304] For example, device identity data 211 can be calculated and / or updated based on a hash value obtained by applying a cryptographic hash function to a boot instruction stored in a second memory region of memory device 130. Therefore, device identity data 211 can lock not only the hardware of memory device 130, but also the boot instructions (and / or other data, such as trace data 215) stored in memory device.

[0305] At frame 309, card profile 219 is written to the integrated circuit memory cell of memory device 130 to simulate the function of a smart card based on card profile 219.

[0306] For example, endpoint 150 may be configured via memory device 130 to generate endpoint identity data 188 representing the component configuration of endpoint 150 at its startup time. Endpoint identity data 188 may be calculated using: device identity data 211, tracking data 215 stored in memory device 130 during the construction 233 of endpoint 150, and identification data of components of endpoint 150 located outside the integrated circuit package of memory device 130.

[0307] For example, card profile 219 can be identified, generated, and / or assigned to endpoint 150 based on the authentication of endpoint identity data 188.

[0308] For example, card profile 219 may include soft modules (e.g., soft card module 243, authentication module 259) having instructions that can be executed by logic circuitry or a processor of endpoint 150 or any combination thereof to emulate the function of a smart card.

[0309] For example, card profile 219 can be stored in memory device 130 to emulate a Subscriber Identity Module (SIM) card typically used to authenticate a mobile phone when accessing a cellular communication network. For example, card profile 219 may contain an International Mobile Subscriber Identity Number 255 and an authentication key 257 associated with the International Mobile Subscriber Identity Number 255.

[0310] For example, when endpoint 150 requests a cellular connection to International Mobile Subscriber Identity (IMSI) number 255, the mobile / cellular network operator may issue a security challenge to authenticate endpoint 150. In response, card profile 219 can be used to generate a response to the security challenge by signing a message with a random number using authentication key 257, proving that the endpoint possesses authentication key 257. For example, authentication key 257 can be used to sign a message with a random number. The response to the security challenge may include a portion of a digital signature used for authentication; another portion of the digital signature can be used as a symmetric encryption key for encrypting communication sessions associated with the cellular connection.

[0311] Figure 12This illustrates a method for providing security services based on security features of a memory device according to one embodiment. For example, Figure 12 The method can be used Figure 9 and 10 The technology is based on the above combined Figure 1-5 The security features of the memory device 130 discussed are as follows: Figure 1 Implemented in the computing system.

[0312] At box 321, security server 140 receives a request (e.g., 173 and / or 281) from client server 141. The request contains identity data 113 of memory device 130 having access controller 109.

[0313] At box 323, the security server 140 determines the authenticity of the memory device 130 based on the secret and identity data 113 of the memory device 130.

[0314] For example, the secret could be a unique device secret 101 that is not transmitted outside the memory device 130 after its manufacture is completed in the secure facility. Identity data 113 is based on a secret key 137 generated at least in part based on the unique device secret 101. During the manufacture of the memory device in the secure facility, the secret is registered with a security server 140 to generate an encryption key 106 for verifying identity data 113, at least in part based on the secret. The encryption key 106 for verifying identity data 113 may be further generated based on data 125 received from the host system 120 during the startup time of the host system 120 of the memory device 130. After the manufacture of the memory device 130 is completed in the secure facility, the memory device 130 can be assembled into an endpoint 150 of the host system 120 having a host interface 147 connected to the memory device 130. At least a portion of instructions configured to execute in the processing unit 118 of the host system 120 is stored in the memory device 130.

[0315] At box 325, security server 140 generates verification code 153 for command 155.

[0316] For example, after determining that the client server 141 has the authority to execute command 155 in the memory device 130 based on the client permission data 283 stored in the security server 140, a verification code 153 can be generated for the client server 141 and provided in the response 174 based on the permissions.

[0317] For example, after determining that the memory device 130 is in an endpoint 150 that has been reported lost or stolen, a verification code 153 can be generated for the command 155 to deactivate the memory device 130.

[0318] At box 327, security server 140 sends response 174 containing verification code 153 to client server 141.

[0319] For example, response 174 may determine that the memory device 130 has a secret based on the fact that identity data 113 contains a verification code 133 generated using a secret.

[0320] At box 329, client server 141 transmits command 155 and verification code 153 to memory device 130.

[0321] At box 331, the access controller 109 of the memory device 130 verifies the verification code 153 to determine whether to block the execution of commands 155 in the memory device 130.

[0322] For example, when executed in memory device 130, command 155 causes access control key 149, which is used by access controller 109 to verify a verification code (e.g., 153) generated using encryption key 145, to change, the encryption key representing the permission to execute one or more commands in memory device 130.

[0323] For example, when executed in memory device 130, command 155 causes a change in the setting of a security feature of memory device 130. For example, the change may include activating or deactivating a security feature of memory device 130.

[0324] For example, after an endpoint 150 containing memory device 130 has reported loss or theft, when executed in memory device 130, command 155 causes memory device 130 to disable the bootloader stored in memory device 130.

[0325] For example, when executed in memory device 130, command 155 causes access controller 116 to block access to one or more segments of memory cell 103 in memory device 130.

[0326] For example, when executed in memory device 130, command 155 causes memory device 130 to clear the decryption key of the data stored in memory device 130.

[0327] For example, when executed in memory device 130, command 155 causes memory device 130 to irreversibly destroy at least one aspect of memory device 130.

[0328] For example, based on the verification of identity data 113, session key 263 can be established and known between security server 140 and storage device 130 without transmitting session key 263 via the connection between security server 140 and storage device 130. Access control key 149, which is used by access controller 109 to verify verification code 153 for command 155, can be based on session key 263.

[0329] Optionally, the security server 140 may transmit command 155 and verification code 153 to the memory device 130 based on instructions loaded from the memory device 130 and executed in the host system 120.

[0330] Figure 13 This illustrates a method for logging into an account to subscribe to a service endpoint according to one embodiment. For example, Figure 13 The method can be used Figure 9 and 10 The technology is based on the above combined Figure 1-5 The security features of the memory device 130 discussed are as follows: Figure 1 Implemented in the computing system.

[0331] At box 341, the server system receives a service-related request (e.g., 171 and / or 173) from endpoint 150. The service is provided via a computer network (e.g., network 110) of multiple subscribers whose services are represented by different accounts. The request includes identity data 113 generated by a memory device 130 configured in endpoint 150.

[0332] For example, the server system may include a security server 140 and / or a card server 223. Optionally, the server system may further include a client server 141 that communicates with the security server 140.

[0333] For example, the service could be cellular connectivity, payment card service, video surveillance service, cloud-based storage or computing service, and so on.

[0334] At box 343, the server system responds to the request and determines the authenticity of endpoint 150 based on the secret and identity data 113 in memory device 130. For example, the operation in box 343 can be performed in a manner similar to the operation performed in box 323.

[0335] At box 345, a subscriber is identified among multiple subscribers based on identity data 113 and ownership data based on endpoint 150.

[0336] For example, during the manufacture of endpoint 150 at the manufacturer's facility (e.g., 150), memory device 130 is connected to host system 120; and software packages for the operation of endpoint 150 are installed in memory device 130. Endpoint 150 is tested. In endpoint registration 235, memory device 130 is configured to generate key 137, which not only represents memory device 130 having a unique device secret 101, but also represents endpoint 150 having memory device 130, which at startup has data 123 in memory cell 103 and data 125 from host system 120.

[0337] When endpoint 150 is transferred from the manufacturer to distributors and end users or subscribers, data that associates the public identification of endpoint 150 with the subscriber's identity is stored in a server system. Ownership data can be stored in the server system without physically operating endpoint 150 (e.g., without opening the packaging that has enclosed endpoint 150 since its manufacture). For example, the public identification of endpoint 150 may include a unique identifier 111 for endpoint 150 and / or data 127 identifying the brand, model, and serial number of endpoint 150 known to the manufacturer of endpoint 150.

[0338] When a subscriber opens an account for services provided to endpoint 150, the subscriber's identity can be associated with the account.

[0339] For example, client permission data 283 may contain ownership data of endpoint 150 and / or subscriber data displaying subscriber accounts.

[0340] At box 347, in response to the request received in box 341, the account of the identified subscriber is determined.

[0341] For example, an account can be identified by matching the subscriber identity associated with identity data 113 in ownership data with the subscriber identity associated with the account in subscriber data.

[0342] At box 349, the server system enables services to be provided to endpoint 150 based on the account.

[0343] In some implementations, client permission data 283 stored in security server 140 indicates the association between subscriber identity data 113 and account. Therefore, during the verification of the authenticity of endpoint 150 based on received identity data 113, the account can be identified based on client permission data 283.

[0344] In an alternative implementation, client permission data 283 stored in security server 140 indicates the association between the subscriber's identity data 113 and the identity as the owner. Therefore, during the verification of the authenticity of endpoint 150 based on received identity data 113, the subscriber can be identified based on client permission data 283. Another server (e.g., client server 141 or card server 223) stores subscriber data to identify the account based on the subscriber identified by security server 140.

[0345] use Figure 13 The method allows the service subscribed to by the account to be provided / directed to endpoint 150 without requiring endpoint 150 itself to be customized for the subscriber and / or the subscriber's account. For example, a subscriber can simply unpack the encapsulation of endpoint 150 during the manufacture of endpoint 150 and use endpoint 150 to access the service subscribed to by the subscriber's account without inserting a card (e.g., a SIM card) to identify the subscriber or account and / or without interacting with an application or utility running in endpoint 150 to identify the subscriber or account.

[0346] For example, after endpoint 150 is created but before the request is received in box 341, endpoint 150 is not customized for the subscriber or the account. Endpoint 150 is created so that it can be used by any of the multiple subscribers. In response to the request received in box 341, endpoint 150 automatically links to the specific account of the subscriber who is receiving the service.

[0347] For example, before and / or after receiving services for a subscriber account, endpoint 150 does not contain any hardware components inserted into endpoint 150 to represent a subscriber, account, or any combination thereof.

[0348] For example, at least prior to the request received in box 341, endpoint 150 does not contain data stored in endpoint 150 to represent a subscriber, account, or any combination thereof.

[0349] For example, prior to the request received in box 341, endpoint 150 does not contain any indication of a subscriber, account, or any combination thereof, and does not have ownership data for endpoint 150; and ownership data is stored in the server system and not in endpoint 150.

[0350] Optionally, in response to a request received in box 341, the server system and / or endpoint 150 may store the identity data of endpoint 150 associated with the subscriber account.

[0351] For example, security server 140 can use encryption key 145 to generate verification code 153 for command 155. The server system can enable memory device 130 to receive command 155 and verification code 153. Before executing command 155 in memory device 130, access controller 109 of memory device 130 is configured to verify verification code 153 based on access control key 149. Optionally, access control key 149 and encryption key 145 can be based on... Figure 9 The session key is established in the manner described in the text.

[0352] When executed in memory device 130, command 155 causes memory device 130 to store additional data identifying the account. For example, the additional data may be a portion of device information 121 used to generate secret key 137 when generating updated identity data 113. For example, the additional data may be contained in data 127 of message 131 in updated identity data 113, which is generated by memory device 130 after the execution of the command. For example, the additional data may include card profile 219 identifying the subscriber account.

[0353] Alternatively, the data associated with the identity data 113 of the memory device 130 and / or endpoint 150 can be stored in the server system (e.g., as part of the client authorization data 283 and / or card profile 219) without changing the secret key 137 used to sign the identity data 113.

[0354] Since no operation is required on endpoint 150 to direct the subscriber's account service to endpoint 150, endpoint 150 can be configured as a cellular-connected IoT device without requiring a user interface tailored to receive cellular services. For example, endpoint 150 can be configured without a slot for inserting a card to identify the subscriber. Similarly, endpoint 150 can be configured without a user interface for receiving input from the end user to identify the subscriber.

[0355] In some implementations, endpoint 150 has a common hardware configuration capable of running different firmware to provide different functionalities. Furthermore, updated versions of the firmware can be installed in endpoint 150 to correct defects or errors in endpoint 150 running previous versions of firmware, thereby improving performance and / or providing new features. Optionally, firmware applications can run on a base version of the firmware to add functionality, features, and / or services.

[0356] For example, different client servers 141, ..., 143 can provide different services using the same hardware on endpoint 150 running different firmware. For example, the different client servers 141, ..., 143 can provide similar services using the same hardware on endpoint 150, but perform different processes implemented using different firmware.

[0357] After assembling endpoint 150 by installing different firmware and shipping it to end users or subscribers, endpoint 150 can be customized for different client servers 141, ..., 143.

[0358] For example, an online firmware store can be configured on communication network 110 to allow end users to purchase a specific version of firmware. Installing the selected version of firmware may or may not include firmware applications that run using the baseline version of firmware. After installing the selected version of firmware, endpoint 150 is customized to differ from endpoint 150 running the previous firmware in at least one respect.

[0359] In some cases, the updated firmware represents a service of endpoint 150 requested by a user of endpoint 150. The service of endpoint 150 may or may not depend on services provided by the client server or service provider.

[0360] The functionality of endpoint 150 can be defined at least in part by its firmware. For example, when endpoint 150 is running one version of firmware, endpoint 150 can provide one functionality to users of endpoint 150; and when endpoint 150 is running another version of firmware, endpoint 150 can provide different functionality to users of endpoint 150.

[0361] For example, different third-party service providers can offer software / firmware solutions for IoT devices based on common, general-purpose hardware platforms. For instance, firmware available in online stores can be programmed to enable general-purpose IoT devices to collaborate with third-party servers to provide specific types of services. Optionally, firmware applications available in online stores can run on a general version of firmware and use the basic services provided by the general firmware to provide specific types of services. The combination of a baseline version of firmware and a firmware application can be considered an enhanced version of firmware. When baseline versions of firmware on different endpoint hardware platforms provide standardized services, the firmware application can be device-independent and support a class of IoT devices from different vendors. Alternatively, the firmware application may be device-dependent and utilize the different hardware capabilities of different vendors.

[0362] Security server 140 can be coupled to an online firmware store to provide firmware updates to endpoints (e.g., 150) in response to verifying the authenticity of the endpoint.

[0363] For example, when endpoint 150 initially connects to client server 141, client server 141 communicates with security server 140 to verify the identity and / or authenticity of endpoint 150. The owner of endpoint 150 can be determined during the verification process. After the subscription service of endpoint 150 is identified, the relevant firmware application can be downloaded from an online firmware store and installed on endpoint 150 via over-the-air (OTA) update.

[0364] For example, security server 140 may generate a verification code 153 for command 155 to install the firmware application into storage device 130. After execution of command 155, the firmware application becomes part of data 123 stored in memory cell 103 of storage device 130 and is used as part of device information 121 when generating updated secret key 137 for updated identity data 113 for storage device 130 and endpoint 150.

[0365] Subsequently, when an update to the firmware application is available in the online firmware store, the outdated firmware application in endpoint 150 can be detected during the verification of identity data 113; and the security server 140 can initiate an over-the-air (OTA) update for endpoint 150 to reduce security risks.

[0366] For example, an online service store can provide cloud-based services, such as Internet of Things (IoT) devices, via an endpoint (e.g., 150). The same endpoint 150 can be customized via firmware updates used with different service providers that can operate different client servers 141, ..., 143.

[0367] For example, a user of endpoint 150 can access an online store to subscribe to services offered by a service provider, change their subscription, and / or move their subscription from one service provider to another. Subscriptions subscribed to by a user for endpoint 150 can be tracked as part of client permissions data 283 associated with the identity of endpoint 150. When security server 140 verifies the identity data 113 of endpoint 150, security server 140 can check whether endpoint 150 requires a firmware update for subscribing to services and / or replacing outdated firmware versions. If so, then security server 140 can customize and / or update the firmware of endpoint 150 via the online store before endpoint 150 receives the subscribed services from the service provider. Optionally, security server 140 communicates with endpoint 150 to direct endpoint 150 to the service provider's current client server 141. Alternatively, the updated firmware enables endpoint 150 to connect to the service provider's current client server 141.

[0368] Generally, the security server 140 may connect to or contain an online service store and / or an online firmware store. The server system may have a security server 140, an online service store, and / or an online firmware store. The server system may track accounts used to subscribe to services from different service providers and track firmware customizations selected / purchased by users at endpoints (e.g., 150).

[0369] The user's account on endpoint 150 can be tracked using the user's identity by the service provider subscribing to endpoint 150, and associated with the user's identity as the owner of endpoint 150 for automatic firmware updates. Through this association, firmware and / or service selections made by the user in online service stores and / or online firmware stores can be mapped to the user's endpoint 150. Alternatively, the user of endpoint 150 can explicitly select firmware and / or services for endpoint 150 using the public identifier of endpoint 150, which is part of endpoint 150's identity data 113.

[0370] In some implementations, endpoint 150 initially connects to security server 140 for the service. Security server 140 can identify the current provider of the subscription service registered in the online service store based on client permission data 283. After verifying the authenticity of endpoint 150 and identifying the service provider, security server 140 configures the firmware of endpoint 150 for the service provider (e.g., using an online firmware store) and directs endpoint 150 to the service provider's client server (e.g., 141, ..., or 143). Thus, endpoint 150 can seamlessly provide the service ordered from the online service store with minimal user effort.

[0371] Figure 14 This illustrates an endpoint customization technique using an online firmware store, according to one embodiment. For example, Figure 14 The technology can be used in reference Figures 1 to 5 The discussion of security services and features Figure 1 and / or Figure 6 Implemented in the computing system. Figure 14 The technology can be combined with Figures 9 to 13 The combination of technologies.

[0372] exist Figure 14 In this context, the online firmware store 170 is configured to facilitate the selection of firmware and / or firmware applications for customization and / or updates for endpoints (e.g., 150), and the security server 140 to verify the identity of endpoints (e.g., 150).

[0373] Endpoint 150 has a set of hardware, including host system 120 and memory device 130 with security features. The functionality of endpoint 150 can be defined, customized and updated by firmware 363 stored in memory device 130 and executed in host system 120 of endpoint 150.

[0374] The manufacturer of endpoint 150 can install a baseline version of firmware 363, which is programmed to allow endpoint 150 to generate and submit identity data 113 for verification by security server 140. The baseline version of firmware 363 is further configured to facilitate firmware updates via firmware store 170 and verification of identity data 113 by security server 140.

[0375] Generally, a firmware update for endpoint 150 may replace the entire firmware 363 executed in host system 120, or add and / or replace one or more firmware applications (e.g., applications 367, ..., 369).

[0376] Endpoint platform 361 can be used to represent a class of endpoint hardware. Each endpoint in the class (e.g., 150) may run different versions of firmware (e.g., 363, ..., 365) to provide different functions and / or services.

[0377] In some implementations, firmware 363 can be customized via one or more firmware applications (e.g., applications 367, ..., 369). For example, endpoint 150 running firmware 363 can further run optional applications (e.g., applications 367, ..., or 369) to provide new features not present in firmware 363, disable existing features in firmware 363, change or customize existing features in firmware 363, and so on.

[0378] For example, when a firmware application (e.g., application 367) runs on firmware 363 in endpoint 150, endpoint 150 is customized to communicate with client server 141 of a service provider to implement services or functions and / or receive services from the service provider. When another firmware application (e.g., application 369) runs on firmware 363 in endpoint 150, endpoint 150 is customized differently to communicate with another client server 143 of a different service provider to implement alternative or similar services or functions and / or receive alternative or similar services from said different service provider.

[0379] For example, a firmware application (e.g., application 367) can be programmed to implement a communication protocol specific to client server 141.

[0380] For example, a firmware application (e.g., application 367) can be programmed to perform new computational functions that generate new types of results.

[0381] For example, a firmware application (e.g., application 367) can be programmed to communicate with client server 141 to obtain services provided via client server 141. Examples of services provided by client server 141 include computing resources for client server 141 to process data from endpoint 150, data storage facilities for client server 141 for data generated by endpoint 150, messaging facilities for notifications and / or warnings to one or more other devices associated with endpoint 150, connections between client server 141 and one or more other devices associated with endpoint 150, internet access for endpoint 150 via Wi-Fi access points, communication satellites, and / or communication connections or devices controlled by client server 141, etc.

[0382] Generally, different service providers can offer different versions of firmware and / or different firmware applications to customize endpoints in the same endpoint platform 361 (e.g., 150). Endpoints in platform 361 may be manufactured and / or assembled by the same manufacturer or different manufacturers.

[0383] Optionally, a baseline version of firmware (e.g., 363) provides a standardized set of functions upon which firmware applications (e.g., applications 367, ..., 369) can run. Therefore, the same firmware application (e.g., application 367) can be installed to customize endpoints (e.g., 150) with different hardware configurations and / or different baseline versions of firmware (e.g., 363, ..., 365). Alternatively, different firmware applications can be programmed for different baseline versions of firmware (e.g., 363, ..., 365) running on endpoints with different hardware implementations to provide the same customized functionality for the respective endpoints and / or the same services for client server 141.

[0384] Using firmware applications (e.g., applications 367, ..., 369) can reduce the amount of data downloaded from firmware store 170 to endpoint 150 when performing a firmware update. Alternatively, different groups of firmware functions can be implemented using different firmware (e.g., 363, ..., 365) without requiring additional firmware applications. Generally, a firmware update in endpoint 150 may involve replacing the entire existing firmware 363 or installing a firmware application (e.g., application 367).

[0385] Optionally, firmware store 170 is configured to allow users of endpoint 150 to select and / or order firmware 371 for customizing endpoint 150 using computer 180. In some cases, the purchase of a selected version of firmware (e.g., 363) and / or firmware application (e.g., 367) represents a request for a service from a service provider and / or client server (e.g., 141). In response, firmware store 170 and / or security server 140 may store data indicating the desired firmware configuration and / or requested service for endpoint 150. For example, client permission data 283 may be updated to reflect firmware and / or service selections made using user computer 180.

[0386] Generally, user computer 180 may be different from and separate from endpoint 150. Therefore, there is no need for hardware and / or software interfaces accessible to users of endpoint 150 to customize endpoint 150 for use with accounts and / or service providers. Optionally, some implementations and / or categories of endpoint 150 may include a user interface that allows it to be used as user computer 180 to order firmware 371 for endpoint 150.

[0387] For example, the owner or user of endpoint 150 can access an online firmware store 170 using user computer 180 to order firmware 371 for endpoint 150 by selecting a firmware application (e.g., application 367), a replacement version of the firmware, or a combination of a replacement version of the firmware and the firmware application. The user's order can be identified as a service subscriber and / or endpoint 150 can be identified as a device to be customized.

[0388] For example, endpoint 150 may be identified by common identifiers of endpoint 150, such as the model and serial number of endpoint 150, mobile device identification number 253, international mobile subscriber identification number 255, unique identifier 111 and / or another identifier contained in data 127 of identity data 113.

[0389] For example, a user or subscriber's identity can be identified via an account identifier and / or a piece of personally identifiable information, such as an email address, phone number, name, and address.

[0390] Security server 140 can verify identity data 113 submitted from endpoint 150 and / or its storage device 130, as described above. Figure 2 , 5 And 9 discussions.

[0391] Generally, identity data 113 can be submitted to security server 140 via client server (e.g., 141 or 143), via firmware store 170, via another server or gateway, or without going through any of client servers 141, ..., 143 and firmware store 170.

[0392] For example, endpoint 150 can be configured via existing firmware 363 to automatically access firmware store 170 and / or security server 140 for authentication, firmware updates, and / or service customization. Therefore, identity data 113 may be submitted to security server 140 via firmware store 170 in some cases, and directly to security server 140 in others.

[0393] For example, when a server (e.g., client server 141 or 143, firmware store 170, or another server) receives identity data 113 from endpoint 150 in request 171, the server (e.g., 141) provides identity data 113 to security server 140 for verification in request 173. In response to such request 173, security server 140 may communicate with firmware store 170 to identify 375 whether a firmware update exists at endpoint 150. If so, security server 140 may instruct firmware store 170 to update the firmware of endpoint 150. For example, after performing a firmware download to store a new version of firmware and / or firmware application (e.g., application 367) in storage device 130, a command 155 signed with encryption key 145 is executed in storage device 130 to cause the new version of firmware and / or firmware application (e.g., application 367) to execute in storage device 130 and become part of the identity of storage device 130 and / or endpoint 150.

[0394] For example, firmware 363 may be initially installed in endpoint 150 (e.g., by the manufacturer of endpoint 150) to provide services via client server 141. After a new version of firmware 363 is made available in firmware store 170 for accessing the same services of client server 141, security server 140 may initiate the installation of the new version in response to successful verification of identity data 113. Optionally, update 377 may be implemented via a firmware application (e.g., application 367) installed on existing firmware 363, or via the installation of new firmware (e.g., 365).

[0395] For example, after a user of firmware 363 visits firmware store 170 to order firmware 365 (an alternative version of firmware 371) to customize endpoint 150, firmware store 170 can update the firmware of endpoint 150 (377) according to order 371 when the identity data 113 of endpoint 150 is successfully verified in security server 140.

[0396] In some cases, endpoint 150 first accesses security server 140. After security server 140 verifies the identity of endpoint 150, it can communicate with online firmware store 170 to identify firmware updates for endpoint 150.

[0397] Generally, a firmware update may involve installing a firmware application (e.g., application 367), replacing an existing firmware application with another firmware application, and / or installing new firmware 365.

[0398] After identifying the required firmware update, firmware store 170 communicates with endpoint 150 to update endpoint 150.

[0399] The access controller of the memory device 130 is configured to require authentication requests for the memory device 130 to execute command 155 to change the permissions of the firmware stored in the memory device 130.

[0400] For example, after the data required for a firmware update is stored in a segment of the storage device 130, command 155 can be sent to host interface 147 to perform a firmware update operation in the storage device 130. The permission to execute command 155 in the storage device 130 can be represented by encryption key 145. Encryption key 145 can be previously configured or generated in response to verifying identity data 113 from the storage device 130 at endpoint 150. For example, encryption key 145 could be based on verifying the authenticity of endpoint 150 in a manner similar to... Figure 9 The session key 263 is generated in a manner that allows the security server 140 to use the encryption key 145 to generate a verification code 153 for the firmware store 170 to update the endpoint 150. Alternatively, the security server 140 may provide the session key 263 and / or the encryption key 145 to the firmware store 170 to update the firmware of the endpoint 150.

[0401] After a successful firmware update, the device information 121 used to generate the secret key 137 is updated to reflect the installed firmware and / or firmware applications. For example, the hash value 163 of the installed firmware and / or firmware applications can be stored as part of the device information 121 for use in verifying their integrity, such as... Figure 4 As shown in the figure. Subsequently, the identity data 113 generated by the memory device 130 of endpoint 150 is based on the updated device information 121 and reflects the configuration of endpoint 150 with updated firmware functions or configuration.

[0402] In some embodiments, firmware store 170 is part of a server system implementing security server 140. In another embodiment, firmware store 170 is hosted on a separate server computer.

[0403] In some implementations, firmware update 377 can be performed automatically based on the service subscribed for endpoint 150, as described below. Figure 15 Further discussion.

[0404] Figure 15This illustrates a technique for directing services to an endpoint via an online service store, according to one embodiment. For example, Figure 15 The technology can be combined with Figure 14 The combination of technologies.

[0405] exist Figure 15 In this context, the online service store 190 is configured to facilitate the selection of a service from one or more services offered by one or more service providers (e.g., 381) for endpoint 150. The service provided by the service provider (e.g., 381) may be implemented via one or more endpoint platforms (e.g., 361, ..., 362).

[0406] For example, a user of endpoint 150 can use computer 180 to access an online service store 190 to order service 391 from service provider 381. The service provided by service provider 381 can be used with endpoints on multiple endpoint platforms (e.g., 361, ..., 362). Endpoints (e.g., 150) on endpoint platforms (e.g., 361, ..., 362) run different firmware to obtain services from service provider 381. Service store 190 has subscription data 387 that identifies the services and / or endpoints (e.g., 150) ordered by the subscriber.

[0407] For example, the services provided by service provider 381 can be implemented via client server 141; and subscription data 387 can identify servers connected to the endpoint to receive services subscribed for the endpoint accordingly.

[0408] For example, services can be explicitly subscribed to for endpoint 150 by referring to the public identifier of endpoint 150, the model and serial number of endpoint 150, the mobile device identification number 253, the international mobile subscriber identification number 255, the unique identifier 111 and / or another identifier contained in the data 127 of the identity data 113.

[0409] Alternatively or in combination, services may be ordered with reference to the identity of the user or subscriber, who may be identified by an account identifier and / or a piece of personally identifiable information, such as an email address, phone number, name, and address.

[0410] As in Figure 14 In this context, user computer 180 is typically different from and separate from endpoint 150. In some cases, endpoint 150 may include a user interface that allows it to function as computer 180 in order to subscribe to services 391 for endpoint 150.

[0411] When a service is implicitly subscribed to for endpoint 150, the subscriber’s identity can be used to determine the service of the endpoint based on the matching of the subscriber’s identity used to subscribe to the service with the identity of the owner of endpoint 150.

[0412] For example, in order to order service 391 from service provider 381, a user (or a representative of the user) at endpoint 150 can access service store 190 to create an account for subscribing to services from service provider 381.

[0413] In response to a service being ordered or changed, or in response to the identity data 113 of endpoint 150 being verified, security server 140 and service store 190 can communicate with each other to identify 393 the service subscribed to by endpoint 150.

[0414] In response to service request 171 from endpoint 150, security server 140 verifies 373 the identity data 113 of endpoint 150 provided in service request 171.

[0415] Generally, service request 171 may be initially received in the client server (e.g., 141 or 143), or in the service store 190 or firmware store 170, or directly in the security server 140.

[0416] After the security server 140 verifies the identity and authenticity of endpoint 150, based on the client permission data 283 stored in the security server 140 and / or the subscription data 387 in the service store 190, the security server 140 can identify 393 as the service subscribed to by endpoint 150.

[0417] Based on the identified service, security server 140 can communicate with firmware store 170 to identify firmware updates for endpoint 150. For example, endpoint 150 can be updated by replacing firmware or installing a firmware application (e.g., application 367) to customize endpoint 150 for the subscribed service. Firmware updates can be combined with the above. Figure 14 The methods discussed are for implementation and protection.

[0418] For example, endpoint 150 may be manufactured using a generic version of firmware 363 that cannot receive services from service provider 381, is unaware of client server 141 regarding the services provided by service provider 381, and / or does not implement the communication protocol used to communicate with client server 141. A firmware application (e.g., application 367) may be installed and run on the generic firmware 363 to customize endpoint 150 for the services ordered for endpoint 150. Once customized via the firmware application (e.g., application 367), endpoint 150 can receive services from service provider 381 from client server 141. For example, after installing the firmware application (e.g., application 367) to update firmware 377, endpoint 150 has knowledge of client server 141, the ability to communicate with client server 141 according to the communication protocol used by client server 141, and processing routines for using the services provided by client server 141.

[0419] For example, the services subscribed for the operation of endpoint 150 may include calculations performed by client server 141 to process data of endpoint 150, storing data generated by endpoint 150 in client server 141, sending notifications and / or warnings to one or more other devices associated with endpoint 150, connecting endpoint 150 to a computer network or the Internet via client server 141 and one or more other devices associated with endpoint 150, using cellular base stations, Wi-Fi access points, communication satellites and / or communication connections or devices controlled by client server 141, etc.

[0420] Optionally, after firmware update 377, endpoint 150 is configured via its firmware 363 and / or firmware application (e.g., application 367) to automatically access client server 141 to obtain subscribed services. Alternatively, security server 140 may redirect endpoint 150 to client server 141 to access subscribed services 379 after verifying the identity data 113 of endpoint 150 with updated firmware.

[0421] Generally, the service store 190 is available for users (or their representatives) to subscribe to services of service provider 381 for endpoint 150, change the subscribed services, and move the subscription from one service provider 381 to another. The firmware 363 of endpoint 150 is automatically updated to support the currently subscribed services without requiring users of endpoint 150 to customize endpoint 150 for the subscribed services.

[0422] Figure 16 A firmware update method using a firmware store and a security server is illustrated according to one embodiment. For example, Figure 16 The method can be used Figure 14 Technical implementation.

[0423] At box 401, the server system receives a request from endpoint 150 containing identity data 113 generated by a memory device 130 configured in endpoint 150.

[0424] For example, the server system may include a security server 140. Optionally, the server system may further include an online firmware store 170 and / or one or more client servers (e.g., 141, ..., 143).

[0425] For example, endpoint 150 may be in a state of being shipped from the endpoint (e.g., 150) manufacturer without needing to be customized for a specific server and / or service provider.

[0426] At box 403, the server system responds to the request received in box 401 and determines the authenticity of endpoint 150 based on the secret and identity data 113 of memory device 130. For example, the operation in box 403 can be performed in a manner similar to the operations performed in boxes 323 and / or 343.

[0427] For example, identity data 113 includes a verification code 133 in the message 131 presented within identity data 113. Security server 140 can verify that verification code 133 was generated using a secret key 137 from memory device 130 and message 131, without the endpoint presenting the secret key 137. Secret key 137 is generated using a unique device secret 101 from memory device 130 and device information 121 representing the software and hardware configuration of endpoint 150.

[0428] At box 405, an update for the first firmware 363 is determined based on the online firmware store 170. The first firmware is stored in the memory device 130 and executed at endpoint 150 to generate the request received in box 401.

[0429] For example, before receiving a request in box 401, firmware store 170 may receive firmware order 391 for endpoint 150. Order 391 can be made to customize the functionality of endpoint 150 using user computer 180 without going through endpoint 150. Order 391 received in firmware store 170 can be used to identify update 377.

[0430] For example, the public identifier of endpoint 150 can be used to identify order 391 of endpoint 150. Identity data 113 may contain the public identifier in message 131 signed using secret key 137 to generate a verification code 133 provided in identity data 113. After verification message 131 has not been changed, security server 140 may instruct online firmware store 170 and / or endpoint 150 to update firmware 363 of endpoint 150.

[0431] At box 407, in response to determining that endpoint 150 is real, the server system generates a verification code 153 for command 155 that can be executed in storage device 130 to perform the update.

[0432] At box 409, the server system provides a verification code 153 to execute command 155 in memory device 130 for firmware update.

[0433] For example, in response to determining that the endpoint is authentic, the security server 140 may communicate with the online firmware store 170 to download data to the storage device 130. When command 155 is executed in the storage device 130, the storage device 130 uses the data to perform a firmware update.

[0434] For example, the data downloaded to the memory device 130 may include a second firmware that replaces the first firmware, which was executed to generate the request received in block 401, after command 155 is executed to perform a firmware update.

[0435] For example, the data downloaded to memory device 130 may include a firmware application (e.g., application 367), which runs using the first firmware executed to generate the request after command 155 is executed to perform a firmware update. The combination of the firmware application (e.g., application 367) and the first firmware provides the second firmware for endpoint 150.

[0436] For example, after executing command 155 to perform a firmware update, endpoint 150 is configured via the second firmware to provide functionality that was not available in the endpoint running the first firmware prior to the update.

[0437] After executing command 155 to perform a firmware update, the second firmware can become part of the identity of memory device 130 and endpoint 150. For example, based on device information 121, memory device 130 is configured to generate a secret key 137 representing the identity of memory device 130 and endpoint 150. After executing command 155 to update firmware 377, device information 121 is updated to include a hash value 163 of the second firmware stored as content 161 in memory cell 103. Subsequently, memory device 130 is configured to generate identity data 113 of endpoint 150 using an encryption key generated at least in part based on the secret of the memory device (e.g., a unique device secret 101) and the second firmware stored in memory device 130.

[0438] Figure 17 This illustrates an endpoint customization method using a service store and a security server according to one embodiment. For example, Figure 17 The method can be used Figure 14 and Figure 15 Technical implementation.

[0439] At box 421, the server system receives a request from endpoint 150 containing identity data 113 generated by a memory device 130 configured in endpoint 150, similar to box 401.

[0440] For example, a server system may include a security server 140 and / or a service store 190.

[0441] At box 423, security server 140 responds to the request received in box 421 and verifies identity data 113 based on information about endpoint 150 stored in security server 140. This information includes a secret of storage device 130, such as a unique device secret 101. This information may further include device information 121 representing the software / hardware configuration of endpoint 150. Verification can be performed in combination with the above. Figure 2 The methods described are implemented.

[0442] In response to confirming that the identity data 113 received in box 421 is valid, at box 425, the server system identifies the service ordered for endpoint 150 in online service store 190.

[0443] At box 427, identify the client server 141 configured to provide services.

[0444] For example, before receiving a request in box 421, online service store 190 may receive an order 391 for services from endpoint 150. Client server 141 may identify itself based on order 391.

[0445] For example, order 391 may be received in online service store 190 via user computer 180 and therefore without going through endpoint 150. Order 391 at endpoint 150 can be identified / placed using the public identifier of endpoint 150. Identity data 113 may contain the public identifier. Alternatively, order 391 may be associated with the identity of the user who is the owner of endpoint 150 in client permissions data 283 on the security server.

[0446] At box 429, the server system directs endpoint 150 to client server 141.

[0447] For example, in response to determining that the identity data 113 in the request received in box 421 is valid, the server system can configure endpoint 150 for the service ordered in the online service store 190.

[0448] For example, to configure endpoint 150 for a service, the server system can update the firmware of endpoint 150. For example, firmware updates can be combined with the above. Figures 14 to 16 The methods described are implemented.

[0449] For example, prior to firmware update 377, endpoint 150 could not receive services from client server 141 and had no knowledge of client server 141. For example, endpoint 150 was initially configured by the manufacturer of endpoint (e.g., 150) to access service store 190, firmware store 170, security server 140, or another gatekeeper, so that endpoint 150 could be properly configured and / or updated for use without requiring end-user customization of endpoint 150 operation.

[0450] For example, after firmware update 377, a second firmware is stored in memory device 130 to replace the first firmware used to generate the request received in block 421. When endpoint 150 runs the second firmware, the endpoint has functionality that was not present in the endpoint running the first firmware prior to firmware update 377. For example, the second firmware may include identification of client server 141 to direct the endpoint to access client server 141 to obtain services ordered in online service store 190. In one embodiment, the second firmware is a combination of the first firmware and an added firmware application. After firmware update 377, memory device 130 is configured to generate updated identity data 113 for endpoint 150 using secret key 137, which is generated at least in part based on a secret (e.g., unique device secret 101) and the second firmware stored in memory device 130.

[0451] Optionally, in order to configure endpoint 150 for services ordered in service store 190, the server system identifies the account used to subscribe to the service for endpoint 150. Storage device 130 is configured to store the account identifier, and the identifier is included as part of message 131 in the updated identity data 113.

[0452] For example, to perform firmware update 377, the server system can use an encryption key 145 representing the permission to execute command 155 in memory device 130 to generate a verification code 153 for command 155. When executed in memory device 130, command 155 replaces the first firmware with the second firmware. After receiving command 155 and verification code 153, memory device 130 verifies the verification code 153 for the permission before executing command 155.

[0453] The security server 140 can be used not only to verify the identity of endpoint 150 based on the security features of the storage device 130 configured in endpoint 150, but also to monitor the integrity of packets stored in storage device 130 and / or endpoint 150. For example, packets stored in endpoint 150 may be bootloaders, firmware, software, modules, at least a portion of an operating system or application, a set of files specifying resources, configuration parameters and / or other data of programs or routines, etc. When a packet is found to be corrupted, modified, tampered with, or outdated, the security server 140 may initiate an over-the-air (OTA) update to maintain the integrity of endpoint 150.

[0454] The memory device 130 can store content 161 in memory cell 103 and separately store hash value 163 as part of device information 121, such as Figure 4As shown. When the current hash value calculated based on the content 161 stored in the memory unit 103 does not match the expected hash value 163 stored as part of the device information 121, the memory device 130 can detect the modification or corruption of the content 161 and initiate content repair.

[0455] For example, content 161 may contain the core packet of endpoint 150. The integrity of the core packet can affect the operation of endpoint 150 when communicating with the security server 140 during the authentication of endpoint 150. An instance of the core packet may contain at least a portion of the endpoint 150's bootloader, firmware, and / or operating system. When the core packet is modified, corrupted, or tampered with, the security of the operations performed by endpoint 150 for authentication may be compromised. When an integrity state 165 generated by the encryption engine 107 indicates a change to the core packet, the access controller 109 may prevent the host system 120 from accessing content 161 until the core packet is repaired.

[0456] For example, storage device 130 may store a reliable backup copy of the core package in a separate segment; and when the hash value of the core package in content 161 stored in storage unit 103 differs from the corresponding hash value 163 of stored device information 121, storage device 130 may use the copy stored in the separate segment to replace the core package stored in storage unit 103. Optionally, the execution of the replacement copy in endpoint 150 may be configured to initiate a recovery process to obtain the latest version of the package from a reliable source (e.g., firmware store 170). Alternatively, security server 140 may initiate an update (e.g., using firmware store 170) after verifying the identity data 113 of storage device 130 and / or endpoint 150 submitted via the replacement copy.

[0457] Some packets stored in memory unit 103 do not affect the security of the initial operation of verifying the identity data 113 of endpoint 150 or subsequent operations of updating endpoint 150. Therefore, it is not necessary to store a restored copy of such packets in memory device 130. Repair and / or updates of such packets can be performed via security server 140. For example, when integrity status 165 indicates that a non-core packet has been changed, access controller 109 can prevent host system 120 from accessing the corrupted or altered packet until endpoint 150 communicates with security server 140 to repair or restore the corrupted packet.

[0458] Optionally, the data 127 provided in identity data 113 may include the current hash value of the packet in content 161 stored in memory unit 103. During the operation of verifying identity data 113 at endpoint 150, security server 140 may check the current hash value of the packet provided in identity data 113. If the current hash value of the packet indicates that the packet has been altered, corrupted, or outdated, then security server 140 may initiate packet repair or recovery.

[0459] Furthermore, some packets from endpoint 150 may be stored on another device that does not have the security features of storage device 130. Executing the core packet in host system 120 can generate the current hash value of the packet as a health indicator. The health indicator may be provided as part of data 127 embedded in identity data 113 of endpoint 150 to allow security server 140 to monitor packet integrity.

[0460] Generally, identity data 113 may contain data indicating the health status of packets in endpoint 150. As part of the operation of verifying identity data 113 of endpoint 150, security server 140 may determine whether any packets need to be repaired and / or updated. Repair or update may be performed before security server 140 confirms the authenticity of endpoint 150.

[0461] In addition, in response to the service of verifying the identity data 113 of endpoint 150 to access client servers (e.g., 141, ..., 143), security server 140 may be configured to track and / or monitor the activity of endpoint 150 when accessing the service to implement further security operations.

[0462] For example, the owner or user of endpoint 150 may request security server 140 to track the activity of endpoint 150. Aspects of the activity of endpoint 150 may be presented by endpoint 150 and / or client servers (e.g., 141, ..., 143) in identity data 113 and / or request 173 to verify identity data 113.

[0463] For example, information about the tracked activity may include the location information of endpoint 150 and / or the type of service requested by endpoint 150 via submitting identity data 113.

[0464] For example, in order to generate identity data 113 from the service of client server 141, endpoint 150 may include not only the unique identifier 111 of endpoint 150 in the message 131 of identity data 113, but also the context and / or aspects of the service, such as the identification of client server 141, the location of endpoint 150, the date and time of the request, the category / type of the service, the parameters of the service, etc.

[0465] For example, when endpoint 150 sends a service request 171 to client server 141, client server 141 may provide security server 140 with not only endpoint 150's identity data 113, but also information about the service request 171 to client server 141 in the request.

[0466] For example, in response to a request 171 from endpoint 150, client server 141 may estimate the location of endpoint 150 based on wireless communication connections to one or more access points connected to client server 141, and provide the location and request 173 to security server 140 to authenticate identity data 113.

[0467] Optionally, the owner or user of endpoint 150 can access the portal of security server 140 to view the tracked activity. For example, based on the tracked activity, the owner or user can determine whether endpoint 150 has been stolen or lost based on one or more of its most recent locations.

[0468] Optionally, parents can use the portal of security server 140 to set parental control preferences to restrict the activity of endpoint 150; and security server 140 can enforce restriction preferences in conjunction with the identity of authentication endpoint 150.

[0469] Figure 18 The illustration shows the generation of identity data according to one embodiment to facilitate the monitoring of integrity and / or endpoint activity.

[0470] For example, Figure 18 The technology can be used to have information about Figures 1 to 5 The discussion of security services and features Figure 1 and / or Figure 6 The computing system. Figure 18 The technology can be combined with Figures 9 to 17 The combination of technologies.

[0471] exist Figure 18 In this context, endpoint 150 stores packet 167 with hash value 169. Packet 167 may be stored in memory device 130 having the security features discussed above, or in another memory device of endpoint 150 that may or may not have the security features of memory device 130. When packet 167 is stored in memory device 130, the encryption engine 107 of memory device 130 can calculate the hash value 169 of packet 167 without relying on the processing device 118 of host system 120 in endpoint 150. When packet 167 is stored outside of memory device 130, the hash value 169 can be processed by the processing device 118 of host system 120. The hash value 169 is stored in memory device 130 and has been verified not to have been changed (e.g., as...). Figure 4 The routines in the middle are used to obtain it.

[0472] Generally, packet 167 may contain instructions and / or data, such as the same resource for a set of endpoints (e.g., 150) and different configuration parameters for different endpoints (e.g., 150).

[0473] The hash value 169 of packet 167 indicates the health status of packet 167.

[0474] exist Figure 18 In the message 131, the secret key 137 used to generate the verification code 133 for identity data 113 is independent of the hash value 169 of packet 167. To facilitate the security server 140's monitoring of the integrity of packet 167, the hash value 169 is provided as part of message 131 in the identity data 113.

[0475] After the security server 140 determines that the identity data 113 is valid, the security server 140 may extract the hash value 169 provided in the identity data 113 to determine whether the packet 167 in the endpoint 150 has been changed and / or whether the packet 167 is outdated.

[0476] For example, a healthy and up-to-date copy of packet 167 can be stored on a server (e.g., security server 140, firmware store 170, or another server) to facilitate the repair or recovery of packet 167 in endpoint 150. If the hash value 169 extracted from identity data 113 differs from the hash value of the healthy and up-to-date copy, then security server 140 can similarly combine... Figures 14 to 17 The update is initiated in the manner described in firmware update 377 of endpoint 150 363.

[0477] Package 167 can be individualized for endpoint 150. For example, when package 167 contains configuration parameters specific to endpoint 150 in platform 361 but not applicable to other endpoints in platform 361, a healthy copy of package 167 can be uploaded to a server (e.g., security server 140, firmware store 170, or another server) immediately after package 167 in endpoint 150 is successfully configured.

[0478] In some implementations, memory device 130 and / or endpoint 150 may be configured to store a hash value of a health-individualized copy of packet 167. For example, the health hash value may be stored as part of device information 121 used to create secret key 137. Message 131 in identity data 113 may contain an indication of whether the current packet 167 is healthy, but does not have the current hash value 169 of packet 167.

[0479] To improve security and / or privacy, a healthy copy of the personalized package 167 can be uploaded and stored in encrypted form on a server using the encryption key of the storage device 130. To reinstall the package 167 using the healthy copy, the storage device 130 decrypts the encrypted version using its corresponding secret encryption key.

[0480] For example, after successfully configuring the individualized packet 167 in endpoint 150, endpoint 150 and / or storage device 130 may calculate the hash value of a healthy copy of individualized packet 167 and encrypt individualized packet 167 using public key 139. Endpoint 150 may submit the hash value and encrypted packet 167 for storage in a server, thereby facilitating monitoring and / or recovery. During recovery, the secret key 137 in key pair 135 will be used to decrypt the encrypted packet. Optionally, encryption engine 107 may generate a separate key pair to protect individualized packet 167.

[0481] Alternatively, the secret key can be used in conjunction with symmetric encryption to protect the individual package 167. For example, a session key 263 generated during the verification of the identity data 113 of endpoint 150 when the individual package 167 is successfully configured in endpoint 150 can be used to encrypt the individual package 167 for transmission to and / or storage on a server (e.g., security server 140, firmware store 170, or another server).

[0482] exist Figure 18 In this context, identity data 113 contains not only the current hash value 169 of packet 167, but also activity information 177 that identifies aspects of the context in which identity data 113 is used. For example, activity information 177 may be generated by the host system 120 executing or running a packet (e.g., 167 or another packet, such as firmware, application, routine).

[0483] For example, activity information 177 may include the current location of endpoint 150, in which identity data 113 is generated.

[0484] For example, activity information 177 may include the date and time of generation of identity data 113.

[0485] For example, activity information 177 may include the identification of a client server 141 that submitted identity data 113 to request service 171.

[0486] For example, activity information 177 may include one or more attributes of the requested service, such as the type of service, the identification of the other party involved in the service, the quantity or amount involved in the service, etc.

[0487] For example, when submitting identity data 113 to establish a communication connection, the attributes may include identification of the connection type, connection identifier, etc.

[0488] For example, when submitting identity data 113 to make a payment, attributes may include identification of the purchase category, the payee, the payment amount, etc.

[0489] Activity information 177 is available to security server 140 for detecting fraudulent activity, unauthorized use of endpoints, and enforcing activity restrictions (e.g., as specified in parental control preferences), etc.

[0490] To improve security and / or privacy, activity information 177 may be included in message 131 in encrypted form. For example, session key 263 associated with the verification of identity data 113 may be used to generate ciphertext of activity information 177; and after successful verification of the verification code 133 of identity data 113, security server 140 may use session key 263 to recover activity information 177 from the ciphertext.

[0491] Figure 19 This illustrates a technique for maintaining the integrity of packets stored in an endpoint, according to one embodiment.

[0492] exist Figure 19 In the process, endpoint 150 stores multiple packets 441, 443, ..., 445. Some packets are stored in a security-enabled memory device 130. Some packets may be stored outside the memory device 130.

[0493] The core packet 441, stored in the memory device 130, can be executed in the processing unit 118 of the host system 120 connected to the memory device 130 in the endpoint 150. Packet 441 controls the endpoint 150's operations when submitting its identity data 113 to the security server 140 and when communicating with the packet repository 191 to repair and / or update packets 441, 443, ..., 445. For example, the packet repository 191 may contain... Figure 14 and 15 Firmware store 170.

[0494] The security features of memory device 130 ensure that endpoint 150 runs a valid version of packet 441 to prevent tampering and / or damage during the verification of endpoint 150's identity and the repair of packet 385.

[0495] For example, storage device 130 may store a backup version of core package 441 in a secure segment of storage device 130. If package 441 is found to have been changed, storage device 130 may replace the changed version of package 441 with the backup version to at least protect the identity of authentication endpoint 150 373 and the operation of repairing 385 and / or updating 377 packages.

[0496] After endpoint 150 generates identity data 113, endpoint 150 of execution packet 441 transmits identity data 113 to security server 140 for verification 373. For example, identity data 113 can use... Figure 18 The technology generated.

[0497] Identity data 113 may include packet health information 447, such as the current hash value of packets 441, 443, ..., 445, and / or an indication of whether any of packets 443, ..., 445 is corrupt based on comparing the current hash value of the health version of the corresponding packet with the stored hash value.

[0498] Optionally, a portion of message 131 may be provided using ciphertext generated using session key 263. For example, the encrypted portion of the message may contain packet health information 447 and / or activity information 177. Session key 263 may be related to... Figure 9 The method described generates data to be shared between storage device 130 and security server, and is used to verify the identity of endpoint 150.

[0499] Generally, identity data 113 can be transmitted directly via a communication connection or indirectly via an intermediate server (e.g., Figure 5 , 9 Or client server 141 in 10, Figure 14 Or firmware store 170 in 15, Figure 15 Service store 190 or Figure 19 The package repository 191 is transferred from endpoint 150 to security server 140.

[0500] After verifying identity data 113, security server 140 can communicate with packet repository 191 to check the integrity of packets 441, 443, ..., 445 based on packet health information 447 provided in identity data 113.

[0501] For example, package 441 may be valid in endpoint 150. However, because a newer version of package 441 has been released in package repository 191, package 441 may be obsolete. Therefore, updating package 441 can improve the security of endpoint 150's operation and the integrity of the system.

[0502] For example, package 443 or 445 may have been altered in endpoint 150 and thus corrupted. The health data 195 of the corresponding package 193 in repository 191 can be compared with the package health information 447 provided in identity data 113 to detect the alteration.

[0503] If a package (e.g., 441, 443, ..., 445) is found to be outdated or corrupt, the security server 140 may instruct the endpoint 150 and / or the package repository 191 to repair package 385 or update package 377.

[0504] The operation of repairing packet 385 or updating packet 377 may include security server 140 generating a verification code 153 for command 155 to write data into storage device 130. When the packet contains sensitive information (e.g., configuration parameters customized for endpoint 150), the replacement packet may be provided to storage device 130 using ciphertext generated using session key 263 or another secret key.

[0505] After fixing 385 or updating 377, endpoint 150 can submit updated identity data 113. When security server 140 determines that identity data 113 is valid and that packet health information 447 in identity data 113 indicates that packets 441, 443, ..., 445 in endpoint 150 are healthy and up-to-date, security server 140 can authenticate the authenticity of endpoint 150.

[0506] Figure 20 A system is shown that implements security operations based on tracking endpoint activity, according to one embodiment.

[0507] For example, Figure 20 Safe operation can be achieved by combining Figures 1 to 5 The discussion of the security features of memory devices combined with Figure 9 , 10 The techniques of 14, 15 and / or 19 combined with Figure 1 And / or 6 system implementation.

[0508] exist Figure 20 In this context, the user computer 180 can access the activity tracker 451 to set preferences 455 and / or check the tracked activity records 453 of the endpoint 150 with a unique identifier 111.

[0509] As in Figure 14 and 15 In this context, the user computer 180 is typically different from and separate from the endpoint 150. In some cases, the endpoint 150 may include a user interface that allows it to function as the computer 180 to set preferences 455 and / or check activity logs 453.

[0510] Activity tracker 451 is coupled to security server 140 to store activity records 453 about the activities of endpoint 150, wherein the identity data 113 of endpoint 150 is verified by security server 140.

[0511] Preference 455 may include security settings for the activities of endpoint 150. For example, security settings can be used to implement parental controls, detect fraudulent use of endpoint 150, track the location of endpoint 150, and so on.

[0512] For example, reference 455 can identify the geographic region of endpoint 150. When endpoint 150 sends identity data 113 from a location outside the geographic region, activity tracker 451 can generate a security alert to the registered owner or user of endpoint 150.

[0513] For example, security alerts can be transmitted to the owner's or user's mobile device, email address or phone number identified in preferences, and / or to applications running on the user's computer, personal media player, mobile phone, smartphone, etc.

[0514] For example, preference 455 may contain a user-selected option associated with predetermined conditions specified in preference 455. When the activity associated with the submission of identity data 113 meets the conditions, the selected option causes security server 140 and / or client server 141 to generate an access rejection response 172 for the corresponding access request 171. Alternatively or in combination, the option may trigger a security alert for a contact registered in preference 455.

[0515] Endpoint 150 may transmit access request 171 to client server 141 to request a service. For example, the service may provide endpoint 150 with cellular communication connectivity, internet connectivity, connectivity to user computer 180, online storage facilities, online computing resources, etc. For example, the service may include processing of payments, transactions, messages, etc.

[0516] The identity data 113 provided in access request 171 may include activity information 177, such as... Figure 18 As shown in the diagram. Alternatively or in combination, client server 141 may provide similar or separate activity information in the authentication request 173 transmitted to security server 140. For example, client server 141 may specify access attribute 449 in authentication request 173. Access attribute 449 identifies certain aspects of the current activity of endpoint 150, in which the identity of endpoint 150 will be authenticated by security server 140. Client server 141 transmits authentication request 173 to security server 140, which verifies identity data 113 to determine the authenticity of endpoint 150's identity.

[0517] After verifying the identity data 113 provided in the verification request 173, the security server 140 may generate an activity record 453 for the activity tracker 451. The activity record 453 may contain activity information 177 extracted from the identity data 113 and / or access attributes 449 of the current activity of the endpoint 150 extracted from the verification request 173.

[0518] Based on activity record 453, activity tracker 451 determines whether the current activity meets any of the conditions specified in preference 455. If the conditions in preference 455 are met, then activity tracker 451 may perform a safety operation to implement the selection scheme selected for said conditions.

[0519] For example, security operations may include notifications to the registered owner or user of endpoint 150.

[0520] For example, a security operation may include instructing the security server 140 to provide a verification response 174 indicating security restrictions, security issues, unauthorized use of endpoint 150, etc.

[0521] Optionally, the activity tracker 451 can identify the activity pattern of the endpoint 150 based on the records 453 of past activities.

[0522] For example, a pattern may include the geographic region or area in which endpoint 150 has previously operated. For example, a pattern may include a time period of a day or week in which endpoint 150 has not previously been active. For example, a pattern may include the range of access attribute 449 of past activity of endpoint 150.

[0523] When the current activity deviates from the pattern, the activity tracker 451 may generate a notification and optionally cause the security server 140 and / or the client server 141 to deny the access request 171.

[0524] Optionally, the security server 140 may examine the activity information 177 provided in the identity data 113 to detect security risks.

[0525] For example, the date and time and / or location specified in activity information 177 can be compared with the corresponding information in access attribute 449 to detect a mismatch. A mismatch could be an indication that stolen identity data 113 has been used or that endpoint 150 has been tampered with or operated insecurely.

[0526] Figure 21 A method for updating or repairing packets stored in an endpoint is illustrated according to one embodiment. For example, Figure 21 The method can be used Figure 18 and 19 Technical implementation.

[0527] At box 461, the server system receives identity data 113 generated by the memory device 130 configured in endpoint 150 from endpoint 150.

[0528] For example, a server system may include a secure server 140 for storing storage devices (e.g., 130) and / or the secrets of other servers, such as a package repository 191, a firmware store 170, and / or another server.

[0529] At box 463, security server 140 verifies identity data based on information about endpoint 150 stored in security server 140 (including the secret of memory device 130).

[0530] For example, the operation in box 463 can be performed in a manner similar to the operations performed in boxes 323, 343, 403 and / or 423.

[0531] At box 465, security server 140 extracts health information 447 from the verified identity data 113 stored in endpoint 150 for packets (e.g., 167, 441, 443, ..., 445).

[0532] For example, health information 447 may include the current hash value 169 of packet 167 stored in endpoint 150. Security server 140 may compare the current hash value 169 extracted from identity data 113 with the hash value of the latest version of packet 167 of health stored in server system (e.g., repository 191, firmware store 170).

[0533] For example, receiving identity data in box 461 could be the result of endpoint 150 executing packet 167 stored in endpoint 150. Packet 167 may contain firmware 363 or at least a portion of the operating system of endpoint 150. Health information 447 can be used to determine whether packet 167 is outdated.

[0534] In another instance, receiving the identity data in box 461 could be the result of endpoint 150 executing a first packet 441 stored in endpoint 150. The first packet 441 may contain firmware 363 or at least a portion of the operating system of endpoint 150. Health information 447 can be used to determine whether a second packet (e.g., 443 or 445) is outdated, corrupted, or altered.

[0535] When the second package (e.g., 443 or 445) contains data customized for endpoint 150, the server system can obtain a copy of the second package (e.g., 443 or 445) from when the second package (e.g., 443 or 445) was successfully configured in endpoint 150. For example, the second package (e.g., 443 or 445) may contain one or more configuration parameters of endpoint 150. In response to the successful configuration of the second package (e.g., 443 or 445), the server system can receive a healthy version of the second package (e.g., 443 or 445) from endpoint 150. Subsequently, if the health information 447 extracted at box 465 indicates that the second package (e.g., 443 or 445) needs to be repaired, the healthy version stored in repository 191 can be used.

[0536] In some implementations, extracting health information 447 from identity data 113 involves decrypting a portion of message 131 provided in identity data 113 (e.g., using session key 263).

[0537] Identity data 113 includes a first verification code 133. Security server 140 verifies identity data 113 by determining whether the first verification code 133 was generated from message 131 and a secret of storage device 130. For example, the secret could be a unique device secret 101 and / or a secret key 137 for storage device 130. After storage device 130 is assembled into endpoint 150, the secret of storage device 130 is not transmitted outside of storage device 130.

[0538] At box 467, based at least in part on health information 447, security server 140 determines that the packet stored in endpoint 150 needs to be updated or repaired.

[0539] At box 469, security server 140 initiates an operation to perform an update or repair of a packet stored in endpoint 150.

[0540] For example, in order to replace or repair a packet stored in storage device 130, security server 140 generates a second verification code 153 for command 155 using an encryption key that represents the authority to execute command 155 in storage device 130. For example, when executed in storage device 130, command 155 causes the packet (e.g., 441 or 443) in storage device 130 to be replaced.

[0541] In some implementations, to repair package 445 stored outside of memory device 130, a replacement for package 445 is initially stored in memory device 130. After the memory device verifies the integrity of the replacement, package 445 can be replaced by executing instructions in package 441 loaded from memory device 130. Optionally, a second verification code 153 can be generated to write the replacement into memory device 130 and / or allow the repair or replacement of package 445 to be performed.

[0542] Figure 22 This illustrates a method for performing security operations based on one or more endpoint-based activities according to one embodiment. For example, Figure 22 The method can be used Figure 18 and 20 Technical implementation.

[0543] At box 481, the server system stores data representing one or more preferences 455 of endpoint 150.

[0544] For example, a server system may include a secure server 140 for storing the secrets of storage devices (e.g., 130) and / or other servers, such as an activity tracker 451, a package repository 191, a firmware store 170, and / or another server.

[0545] At box 483, the server system receives a verification request 173 containing identity data 113 generated by a memory device 130 configured in endpoint 150.

[0546] At box 485, the server system determines the validity of identity data 113 based at least in part on the secret of the memory device.

[0547] For example, the operation in box 485 can be performed in a manner similar to the operations performed in boxes 323, 343, 403, 423 and / or 463.

[0548] At box 487, the server system determines that the activity associated with identity data 113 meets the conditions specified for endpoint 150.

[0549] For example, the condition can be specified in preference 455 of endpoint 150.

[0550] At box 489, when providing verification response 174 in response to verification request 173, the server system performs a security operation associated with the condition.

[0551] For example, security operations may include transmitting warnings or notifications to contacts registered in one or more references 455.

[0552] For example, the security operation may include identifying security risks or limitations in the verification response 174. Optionally, given the secret key 137 of the memory device 130 and the message 131 provided in the identity data 113, the security server 140 may provide a verification response 174 that does not confirm the authenticity of the endpoint 150 even if the identity data 113 has a valid verification code 133. When the activity associated with the identity data 113 meets the conditions, the verification response 174 may be configured to cause the client server to reject the request 171 for services from the endpoint 150 identified by the identity data 113.

[0553] Conditions can be evaluated for activities based on activity information 177 embedded in identity data 113 in memory device 130 and / or access attributes 449 provided by client server 141 in verification request 173.

[0554] For example, after security server 140 determines that verification code 133 in identity data 113 is valid, security server 140 trusts that activity information 177 embedded in identity data 113 has not changed since memory device 130 generated verification code 133. Therefore, activity information 177 can be extracted from identity data 113 to evaluate conditions. Optionally, activity information 177 can be provided in encrypted form in a message, the encrypted form being used to... Figure 9 The session key 263 generated in the manner described herein or another secret encryption key of the memory device 130 is used for decryption.

[0555] Alternatively or in combination, security server 140 may extract access attribute 449 from authentication request 173. For example, after client server 141 receives access request 171 for a service provided by client server 141, client server 141 may generate authentication request 173 to security server 140. Authentication request 173 is generated to include identity data 113 from access request 171. Furthermore, in the context of requesting a service from client server 141, client server 141 may add access attribute 449 to provide information about the activity of endpoint 150.

[0556] For example, the conditions may include a mismatch between activity information 177 and access attribute 449; and the mismatch may trigger the rejection of access request 171 and / or the rejection of identity data 113 in the verification response 174, even if identity data 113 has a valid verification code 133.

[0557] In some implementations, the server system communicates with the user computer 180 to receive data representing one or more preferences 455 of the endpoint 150.

[0558] Alternatively or in combination, the server system can infer preferences 455 from records of past activities 453.

[0559] For example, the server system's activity tracker 451 can store multiple records 453 of the activity of endpoint 150. Based on the multiple records 453, the activity tracker 451 can determine the activity pattern of endpoint 150. The pattern can include a geographic region, a time period of day or week, or a range of activity attributes, or any combination thereof. The conditions for the safe operation of trigger box 489 can be met by activities deviating from the pattern.

[0560] Optionally, activity tracker 451 can present the activity of endpoint 150 to the owner or authorized user of endpoint 150 based on records 453. For example, based on a review of past activity, the owner or authorized user can specify conditions for implementing parental controls, access restrictions, etc.

[0561] The identity of endpoint 150, authenticated by security server 140, can be dynamically associated with a subscription account represented by an account identifier to receive services provided to the account by client server 141. When endpoint 150 is not using the service, the association between endpoint 150's identity and the subscription account can be removed to allow another endpoint to use the subscription account. Therefore, a group of endpoints (e.g., 150) can be configured to share a subscription account and use the subscription account one at a time.

[0562] For example, a group of endpoints can be configured to use the services of client server 141 for cellular connectivity. Traditionally, a Subscriber Identity Module (SIM) card would be used to represent a subscriber / subscription account. This group of endpoints can use the subscription account represented by the SIM card by physically installing the SIM card in one endpoint at a time within the group. In order for another endpoint in the group to use the subscription account, the SIM card will be physically moved from one endpoint to the other.

[0563] As mentioned above Figure 6 The system described allows the use of a virtual subscriber identification module (vSIM) to register via a virtual card 237 and attach to an endpoint (e.g., 150) based on authentication performed using a security server 140 or endpoint authentication 239. Figure 6 The system can be further configured to deassociate an endpoint (e.g., 150) with a card profile 219 representing a subscription account, such that virtual card registration 237 can be performed for another endpoint to use the subscription account.

[0564] For example, a subscription service (e.g., cellular connectivity) provided to a subscription account can be shared among a group of endpoints owned by a business (or another entity). These endpoints (e.g., 150) may not simultaneously require the account's services. Therefore, it may be advantageous to configure the endpoints in this group to share one or more subscription accounts. When more than one subscription account is configured to be shared by a group of endpoints (e.g., Internet of Things (IoT) devices), a small subset of these endpoints can simultaneously use the subscription account's services.

[0565] For example, a server system can be configured to track the current usage status of endpoints within a group. When an endpoint communicates with a client server to request a service, it can dynamically bind to a subscription account. When an endpoint is no longer using the service, the subscription account can be released from that endpoint. When the number of endpoints using the service provided to a subscription account is greater than the number of subscription accounts that can share the service, endpoints in action can simultaneously use the account's service. When a subscription account is currently bound to and used by a part of the group, a request for the service from another endpoint can be rejected until one of the subscription accounts becomes unused and thus available for sharing.

[0566] For example, in response to a request for cellular connectivity from an IoT device within an enterprise, a Virtual Subscriber Identity Module (vSIM) can be attached to the IoT device. If the cellular connection remains idle for an extended period exceeding a threshold, it can be disconnected; and the vSIM can be released from the IoT device and used to attach to another IoT device within the enterprise. Therefore, an enterprise can subscribe to a reduced number of vSIMs; and while all of these vSIMs are in use, a cellular connectivity request from another device can remain in a hold state until one of the connections is lost and the vSIM is released for allocation to the holding device.

[0567] Optionally, the security server 140 may be configured to suppress and / or schedule the forwarding of connection requests to manage the use of a limited number of subscribed cellular connections.

[0568] Figure 23 and 24 A system configured to implement subscription sharing among a set of endpoints is shown according to one embodiment.

[0569] exist Figure 23 and 24 In the middle, service store 190 has subscription data 387 that associates endpoint group 501 with subscriber group 503.

[0570] Endpoint group 501 has a plurality of unique identifiers 111, ..., 112. Each of the unique identifiers (e.g., 111) represents a memory device (e.g., 130) installed in a corresponding endpoint (e.g., 150) in the group of endpoints.

[0571] Subscriber group 503 has one or more subscriber identification numbers (e.g., 505). Each subscriber identification number (e.g., 505) in subscriber group 503 represents a subscriber to the service of client server 141. For example, each subscriber identification number (e.g., 505) can be used to identify a unique subscription account used by one subscriber at a time.

[0572] For example, subscriber identification number 505 can be used to identify a unique subscriber in the same way that a subscriber identification module (SIM) identifies a subscriber in a cellular communication network.

[0573] When a SIM card is inserted into a cellular phone, communication with the subscriber is connected to the cellular phone; and the cellular phone has the services in the subscriber's account. When a SIM card is inserted into an alternative cellular phone, communication with the subscriber is connected to the alternative cellular phone currently equipped with the SIM card.

[0574] Similarly, when subscriber identification number 505 is associated with unique identifier 111, services provided to the subscriber account represented by subscriber identification number 505 are provided to endpoint 150 with unique identifier 111. When subscriber identification number 505 is associated with alternative unique identifier 112, services provided to the subscriber account represented by subscriber identification number 505 are provided to the alternative endpoint with unique identifier 112.

[0575] exist Figure 23 In this configuration, the security server 140 is configured to dynamically link subscriber ID 505 in subscriber group 503 and unique identifier 111 in endpoint group 501.

[0576] For example, in response to a verification request 173 from client server 141 containing identity data 113, security server 140 may determine whether identity data 113 has a valid verification code 133 for storage device 130 with unique identifier 111. If identity data 113 is valid, then security server 140 may determine whether subscriber group 503 currently has a subscriber identity number 505 available for use by storage device 130 with unique identifier 111 and / or endpoint 150. If so, then security server 140 may provide a verification response 174 confirming the authenticity of identity data 113 and its association with subscriber identity number 505. In response, client server 141 may provide services to the account identified by subscriber identity number 505 to endpoint 150.

[0577] In some implementations, if there is no subscriber ID 505 available for endpoint 150 in subscriber group 503, then the verification response 174 does not recognize the subscriber ID of identity data 113, which may cause client server 141 to reject service requests from endpoint 150.

[0578] Figure 23 The verification request 173 may include access attribute 449, which indicates the requested time period for associating the unique identifier 111 identified in the identity data 113 with a subscriber identity number (e.g., 505) available for use by the endpoint 150 having the unique identifier 111.

[0579] In some implementations, the system is configured to associate unique identifier 111 and subscriber identity number 505 for a predetermined period of time following a verification response 174 that identifies unique identifier 111 and / or identity data 113. After the predetermined period of time, service store 190 removes the assignment of subscriber identity number 505 to unique identifier 111, making subscriber identity number 505 available to another endpoint in endpoint group 501 with a different unique identifier (e.g., 112). After the predetermined period of time, client server 141 does not provide services to the account represented by subscriber identity number 505 to any of the endpoints in endpoint group 501 with unique identifiers 111, ..., 112 (e.g., 150) until another verification response 174 is received from security server 140 associating subscriber identity number 505 with one of the unique identifiers 111, ..., 112 in endpoint group 501.

[0580] When endpoints with unique identifiers 111, ..., 112 compete to use a subscriber identification number (e.g., 505) in subscriber group 503, service store 190 may control the allocation of the subscriber identification number (e.g., 505) in subscriber group 503.

[0581] For example, service store 190 can track endpoints in group 501 that reject access requests because there is no available subscriber ID 505, and prioritize subsequent allocations of available subscriber ID 505 based on the tracked priorities.

[0582] For example, when subscriber ID 505 is available, service store 190 may open a time window in which access requests from different endpoints can be received; when multiple access requests from group 501 are received, the endpoint with the earliest request that was rejected before the time window may have the highest priority to obtain the opportunity to use subscriber ID 505.

[0583] In some implementations, endpoints in endpoint group 501 with unique identifiers 111, ..., 112 can compete for the opportunity to use a subscriber identification number (e.g., 505) in subscriber group 503 based on one or more predefined rules. For example, after receiving a rejection of a service request, an endpoint (e.g., 150) can wait for a random period of time to make a subsequent request. By making the waiting period after rejection random, the opportunity to obtain service access using subscriber group 503 can be allocated to endpoints that need the service.

[0584] In some implementations, endpoint 150, which has been temporarily assigned subscriber ID 505, may notify client server 141 and / or security server 140 to release subscriber ID 505 from its allocation to endpoint 150. For example, after endpoint 150 has completed communication using the service provided to subscriber ID 505, endpoint 150 may return subscriber ID 505 to a subscriber ID pool in group 503, which may be assigned to and / or used by another endpoint in group 501 that has a unique identifier 112.

[0585] In some implementations, the system can track active activity of endpoint 150 using subscriber identification number 505. After the inactive period, service store 190 can remove the assignment of subscriber identification number 505 from unique identifier 111.

[0586] Figure 23 The diagram illustrates a configuration in which security server 140, in conjunction with authentication request 173 and / or authentication response 174, controls the assignment of subscriber identification number 505 to unique identifier 111. Alternatively and / or in combination, client server 141 may connect to service store 190 to implement assignment and / or use the assignment to provide services, such as... Figure 24 As shown.

[0587] exist Figure 24 In this context, client server 141 is coupled to service store 190 and activity tracker 451. Based on verification response 174 indicating the authenticity of endpoint 150 with unique identifier 111 and the availability of subscriber ID 505 for endpoint group 501, client server 141 enables service store 190 to store data indicating temporary allocation of subscriber ID 505 to unique identifier 111.

[0588] Subsequently, the client server 141 can use the activity tracker 451 to determine whether to remove the allocation of subscriber identification number 505 from the unique identifier 111.

[0589] For example, after a predetermined period of inactivity during which endpoint 150 does not use the service provided to the account represented by subscriber ID 505, client server 141 may cause service store 190 to update subscription data 387 and terminate the allocation of subscriber ID 505 to unique identifier 111.

[0590] For example, after receiving an instruction or notification from endpoint 150, client server 141 may cause service store 190 to terminate the allocation of subscriber identification number 505 to unique identifier 111.

[0591] In some implementations, after subscriber ID 505 has been assigned to unique identifier 111, client server 141 may cause service store 190 to terminate the assignment of subscriber ID 505 to unique identifier 111 for a certain period of time. This period of time may be predetermined or determined based on access request 171 received from endpoint 150.

[0592] Figure 25 A method for facilitating subscription sharing among a set of endpoints is illustrated according to one embodiment. For example, Figure 25 The method can be combined with the above. Figure 23 and 24 The technology discussed has the characteristics of combination Figures 1 to 19 The security features discussed are implemented in the system.

[0593] At box 521, the server system stores data that associates endpoint group 501 with at least one subscriber identifier (e.g., identification number 505). Endpoint group 501 may have multiple endpoints (e.g., 150) identified by unique identifiers 111, ..., 112.

[0594] For example, the server system may include a secure server 140 storing the secrets of storage devices (e.g., 130) and / or other servers, such as a service store 190, an activity tracker 451, a package repository 191, a firmware store 170, and / or another server. The server system may further include... Figure 6 The client server 141 and / or card server 223 are shown.

[0595] At box 523, the server system receives an authentication request 173 containing identity data 113 generated by a memory device 130 configured in endpoint 150. The identity data 113 uses its unique identifier 111 in endpoint group 501 to identify endpoint 150.

[0596] At box 525, in response to verification request 173, the server system determines that identity data 113 is valid, at least in part, based on the secret of memory device 130.

[0597] For example, the operation in box 525 can be performed in a manner similar to the operations performed in boxes 323, 343, 403, 423, 463 and / or 485.

[0598] At box 527, the server system determines that the subscriber identifier (e.g., identity number 505) is not currently assigned to any endpoint in endpoint group 501.

[0599] At box 529, the server system assigns a subscriber identifier to endpoint 150 based on data that associates endpoint group 501 with a subscriber identifier (e.g., identification number 505). This assignment enables services to be provided to the endpoints that are represented by and / or associated with the subscriber identifier (e.g., identification number 505).

[0600] For example, a subscriber identifier (e.g., identification number 505) represents a unique subscriber to a service provided in a network (e.g., 225) with multiple endpoints (e.g., 150), including multiple endpoints in endpoint group 501 and other endpoints not in endpoint group 501.

[0601] For example, a service network (e.g., 225) may be configured to provide services to endpoints, such as cellular communication connections, Internet connections, connections to user computers, online storage facilities, online computing resources, payments, transactions, or messages, or any combination thereof.

[0602] For example, assigning a subscriber identifier (e.g., identity number 505) to endpoint 150 includes configuring endpoint 150 to have a unique identity represented by the subscriber identifier (e.g., identity number 505) in the service network (e.g., 225).

[0603] For example, a service network (e.g., 225) may require different endpoints in the network (e.g., 225) to have different identities represented by different subscriber identifiers (e.g., identity number 505). Identity data 113 generated by memory device 130 does not contain a subscriber identifier. Identity data 113 and / or unique identifier 111 of memory device 130 and / or endpoint 150 can be dynamically assigned to or associated with the subscriber identifier (e.g., identity number 505) to configure endpoint 150 for the service network (e.g., 225).

[0604] For example, assigning a subscriber identifier (e.g., identity number 505) to endpoint 150 includes storing data representing the assignment of the subscriber identifier to the endpoint over a period of time.

[0605] For example, the server system may remove the data representing the allocation of the subscriber identifier to the endpoint after the said time period to interrupt endpoint 150 as a subscriber receiving service in the network. After the data removal, endpoint 150 no longer has a subscriber identity represented by the subscriber identifier (e.g., identity number 505) in the service network (e.g., 225).

[0606] For example, the service system may monitor the activity of endpoint 150 as a subscriber receiving services in the service network (e.g., 225); and in response to detecting an inactive period of endpoint 150 as a subscriber receiving services in the network (e.g., 225), the server system may remove data to reconfigure endpoint 150 so that it does not have a subscriber identity represented by a subscriber identifier (e.g., identity number 505) in the service network (e.g., 225).

[0607] Alternatively, in response to a message or request from endpoint 150, it may be possible to release endpoint 150 from the service network (e.g., 225) configured as a subscriber identifier (e.g., identity number 505).

[0608] Alternatively, the length of the period after the subscriber identifier (e.g., identity number 505) is released from the binding to endpoint 150 may be a predetermined length starting from the time when the subscriber identifier (e.g., identity number 505) was assigned to endpoint 150.

[0609] Alternatively, the length of the time period can be specified in verification request 173.

[0610] For example, authentication request 173 is received from client server 141 in a service network (e.g., 225). To configure endpoint 150 to have a subscriber identity represented by a subscriber identifier (e.g., identity number 505), security server 140 may transmit authentication response 174 to client server 141 in response to authentication request 173. Authentication response 174 is configured to indicate the validity of identity data 113 and its association with the subscriber identifier (e.g., identity number 505).

[0611] Generally, endpoint 150 can be identified using different identifiers for different services, in different networks, and / or in different contexts. Each identifier of endpoint 150 can be used to represent endpoint 150 as a member, subscriber, account, authorized device, and / or entity within a group specific to a certain type of service, connection, communication, etc.

[0612] For example, endpoint 150 may be configured to communicate with different client servers 141, ..., 143, respectively, for its services. Endpoint 150 may use different subscriber identifiers identified by different client servers 141, ..., 143. Each subscriber identifier of endpoint 150 represents a unique subscriber and / or account identified by the corresponding client server (e.g., 141, ..., 143) for its services to its subscriber group.

[0613] For example, endpoint 150 can be configured to communicate with client server 141 to obtain different types of services. Different identifiers of endpoint 150 can be used to represent endpoint 150 as a subscriber of different service types.

[0614] For example, endpoint 150 may be assigned an integrated circuit card identifier 251 for use as a smart card, a mobile device identification number 253 for use as a cellular communication device, a mobile subscriber identification number 255 for use as a subscriber of cellular connectivity services, and so on.

[0615] The security server 140 can be configured to manage the identity of the endpoint 150 using the security features of the storage device 130 configured in the endpoint 150.

[0616] For example, a third party may request the security server 140 to bind a subscription service in an account to a public identifier of endpoint 150. Since the identifier is publicly known, there is a potential risk of fraudulent use of the public identifier. The identity data 113 of endpoint 150 can be configured to include the public identifier. Based on the unique device secret (UDS) 101 of the memory device 130 configured in endpoint 150, the security server 140 can verify that the identity data 113 received from endpoint 150 is authentic; therefore, endpoint 150 has an identity represented by the public identifier contained in the identity data 113. The verification performed by the security server 140 can detect fraudulent use of the public identifier as an identity.

[0617] Security server 140 can be configured to manage the secure, dynamic binding of public identities to endpoint 150. For example, in response to a request from an authorized party in an application domain, security server 140 can bind a unique public identity to endpoint 150 of the application domain. For example, the authorized party can be authenticated based on tracking ownership rights of storage devices configured in the endpoint (e.g., 150). Each application domain can have multiple public identities representing individual identities within the application domain. Security server 140 binds a unique public identity to an endpoint at a time.

[0618] For example, in response to a request to bind a public identifier to endpoint 150, security server 140 can verify that the public identifier is not currently bound to another endpoint, and can use an encryption key generation command representing owner permissions to operate storage device 130 to store the public identifier in storage device 130 as part of device information 121 for generating identity data 113 for storage device 130 and / or endpoint 150.

[0619] Alternatively, security server 140 may store data in the application domain that associates endpoint 150 with a public identifier of endpoint 150. In response to authentication request 173 in the application domain, security server 140 authenticates the identity data 113 provided in endpoint 150 and looks up the public identifier of endpoint 150 in the application domain. The public identifier may be provided in authentication response 174.

[0620] The secure, dynamic binding of a public identifier to endpoint 150 can facilitate secure operation. For example, when endpoint 150 is lost / stolen, the owner of endpoint 150 can request security server 140 to bind the public identifier of the lost / stolen endpoint 150 to a replacement endpoint. Once security server 140 binds the public identifier of the lost / stolen endpoint 150 to the replacement endpoint, the service subscribed to the lost / stolen endpoint 150 is transferred to the replacement endpoint. Optionally, the owner of the lost / stolen endpoint 150 can request that data be transferred from the lost / stolen endpoint 150 to the replacement endpoint; and after the transfer, the owner can request that the lost / stolen endpoint 150 be deactivated to minimize the loss / impact of endpoint 150.

[0621] Figure 26 This illustrates a technique for managing endpoint identification according to one embodiment.

[0622] For example, Figure 26 The technology can be combined Figures 1 to 5 The security features of memory devices discussed in sections 9 and 10 are... Figure 1 Used in systems with and / or 6. For example, Figure 26 The technology can be with Figure 14 and 15 firmware store Figure 15 , 23 and 24-hour service stores 190 and / or Figure 20 Use it together with the activity tracker 451 service.

[0623] exist Figure 26 In the storage server 140, a unique identifier 111 and a unique device secret 101 of the storage device 130 are stored. Furthermore, the security server 140 stores device information 121 that characterizes the hardware, software, and / or data configuration of the endpoint 150 on which the storage device 130 is installed. (As in...) Figure 2 In this context, secret key 137 is based on unique device secret 101 and device information 121. Secret key 137 is used by memory device 130 to generate verification code 133 for identity data 113; and security server 140 verifies that verification code 133 was generated using secret key 137, indicating that identity data 113 was generated by memory device 130 with unique device secret 101.

[0624] exist Figure 26 In this context, security server 140 can bind a unique identifier 111 to a public identifier 541 of endpoint 150. For example, after public identifier 541 is assigned to endpoint 150 in the application domain, security server 140 can store public identifier 541 as part of device information 121 associated with the unique identifier of storage device 130 and / or endpoint 150.

[0625] For example, the application domain can be configured for services such as cellular connectivity, smart card processing, and client server 141. Identifier 541 can be used to represent endpoint 150 among a group of endpoints in the application domain. Identifier 541 can be used to represent endpoint 150 as a device, member, service subscriber, account, contact, etc.

[0626] For example, a client server 141 operating in an application domain can request a security server 140 to bind a public identifier 541 to an endpoint 150 having a unique identifier 111. In request 549, the client server 141 can provide identity data 113 received from endpoint 150 and the public identifier 541 to be bound to endpoint 150. In response to request 549, the security server 140 verifies identity data 113 by determining whether the verification code 133 in the identity data 113 was generated using a secret key 137 from a memory device 130 having a unique identifier 111.

[0627] After the identity data 113 is verified, the security server 140 can add the public identifier 541 to the device information 121 and cause the memory device 130 in the endpoint 150 to update the device information 121 543. After the update 543, the memory device 130 has a new secret key for generating new identity data 113 containing the public identifier 541. For example, in addition to the unique identifier 111, the message 131 in the new identity data 113 may also contain the public identifier 541. Security features of the memory device 130 configured to prevent fraudulent use of the unique identifier 111 can also prevent fraudulent use of the public identifier 541. For example, when the client server 141 receives new identity data 113 containing the public identifier 541, the client server 141 can request the security server 140 to verify the new identity data 113. If the new identity data 113 has a valid verification code 133, then it is generated by the endpoint 150 that was assigned the public identifier 541.

[0628] Security server 140 can update device information 121 543 in a manner similar to firmware update 377 and / or package repair 385 installed in endpoint 150. For example, security server 140 can generate verification code 153 for command 155 to store public identifier 541 in memory cell 103 of memory device 130. Verification code 153 is generated using encryption key 145 representing owner permissions to operate memory device 130, said owner permissions including permissions controlled by access controller 109 of memory device 130 for executing command 155 in memory device 130.

[0629] Optionally, the association of public identifier 541 with endpoint 150 does not require the generation of a new secret key to represent memory device 130 and / or endpoint 150. Public identifier 541 may be included in message 131 for generating verification code 133 signed using secret key 137. The public identifier 541 provided in the verification indication message 131 for verification code 133 has not changed; and verification code 133 is signed by memory device 130 installed in endpoint 150.

[0630] Optionally, update 543 is skipped; and storage device 130 and / or endpoint 150 do not store the public identifier 541. Security server 140 stores data that associates the unique identifier 111 with the public identifier 541. After security server 140 verifies the identity data 113 provided in the verification request, security server 140 may look up the public identifier 541 associated with the application domain to find the unique identifier 111 identified in the message 131 of identity data 113, and provide the public identifier 541 in the verification response, similar to... Figure 23 The verification response 174 shown presents subscriber identification number 505 in this manner.

[0631] Optionally, the security server 140 has a portal 545 that allows the computer 180 to submit a request 547 to associate a public identifier 541 with an endpoint 150 having a unique identifier 111. After the portal 545 verifies that the computer 180 is operated by an authorized owner or user of the endpoint 150, the portal 545 can communicate with the security server 140 to update the device information 121 of the unique identifier 111.

[0632] In one embodiment, endpoint 150 has a packet stored in storage device 130. When the packet is loaded from storage device 130 and executed in host system 120, endpoint 150 can communicate with server 140 to obtain update 543. Communication between endpoint 150 and server 140 can be via a client server (e.g., 141), firmware store 170, service store 190, activity tracker 451, or another server (e.g., portal 545), or without any intermediate server.

[0633] For example, the manufacturer of an endpoint (e.g., 150) can use computer 180 to configure the endpoint (e.g., 150) and request an identifier (e.g., 541) assigned by the manufacturer to be bound to the endpoint (e.g., 150). For example, such a public identifier could be a mobile device identification number (e.g., 253) representing various devices in a communications network.

[0634] For example, a service provider can assign a subscriber identification number (e.g., 255) to a subscriber of a service offered by the provider. When the owner or user of endpoint 150 registers for the provider's service, the service provider can use computer 180 to request that subscriber identification number 255 be bound to endpoint 150.

[0635] Figure 27 A method for identifying management endpoints is illustrated according to one embodiment. For example, Figure 27 The method can be combined with the above. Figure 26 The technology discussed has the characteristics of combination Figures 1 to 19 The security features discussed are implemented in the system.

[0636] At box 561, the server system stores data that associates the secret (e.g., 101) of the memory device 130 configured in endpoint 150, the first identification 111 of endpoint 150, and device information 121.

[0637] For example, the server system may include a security server 140. Optionally, the server system may further include a portal 545, a firmware store 170, a service store 190, an activity tracker 451, a package repository 191, and / or another server. In some embodiments, the server system may further include Figure 6 The client server 141 and / or card server 223 are shown.

[0638] At box 563, the server system receives a request to bind the second identifier 541 to the endpoint 150 identified by the first identifier 111 (e.g., 547 or 549).

[0639] For example, a request (e.g., 547 or 549) to bind a second identifier 541 to endpoint 150 can be received from and / or initiated on a computer separate from endpoint 150 (e.g., 180 or server 141) within the server system. The server system is configured to determine whether the computer has permission to attach such a second identifier 541 to endpoint 150. If so, then server system 140 may store data that associates the first identifier 111 and the second identifier 541.

[0640] In one embodiment, the permission to attach such a second identifier 541 to endpoint 150 is associated with an entity that operates the computer and has ownership of the storage device 130 (e.g., as a manufacturer, retailer, service provider, or end user of endpoint 150).

[0641] For example, an entity may use a computer to communicate with endpoint 150 and / or memory device 130 to retrieve current identity data 113 generated by memory device 130. Current identity data 113 includes a first identifier 111 and can be verified by a server system as to whether the current identity data 113 from memory device 130 is authentic.

[0642] For example, in response to a request, the server system may store data that associates the first identifier 111 with the second identifier 541.

[0643] For example, the server system can update the device information 121 of the first identifier 111 to include the second identifier 541.

[0644] For example, the server system may communicate with endpoint 150 to update data stored in memory device 130 and / or store a second identifier 541 in memory device 130.

[0645] Optionally, the second identification 541 may be used as part of the device information 121 in the memory device 130 for generating the secret key 137, wherein the secret key 137 is used to generate the verification code 133 for the identity data 113 of the memory device 130 and / or the endpoint 150.

[0646] Optionally, the second identifier 541 does not alter the generation of the secret key 137. However, the second identifier 541 is stored in the access-controlled area of ​​the memory device 130 and included in message 131 presented in the identity data 113 (e.g., as part of data C 127).

[0647] For example, in response to a request to bind the second identifier 541 to endpoint 150, the server system can generate a verification code 153 for command 155 and cause memory device 130 to execute command 155 based on the verification code 153. Upon receiving command 155 and its verification code 153, access controller 109 of memory device 130 is configured to verify the verification code 153 of command 155 using an encryption key (e.g., access control key 149) representing permission to execute command 155 in memory device 130. Memory device 130 is configured to execute command 155 in response to determining that the verification code 153 of command 155 is valid; executing command 155 in memory device 130 may store the second identifier 541 in memory device 130 for subsequent generation of identity data 113. For example, the second identifier 541 may be stored as part of device information 121 and / or used for presentation in message 131 of identity data 113.

[0648] For example, the memory device stores a set of executable instructions in endpoint 150. This set of instructions may be part of content 161 or a package 441 of the endpoint's firmware or operating system. The memory device 130 is configured to verify the integrity of the set of instructions before allowing endpoint 150 to load them for execution. Because the set of instructions is protected via the memory device 130, the server system can reliably communicate with endpoint 150 executing the set of instructions to enable the memory device 130 to execute command 155. The communication path between endpoint 150 and the server system may optionally be protected via client server 141 and / or optionally via session key 263 and symmetric encryption.

[0649] At box 565, the server system receives a verification request 173 containing identity data 113 generated by memory device 130. The identity data 113 includes a verification code 133 generated from the message 131 presented in the identity data 113 and an encryption key (e.g., secret key 137) derived at least in part from a secret (e.g., 101).

[0650] For example, in some implementations, the message 131 presented in the identity data contains a second identifier 541. Optionally, when the second identifier 541 is configured as part of the device information 121, an encryption key (e.g., secret key 137) for signing the message 131 in the form of a verification code 133 may be further derived based on the second identifier 541; alternatively, the encryption key may be independent of the second identifier 541.

[0651] In some implementations, the message 131 presented in the identity data 113 does not contain a second identifier 541.

[0652] At box 567, the server system verifies the validity of identity data 113 based at least in part on the secret (e.g., 101) of memory device 130.

[0653] For example, the operation in box 567 can be performed in a manner similar to the operations performed in boxes 323, 343, 403, 423, 463, 485 and / or 525.

[0654] At box 569, the server system provides a verification response 174 to the verification request 173 in response to determining that the identity data 113 is valid. The verification response 174 is configured to indicate that the identity data 113 was generated by the endpoint 150 having the second identifier 541.

[0655] For example, the server system can identify the second identifier 541 in the verification response 174 by looking up the second identifier 541 associated with the first identifier in the data stored in the security server 140 or by retrieving the second identifier 541 from the identity data 113. Alternatively, the server system can indicate that the identity data 113 is valid, including the second identifier 541 presented in the message 131 contained in the identity data 113.

[0656] Figure 28 An example machine of computer system 600 is shown, within which a set of instructions can be executed to cause the machine to perform any one or more of the methods discussed herein. In some embodiments, computer system 600 may correspond to a host system that includes, is coupled to, or uses a memory subsystem, or may be used to perform the operations of security manager 160 (e.g., execute instructions to perform actions corresponding to those described in the reference). Figure 1-27 The operation of the security features of the described security server 140 and / or storage device 130. In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a LAN, intranet, extranet, and / or the Internet. The machine may operate as a qualified server or client machine in a client-server network environment, as a peer-to-peer (or distributed) network environment, or as a server or client machine in a cloud computing infrastructure or environment.

[0657] The machine may be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), cellular phone, network appliance, server, network router, switch, or bridge, or any machine capable of executing (sequentially or otherwise) a set of instructions specifying actions to be taken by the machine. Furthermore, although a single machine is shown, the term "machine" should also be considered to include any collection of machines that individually or collectively execute a set (or more) of instructions to perform any or more of the methods discussed herein.

[0658] Example computer system 600 includes a processing device 602, a main memory 604 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM), such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), static random access memory (SRAM), etc.), and a data storage system 618, which communicate with each other via a bus 630 (which may include multiple buses).

[0659] Processing device 602 represents one or more general-purpose processing devices, such as microprocessors, central processing units, etc. More specifically, the processing device may be a Complex Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computing (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, or a processor implementing other instruction sets, or a processor implementing a combination of instruction sets. Processing device 602 may also be one or more special-purpose processing devices, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, etc. Processing device 602 is configured to execute instructions 626 for performing the operations and steps discussed herein. Computer system 600 may further include a network interface device 608 communicating via network 620.

[0660] Data storage system 618 may include machine-readable medium 624 (also referred to as computer-readable medium) on which one or more sets of instructions 626 or software embodying any one or more of the methods or functions described herein are stored. Instructions 626 may also reside wholly or at least partially in main memory 604 and / or processing device 602 during execution by computer system 600, main memory 604, and processing device 602, which also constitute machine-readable storage media. Machine-readable medium 624, data storage system 618, and / or main memory 604 may correspond to a memory subsystem.

[0661] In one embodiment, instruction 626 includes implementations corresponding to security manager 160 (e.g., reference 160). Figure 1-27 The description describes the functional instructions for the operation of the security features of the security server 140 and / or storage device 130. Although the machine-readable storage medium 624 is shown as a single medium in the exemplary embodiment, the term "machine-readable storage medium" should be considered to include a single medium or multiple media storing one or more sets of instructions. The term "machine-readable storage medium" should also be considered to include any medium capable of storing or encoding a set of instructions executable by a machine and causing the machine to perform any one or more of the methods of this disclosure. The term "machine-readable storage medium" should therefore be considered to include, but is not limited to, solid-state memory, optical media, and magnetic media.

[0662] Generally, endpoint 150, servers (e.g., security server 140, client server 141 or 143, or card server 223) can be computing systems having host system 120 and memory subsystem. The memory subsystem may contain media, such as one or more volatile memory devices, one or more non-volatile memory devices (e.g., memory device 130), or a combination of both.

[0663] The memory subsystem can be a storage device, a memory module, or a mixture of both. Examples of storage devices include solid-state drives (SSDs), flash drives, universal serial bus (USB) flash drives, embedded multimedia controller (eMMC) drives, universal flash memory (UFS) drives, secure digital cards (SD cards), and hard disk drives (HDDs). Examples of memory modules include dual in-line memory modules (DIMMs), small outline DIMMs (SO-DIMMs), and various types of non-volatile dual in-line memory modules (NVDIMMs).

[0664] For example, a computing system may be a computing device, such as a desktop computer, laptop computer, web server, mobile device, vehicle (e.g., airplane, drone, train, car or other means of transport), device with Internet of Things (IoT) capabilities, embedded computer (e.g., embedded computer contained in a vehicle, industrial equipment or networked business device), or such computing device containing memory and processing devices.

[0665] The host system 120 of the computing system is coupled to one or more memory subsystems. As used herein, “coupled to” or “coupled with” generally refers to a connection between components, which can be an indirect or direct communication connection (e.g., without intermediate components), whether wired or wireless, and includes electrical, optical, magnetic, and other connections.

[0666] Host system 120 may include a processor chipset (e.g., processing device 118) and a software stack executed by the processor chipset. The processor chipset may include one or more cores, one or more caches, a memory controller (e.g., controller 116) (e.g., an NVDIMM controller), and a storage protocol controller (e.g., a PCIe controller, a SATA controller). Host system 120 uses the memory subsystem, for example, to write data to and read data from the memory subsystem.

[0667] Host system 120 can be coupled to the memory subsystem via a physical host interface. Examples of physical host interfaces include, but are not limited to, Serial Advanced Technology Attachment (SATA) interfaces, Peripheral Component Interconnect High Speed ​​(PCIe) interfaces, Universal Serial Bus (USB) interfaces, Fibre Channel, Serial Attached SCSI (SAS) interfaces, Double Data Rate (DDR) memory bus interfaces, Small Computer System Interface (SCSI), Dual In-line Memory Module (DIMM) interfaces (e.g., DIMM socket interfaces supporting Double Data Rate (DDR)), Open NAND Flash Interface (ONFI), Double Data Rate (DDR) interfaces, Low Power Double Data Rate (LPDDR) interfaces, or any other interfaces. The physical host interface can be used to transfer data between host system 120 and the memory subsystem. Host system 120 may further utilize an NVM Fast (NVMe) interface to access components (e.g., memory device 130) when the memory subsystem is coupled to host system 120 via a PCIe interface. The physical host interface provides an interface for passing control, address, data, and other signals between the memory subsystem and host system 120. Generally, host system 120 can access one or more memory subsystems via the same communication connection, multiple separate communication connections, and / or a combination of communication connections.

[0668] The processing unit 118 of the host system 120 may be, for example, a microprocessor, a central processing unit (CPU), a processor core, an execution unit, etc. In some cases, the controller 116 may be referred to as a memory controller, a memory management unit, and / or an initiator. In one example, the controller 116 controls communication via a bus coupled between the host system 120 and the memory subsystem. Generally, the controller 116 may send commands or requests to the memory subsystem requesting access to the memory device 130. The controller 116 may further include an interface circuitry for communicating with the memory subsystem. The interface circuitry can translate responses received from the memory subsystem into information for the host system 120.

[0669] The controller 116 of the host system 120 can communicate with the controller of the memory subsystem to perform operations, such as reading, writing, or erasing data at memory device 130, and other such operations. In some cases, the controller 116 is integrated within the same package as the processing device 118. In other cases, the controller 116 is packaged separately from the processing device 118. The controller 116 and / or the processing device 118 may include hardware such as one or more integrated circuits (ICs) and / or discrete components, buffer memory, cache memory, or combinations thereof. The controller 116 and / or the processing device 118 may be a microcontroller, a special-purpose logic circuit system (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), or another suitable processor.

[0670] The memory device 130 may include any combination of different types of non-volatile memory components and / or volatile memory components. The volatile memory device may be, but is not limited to, random access memory (RAM), such as dynamic random access memory (DRAM) and synchronous dynamic random access memory (SDRAM).

[0671] Some examples of non-volatile memory components include NAND flash memory and in-situ write memory, such as three-dimensional crosspoint ("3D crosspoint") memory. Non-volatile memory crosspoint arrays can combine stackable cross-grid data access arrays to perform bit storage based on variations in volume resistance. Furthermore, compared to many flash-based memories, crosspoint non-volatile memories can perform in-situ write operations, where non-volatile memory cells can be programmed even after they have been previously erased. NAND flash memories include, for example, two-dimensional NAND (2DN NAND) and three-dimensional NAND (3D NAND).

[0672] Each of the memory devices 130 may include one or more arrays of memory cells. One type of memory cell, such as a single-level cell (SLC), may store one bit per cell. Other types of memory cells, such as multi-level cell (MLC), three-level cell (TLC), four-level cell (QLC), and five-level cell (PLC), may store multiple bits per cell. In some embodiments, each of the memory devices 130 may include one or more arrays of, for example, SLC, MLC, TLC, QLC, PLC, or any combination thereof. In some embodiments, a particular memory device may include an SLC portion, an MLC portion, a TLC portion, a QLC portion, and / or a PLC portion of memory cells. The memory cells of the memory device 130 may be grouped into pages, and a page may refer to a logical cell of the memory device used to store data. In some types of memory (e.g., NAND), pages may be grouped to form blocks.

[0673] Although non-volatile memory devices, such as 3D crosspoint type and NAND type memory (e.g., 2D NAND, 3D NAND), are described, memory device 130 may be based on any other type of non-volatile memory, such as read-only memory (ROM), phase-change memory (PCM), auto-select memory, other chalcogenide-based memory, ferroelectric transistor random access memory (FeTRAM), ferroelectric random access memory (FeRAM), magnetic random access memory (MRAM), spin-transfer torque (STT)-MRAM, conductive bridged RAM (CBRAM), resistive random access memory (RRAM), oxide-based RRAM (OxRAM), NOR flash memory, and electrically erasable programmable read-only memory (EEPROM).

[0674] The memory subsystem controller can communicate with memory device 130 to perform operations, such as reading, writing, or erasing data at memory device 130, and other such operations (e.g., in response to commands scheduled by controller 116 on the command bus). The memory subsystem controller may include hardware such as one or more integrated circuits (ICs) and / or discrete components, buffer memories, or combinations thereof. The hardware may include a digital circuit system with dedicated (e.g., hard-decoded) logic to perform the operations described herein. The memory subsystem controller may be a microcontroller, a dedicated logic circuit system (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), or another suitable processor.

[0675] The memory subsystem controller may include a processing device (e.g., a processor) configured to execute instructions stored in local memory. In the example shown, the local memory of the memory subsystem controller includes embedded memory configured to store instructions for performing various procedures, operations, logic flows, and routines for controlling the operation of the memory subsystem, including handling communication between the memory subsystem and the host system 120.

[0676] In some embodiments, the local memory may include memory registers that store memory pointers, retrieved data, etc. The local memory may also include read-only memory (ROM) for storing microcode. While some memory subsystems have a memory subsystem controller, others do not and may rely on external control (e.g., provided by an external host or by a processor or controller separate from the memory subsystem).

[0677] Generally, the memory subsystem controller receives commands or operations from the host system 120 and translates these commands or operations into instructions or appropriate commands to achieve the desired access to the memory device 130. The memory subsystem controller may handle other operations such as wear leveling, garbage collection, error detection and error correction (ECC) operations, encryption, caching, and address translation between logical addresses (e.g., logical block addresses, namespaces) and physical addresses (e.g., physical block addresses) associated with the memory device 130. The memory subsystem controller may further include a host interface circuitry for communicating with the host system 120 via a physical host interface. The host interface circuitry translates commands received from the host system into instructions for accessing the memory device 130 and translates responses associated with the memory device 130 into information for the host system 120.

[0678] The memory subsystem may also include additional circuitry or components not shown. In some embodiments, the memory subsystem may include a cache or buffer (e.g., DRAM) and address circuitry (e.g., row decoder and column decoder) that can receive addresses from the memory subsystem controller and decode the addresses to access the memory device 130.

[0679] In some embodiments, memory device 130 includes a local media controller that incorporates a memory subsystem controller for performing operations on one or more memory cells 103 of memory device 130. The local media controller may be used to implement encryption engine 107 and / or access controller 109. An external controller (e.g., a memory subsystem controller or controller 116 of host system 120) may externally manage memory device 130 (e.g., perform media management operations on memory device 130). In some embodiments, memory device 130 is a managed memory device, which is a native memory device combined with a local media controller for media management within the same memory device package. An example of a managed memory device is a managed NAND (MNAND) device.

[0680] The memory subsystem controller and / or memory device 130 may include a security manager 160 configured to provide the security features discussed above. In some embodiments, the memory subsystem controller and / or a local media controller in the memory subsystem may include at least a portion of the security manager 160. In other embodiments, or in combination, a controller 116 in the host system 120 may include at least a portion of the security manager 160. For example, the memory subsystem controller, controller 116, and / or security server 140 may include a logic circuit system and / or execute instructions when the security manager 160 is implemented. For example, a processing means 118 (e.g., a processor) of the memory subsystem controller or host system 120 may be configured to execute instructions stored in the memory device 130 for performing the operations of the security manager 160 described herein. In some embodiments, the security manager 160 is implemented in an integrated circuit chip disposed in the memory subsystem. In other embodiments, the security manager 160 may be part of the firmware of the memory subsystem, the operating system of the host system 120, a device driver or application, or any combination thereof.

[0681] Some of the previously described sections have presented algorithms and symbolic representations of operations on data bits within computer memory. These algorithmic descriptions and representations are the most efficient way for those skilled in the art of data processing to communicate their work to others skilled in the art. Here and generally, an algorithm is conceived as a self-consistent sequence of operations that produces a desired result. These operations are those that require physical manipulation of physical quantities. Typically, but not necessarily, these quantities take the form of electrical or magnetic signals that can be stored, combined, compared, and otherwise manipulated. It has been found convenient, primarily for common reasons, to refer to these signals as bits, values, elements, symbols, characters, items, numbers, etc.

[0682] However, it should be remembered that all these and similar terms are associated with appropriate physical quantities and are merely convenient labels for application to those quantities. This disclosure may refer to the actions and processes of a computer system or similar electronic computing device that manipulate and transform data represented as physical (electronic) quantities in the registers and memories of a computer system into other data similarly represented as physical quantities in the computer system's memory or registers or other such information storage systems.

[0683] This disclosure also relates to apparatus for performing the operations described herein. Such apparatus may be specifically constructed for the desired purpose, or may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in a computer. Such computer programs may be stored in computer-readable storage media, such as, but not limited to, any type of disk, including floppy disks, optical disks, CD-ROMs and magneto-optical disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic cards or optical cards, or any type of media suitable for storing electronic instructions, each coupled to a computer system bus.

[0684] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various general-purpose systems can be used with the programs taught herein, or it may prove convenient to construct more specialized devices to perform the methods described herein. Structures for various such systems will be presented in the following description. Furthermore, this disclosure is described without reference to any particular programming language. It should be understood that the teachings of this disclosure as described herein can be implemented using a variety of programming languages.

[0685] This disclosure may be provided as a computer program product or software, which may include machine-readable media on which instructions are stored for programming a computer system (or other electronic device) to perform processes according to this disclosure. Machine-readable media includes any means for storing information in a machine-readable (e.g., computer-readable) form. In some embodiments, machine-readable (e.g., computer-readable) media includes machine-readable storage media such as read-only memory (“ROM”), random access memory (“RAM”), disk storage media, optical storage media, flash memory components, etc.

[0686] In this specification, for the sake of simplicity, various functions and operations are described as being executed or caused by computer instructions. However, those skilled in the art will recognize that such expressions are intended to mean that the functions originate from one or more controllers or processors (e.g., microprocessors) executing computer instructions. Alternatively or in combination, the functions and operations may be implemented using a dedicated circuit system with or without software instructions, such as using an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA). Embodiments may be implemented using hardwired circuit systems without software instructions or in combination with software instructions. Therefore, the technology is neither limited to any particular combination of hardware circuit systems and software, nor to any particular source of instructions executed by a data processing system.

[0687] In the foregoing description, embodiments of this disclosure have been described with reference to specific example embodiments thereof. It will be apparent that various modifications may be made thereto without departing from the broader spirit and scope of the embodiments of this disclosure as set forth in the appended claims. Therefore, the description and drawings should be viewed in an illustrative rather than restrictive sense.

Claims

1. A memory device comprising: An integrated circuit memory cell, formed on one or more integrated circuit dies, includes a first memory region comprising memory cells configured to store device identity data; A controller configured to generate device identity data representing the memory device based at least in part on the root secret of the memory device, and to control access to the first memory region based on an access control key; as well as An integrated circuit package configured to enclose the integrated circuit memory cell and the controller; The integrated circuit memory cell is configured to store boot instructions executable by an endpoint, the endpoint having the memory device as one of a plurality of components of the endpoint; and The controller is further configured to store a card profile in the integrated circuit memory cell to simulate the function of a smart card based on the card profile; and The controller is configured to further generate device identity data based on the hash value obtained by applying an cryptographic hash function.

2. The memory device according to claim 1, further comprising: A physically unclonable function (PUF) is used to generate the root secret; The controller is configured to further generate device identity data based on the hash value obtained by applying a cryptographic hash function to the boot instruction stored in a second memory region of the memory device.

3. The memory device of claim 2, wherein the controller includes a cryptographic engine configured to perform cryptographic computations without using a processor outside the integrated circuit package.

4. The memory device of claim 3, wherein the smart card includes a subscriber identification module configured to authenticate when accessing a cellular communication network.

5. The memory device of claim 4, wherein the card profile includes an International Mobile Subscriber Identity (IMSI) number or an International Mobile Equipment Identity (IMEI) number.

6. The memory device of claim 5, wherein the card profile further includes an authentication key associated with the International Mobile Subscriber Identity (IMSI) number or the International Mobile Equipment Identity (IMEI) number.

7. The memory device of claim 6, wherein the controller is configured to generate a response to a security challenge by signing a message having a random number using the authentication key to prove that the endpoint possesses the authentication key.

8. The memory device of claim 7, wherein the controller is further configured to generate endpoint identity data representing the component configuration of the endpoint at startup time.

9. The memory device of claim 8, wherein the endpoint identity data is calculated at least in part using tracking data stored in the memory device during the construction of the endpoint and identification data of components of the endpoint outside the integrated circuit package.

10. The memory device of claim 5, wherein the card profile includes a software module having instructions that can be executed by the controller or the processor of the endpoint, or any combination thereof, to emulate the function of the smart card.

11. A method comprising: Device identity data representing the memory device is generated, at least in part, based on the root secret of the memory device, by a controller enclosed in the integrated circuit package of the memory device. The device identity data is stored in a first memory region of an integrated circuit memory cell formed on one or more integrated circuit dies enclosed within the integrated circuit package; Based on the access control key, the controller controls access to the first memory region; A boot instruction executable by an endpoint is stored in a second memory region of the integrated circuit memory cell, the endpoint having the memory device as one of a plurality of components of the endpoint; as well as The controller writes the card profile into the integrated circuit memory cell to simulate the function of a smart card based on the card profile. The device identity data is further generated based on the hash value obtained by applying a cryptographic hash function.

12. The method of claim 11, wherein the device identity data is generated based on a hash value obtained by applying a cryptographic hash function to the startup instruction, and is generated using a cryptographic engine configured to perform cryptographic computations without using a processor located outside the integrated circuit package.

13. The method of claim 12, further comprising: At least in part based on the device identity data, endpoint identity data representing the component configuration of the endpoint at startup time is calculated; The card profile is generated and assigned to the endpoint based on the endpoint identity data.

14. The method of claim 13, wherein the endpoint identity data is calculated at least in part using tracking data stored in the memory device during the construction of the endpoint and identification data of components of the endpoint outside the integrated circuit package; and the calculation of the endpoint identity data is protected via security features of the memory device.

15. The method of claim 14, wherein the card profile comprises: International Mobile Subscriber Identity (IMSI) number or International Mobile Equipment Identity (IMEI) number; and An authentication key associated with the International Mobile Subscriber Identity (IMSI) number or the International Mobile Equipment Identity (IMEI) number.

16. The method of claim 15, further comprising responding to a security challenge of the cellular connection to the International Mobile Subscriber Identity (IMSI) number or International Mobile Equipment Identity (IMEI) number presented by the endpoint: Use the authentication key to sign the message containing the random number; A response to the challenge is provided based on the digital signature applied to the message; as well as A symmetric encryption key for communication sessions associated with the cellular connection is generated from the digital signature.

17. The method of claim 16, wherein the card profile includes a software module having instructions that can be executed by the controller or the processor of the endpoint, or any combination thereof, to emulate the function of the smart card.

18. An endpoint comprising: Multiple components, including a memory device and a processor connected to the memory device, wherein the memory device includes: An integrated circuit memory cell, formed on one or more integrated circuit dies, includes a first memory region comprising memory cells configured to store device identity data; A controller configured to generate device identity data representing the memory device based at least in part on the root secret of the memory device, and to control access to the first memory region based on an access control key; as well as An integrated circuit package configured to enclose the integrated circuit memory cell and the controller; The memory device is configured to store boot instructions executable by the processor in the integrated circuit memory cell; and The endpoint is further configured to store a card profile in the integrated circuit memory cell to simulate the function of a smart card based on the card profile; and The controller is configured to further generate device identity data based on the hash value obtained by applying an cryptographic hash function.

19. The endpoint of claim 18, wherein the memory device includes a Physically Unclonable Function (PUF) for generating the root secret, and the controller is configured to further generate device identity data based on a hash value obtained by applying a cryptographic hash function to the boot instruction stored in a second memory region of the memory device; wherein the endpoint is further configured via the memory device to generate endpoint identity data representing the component configuration of the endpoint at boot time; and wherein the card profile is identified based on the endpoint identity data.

20. The endpoint of claim 19, wherein the card profile includes International Mobile Subscriber Identity (IMSI) number or International Mobile Equipment Identity (IMEI) number; An authentication key associated with the International Mobile Subscriber Identity (IMSI) number or the International Mobile Equipment Identity (IMEI) number; and A software module with instructions that can be executed in the endpoint to simulate a subscriber identification module (SIM) card.

Images