Monitoring the integrity of endpoints with secure memory devices for authentication

Abstract

The present application relates to monitoring the integrity of an endpoint having a secure memory device for identity authentication. A security server is configured to manage the integrity of packages stored in the endpoint based on identity authentication implemented using security features of the memory device configured in the endpoint. For example, the security server may verify identity data generated by the memory device based at least in part on a secret of the memory device. The server may extract health information about packages stored in the endpoint from the identity data and determine whether to update or repair the packages currently stored in the endpoint based at least in part on the health information.

Description

[0001] Related applications

[0002] This application claims the benefit of the filing date of Provisional U.S. Patent Application No. 63 / 105,820, filed on October 26, 2020, and entitled “Virtual Subscriber Identification Module and Virtual Smart Card,” which also claims the benefit of the filing date of Provisional U.S. Patent Application No. 63 / 156,235, filed on March 3, 2021, and entitled “Monitor Integrity of Endpoints having Secure Memory Devices for Identity Authentication,” the entire disclosures of which are hereby incorporated by reference herein.

[0003] This application is related to U.S. patent application Ser. No. 17 / 005,565, filed on Aug. 28, 2020, and entitled “Secure Memory System Programming for Host Device Verification,” which claims the benefit of the filing dates of: U.S. Provisional Patent Application Ser. No. 63 / 059,617, filed on Jul. 31, 2020; U.S. Patent Application Ser. No. 17 / 080,684, filed on Oct. 26, 2020, and entitled “Endpoint Authentication based on Boot-Time Binding of Multiple Components”; and U.S. Patent Application Ser. No. 17 / 080,684, filed on Apr. 4, 2019, and entitled “Onboarding Software on Secure Devices to Generate Device Identities for Authentication with Remote Servers.” and U.S. patent application Ser. No. 16 / 374,905, filed on September 8, 2020, entitled “Customer-Specific Activation of Functionality in a Semiconductor Device,” the entire disclosures of which are hereby incorporated by reference herein. Technical Field

[0004] At least some embodiments disclosed herein relate generally to authentication, and more particularly, but not limited to, authentication of communication endpoints having secure memory devices in a network. Background Art

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

[0006] Standards for the Device Identity Composition Engine (DICE) and the Robust Internet of Things (RIoT) have been developed for data computing based on cryptographic computing to identify and authenticate computing devices. Summary of the Invention

[0007] According to one aspect of the present application, a method is provided. The method includes: receiving, in a server system, identity data generated by a memory device configured in an endpoint from the endpoint; verifying, by the server system, the identity data based on information about the endpoint stored in the server, the information including a secret of the memory device and a portion of content stored in the memory device; and, in response to determining that the identity data is valid, extracting health information of a package stored in the endpoint from the identity data; determining, based at least in part on the health information, that the package stored in the endpoint requires updating or repairing; and initiating an operation to perform the updating or repairing of the package stored in the endpoint.

[0008] According to another aspect of the present application, a computing system is provided. The computing system includes: a memory storing an encryption key of a memory device; and at least one processor configured via a set of instructions to: receive identity data generated by a memory device configured in an endpoint; and in response to receiving the identity data: verify the identity data based at least in part on a secret of the memory device; extract health information of a package stored in the endpoint from the verified identity data; and determine whether to update or repair the package stored in the endpoint based at least in part on the health information.

[0009] According to another aspect of the present application, a non-transitory computer storage medium is provided. The non-transitory computer storage medium stores instructions that, when executed by a server system, cause the server system to perform a method, the method comprising: receiving identity data generated by a memory device configured in an endpoint; validating the identity data based at least in part on a secret of the memory device; and, in response to determining that the identity data is valid, extracting health information of a package stored in the endpoint from the identity data; and determining whether to update or repair the package stored in the endpoint based at least in part on the health information. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Embodiments are illustrated by way of example, and not limitation, in the figures of the accompanying drawings in which like references indicate similar elements.

[0011] Figure 1 An example computing system is shown in accordance with some embodiments of the present disclosure.

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

[0013] Figure 3A technique for controlling command execution in a memory device according to one embodiment is shown.

[0014] Figure 4 A technique for verifying the integrity of data stored in a memory device is shown according to one embodiment.

[0015] Figure 5 A security service provided by a security server to a client server based on security features implemented in a memory device according to one embodiment is shown.

[0016] Figure 6 A system and method for configuring and authenticating endpoints for card-based services according to one embodiment is 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) is shown according to one embodiment.

[0019] Figure 9 A technique for authenticating a memory device according to one embodiment is shown.

[0020] Figure 10 A technique for generating commands to control secure operations of a memory device is shown according to one embodiment.

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

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

[0023] Figure 13 A method for logging into an endpoint of a service subscribed to an account according to one embodiment is shown.

[0024] Figure 14 A technique for endpoint customization using an online firmware store is shown according to one embodiment.

[0025] Figure 15 A technique for directing services to endpoints via an online service store is shown according to one embodiment.

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

[0027] Figure 17 An endpoint customization method using a service store and a secure server according to one embodiment is shown.

[0028] Figure 18 A diagram illustrating the generation of identity data to facilitate monitoring of integrity and / or endpoint activity according to one embodiment.

[0029] Figure 19 A technique for maintaining the integrity of packets stored in an endpoint is shown according to one embodiment.

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

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

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

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

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

[0035] Figure 26 A technique for managing endpoint identification according to one embodiment is shown.

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

[0037] Figure 28 is a block diagram of an example computer system in which embodiments of the present disclosure may operate. DETAILED DESCRIPTION

[0038] At least some aspects of the present disclosure relate to a security server and a memory device having 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. A host system of the memory device can use the memory and / or storage function of the memory device to store instructions and / or data for processing and store processing results.

[0039] Generally speaking, a memory subsystem may include storage devices and / or memory modules. A host system may use a memory subsystem that includes one or more components, such as memory devices, that store data. The host system may provide data for storage in the memory subsystem and may 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, a boot loader, an operating system, routines, device drivers, application packages, etc. The instructions may be stored for a computing device implemented using a host system connected to the memory device.

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

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

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

[0044] Security features implemented in a memory device can be used to secure communications between the memory device and a security server via 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 be used to verify the identity of the memory device and / or control access to the memory device to prevent and detect counterfeiting, tampering, theft, and / or unsafe operations.

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

[0046] For example, the security server and memory device may combine to implement replacement of a Subscriber Identity Module (SIM).

[0047] A SIM card is commonly used to represent a subscriber's identity for cellular services in a telecommunications network. When the SIM card is inserted into a cellular phone, the cellular phone can access the cellular services provided to the subscriber's account; and when the SIM card is inserted into a replacement cellular phone, the subscriber can use the replacement cellular phone to access the cellular services associated with the account.

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

[0049] Generally speaking, a security server can be deployed on the Internet to provide security-related services to third-party computers and servers based on security features built into memory devices. The security features are built into and packaged within the memory devices. The security features and security services can be used without trusting the security implementation of the computing device that hosts the memory devices. Therefore, security implementation can be focused on the security features of the memory devices and the design of the security server. By simply using memory devices with security features, the security of computing devices using the memory devices can be improved without requiring significant effort from the computing device's designer and / or manufacturer.

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

[0051] Security features of a memory device may be implemented within the memory device's integrated circuit (IC) package during the memory device's manufacture. A memory device may have logic circuitry (or a controller) and memory cells formed on one or more integrated circuit dies. At least some of the memory cells in the memory device may be non-volatile, such that data may be retained in the non-volatile memory cells even if the memory device is powered off for an extended period of time (e.g., days, months, or even years). The non-volatile memory of the memory device may be used to store instructions and data for use in operations of a host system of the memory cells.

[0052] The memory device may have a unique device secret (UDS) that is protected within the memory device so that after the memory device is manufactured, the unique device secret is not transferred outside the memory device and is not readable by a host system via any interface of the memory device.

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

[0054] A cryptographic calculation that encrypts a message using an encryption key involves the calculation of a ciphertext representing the message. The message can be efficiently recovered from the ciphertext by performing a predefined decryption calculation using the corresponding encryption key. Without the corresponding encryption key used for decryption, recovering the message from the ciphertext is generally not feasible. The level of difficulty in recovering the message without knowledge of the corresponding encryption key used for decryption represents the security level of the cryptographic calculation. The security level generally depends on the encryption key length and the encryption algorithm used.

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

[0056] The cryptographic calculation of hashing a message maps the message to a hash value representing the message. However, a certain amount of information is lost in the hash calculation, 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 hashes to the same hash value is generally infeasible, especially when the modified version is similar to the original message.

[0057] The cryptographic calculations used for key generation involve calculating a cryptographic key for symmetric encryption or a pair of cryptographic keys for asymmetric encryption based on a set of data. The probability of generating the same key or key pair without using the same set of data is low. The probability level indicates the strength of the cryptographic calculations used for key generation.

[0058] In general, any cryptographic computing technology for encryption, hashing, and key generation can be used with the memory device and the secure server. Therefore, the present disclosure is not limited to a specific encryption, hashing, and / or key generation technology.

[0059] In addition to the 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. Some of this additional data may or may not be maintained as a secret for the memory device. The unique device secret and the additional data may be used to generate a secret encryption key representing the identity of the memory device and / or 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 calculations (e.g., hashing, encryption / decryption, key generation) within the memory device to support the operation of the identity engine and the access controller. The implementation of the encryption engine in the memory device eliminates the need to rely on an external processor to perform security calculations for the memory device, and thus improves security by preventing secrets from being transmitted outside the memory device and preventing tampering and theft of the encryption calculations. Optionally, at least a portion of the encryption calculations involved in the security features of the memory device can be implemented by storing instructions in the memory device for execution by the host system of the memory device, while there is a certain level of trade-off between the security level and complexity of the logic circuitry (or local controller) of the memory device.

[0061] The encryption engine of the memory device may 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 a ciphertext of the message using the encryption key, and / or recover the message from the ciphertext using the encryption key.

[0062] The access controller of the memory device is configured to control the execution of commands received in the memory device using an encryption key. For example, permission may be required to request the memory device to execute commands such as read, write, delete, modify, etc. on various parts of the non-volatile memory of the memory device. The permission may be represented by a corresponding encryption key. After receiving a permission command for execution in the memory device, the access controller may use an encryption engine to perform calculations when determining whether the command comes from a sender with an encryption key representing the permission. After the calculation indicates that the sender has the encryption key and therefore has permission, the access controller allows the command to be executed in the memory device. Otherwise, the access controller may reject, ignore, or discard the command. Such access control can prevent unauthorized access to data stored in the memory device, prevent unauthorized changes to the memory device, and prevent tampering and / or theft to form counterfeit and / or unsecure devices of the memory device.

[0063] Generally speaking, verifying that the sender of a message possesses the encryption key involves verifying an authentication code of the message. The authentication code may take the form of a hash digest, a digital signature, a hash-based message authentication code (HMAC), a cryptographic message authentication code (CMAC), or the like. The authentication code is generated using the encryption key and the message as input to a cryptographic operation such as hashing, encryption, and / or other computations, making it generally infeasible to generate the authentication code without the encryption key or from a modified version of the message. Therefore, when a recipient confirms that a received authentication code is valid for the received message and encryption key, the recipient can conclude that the sender possesses the corresponding encryption key and that the received message is identical to the message used to generate the received encryption key.

[0064] In some embodiments, the recipient performs verification of the message authentication code using the same encryption key that the sender used to generate the authentication code. For example, the recipient generates an authentication code for the received message using the same encryption key and compares the generated authentication code with the received authentication code. If there is a match, then the received authentication code is valid for the received message, and the sender can be considered to have the encryption key. Otherwise, the received authentication code is invalid for the received message; the received message has changed since the authentication code was generated, or the received authentication code was generated using a different encryption key, or both.

[0065] In some embodiments, the recipient uses the public encryption key from a key pair to verify the message authentication code; and the sender uses the private encryption key from the key pair to generate the authentication code. For example, the authentication code can be generated by applying a hash function to the message to generate a hash value for the message. The ciphertext of the hash value, obtained by encrypting the hash value using the encryption key, can be used as the authentication code. The recipient of the message and authentication code performs authentication using the corresponding decryption key, which is the same as the encryption key when symmetric encryption is used, or the other key in the key pair when asymmetric encryption is used. 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 there is a match, the received authentication code is valid for the received message; otherwise, the received authentication code is invalid for the received message. Alternatively, the recipient can perform authentication using the encryption key without performing decryption. The recipient can use the encryption key to generate an authentication code for the message to compare with the received authentication code.

[0066] In some embodiments, the message and the encryption key are combined to generate a hash value as a verification code, such as in the technique of hash-based message authentication code (HMAC). For example, an 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 another 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 to compare with the received hash-based message authentication code. If there is a match, then the verification is successful; otherwise, the verification fails.

[0067] In general, any technique for generating and verifying an authentication code for a message 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 recipient will perform verification using the appropriate encryption key, which can be the same encryption key used to generate the authentication code or part of the same asymmetric encryption key pair. Therefore, the present disclosure is not limited to specific techniques for hash digests, digital signatures, and / or hash-based message authentication codes.

[0068] For convenience, the verification code used to represent the message and the encryption key generated using the encryption key can be collectively referred to as the digital signature of the message signed using the encryption key, but it should be understood that the verification code can be generated using various technologies, such as a hash-based message authentication code.

[0069] The memory device may be configured to store an associated cryptographic key for verifying an authentication code signed using a cryptographic key configured to indicate permission to request the memory device to execute a command.

[0070] For example, an access controller may provide a set of permissions to the owner of a memory device so that the owner can 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 sections of the memory device that are not readable by other users of the memory device.

[0071] For example, an access controller may provide authorized users of a memory device with specific permissions to read, write, erase, or modify specific sectors of the memory device.

[0072] When a memory device receives a command requiring access rights to execute, the access controller retrieves the corresponding cryptographic key to verify the authentication code or digital signature of the message containing the command. If verification of the authentication code received for the received command is successful, the received command is deemed to have originated from a sender with the cryptographic key indicating permission to execute the command in the memory device. In response, the access controller allows execution of the command in the memory device. Otherwise, the access controller prevents execution of the command.

[0073] The memory device can be manufactured to be initially owned by a security server. The security server can then provide and / or transfer some or all permissions to one or more owners and users during the process from the memory device being assembled into a computing device to the computing device having the memory device being used by an end user. The access controller can prevent tampering, theft, and unauthorized access while providing flexibility to support different permission transfer models for different owners and users, such as the manufacturer of the component computing device in which the memory device is installed, the manufacturer of the computing device in which the component computing device is installed, a retailer, an enterprise user, an end user, and an alternative end user.

[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 on which the memory device is installed. To generate the identity data, the identity engine uses the encryption engine to generate a secret encryption key from a unique device secret and other data stored in the memory device and / or collected by the memory device (e.g., during the boot process of the computing device). The presence of the secret encryption key in the memory device can be considered as evidence that the memory device possesses the unique device secret and the other data used to generate the secret encryption key. The presence of the secret encryption key in the memory device can be verified by a secure server using a verification code or digital signature signed using the secret encryption key.

[0075] During the manufacture of the memory device, a copy of the unique device secret is stored on a secure server and / or securely shared without exposure. The secure server is then 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. Thus, the secure server can verify that the memory device possesses the unique device secret by verifying that the memory device possesses the secret encryption key; and the secret encryption key, which serves as the identity of the memory device, can change during the process of integrating the memory device into a component, device, or system and transferring it between manufacturers, retailers, distributors, companies, and / or end users. Without changing 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 a component, device, or system, customized and / or personalized, and / or owned and / or operated by a different entity or user.

[0076] Cryptographic operations and communications may be performed to allow the secure server to verify that the memory device possesses the secret encryption key.

[0077] For example, the identity data presented by a memory device for verification may include a message showing the public identification of the memory device. The public identification 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 includes a copy of the message and the verification code or digital signature. Once the verification code and message data are verified by the security server, the security server can conclude that the public identification provided in the identity data is authentic and that the identity data originated from the memory device with the secret encryption key.

[0078] The secret encryption key of the memory device can be generated not only using the unique device secret of the memory device but also using additional data representing some aspects of the memory device and / or the computing device on which the memory device is installed. The additional data can represent software, firmware, a boot loader, an application, tracking data stored in the memory device, and identifiers of computing device components in the computing device at the time of the most recent boot of the computing device. If the additional data has been changed, the identity engine generates a changed secret encryption key. Therefore, the verification code generated using the changed secret encryption key cannot pass the verification performed at the secure server. Therefore, the verification of the verification code generated by the identity engine also verifies the integrity and authenticity of the hardware / software / data combination of the memory device and the computing device on which the memory device is installed.

[0079] Verification of the identity 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 the 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 a database of information 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 manufacturing the memory device. The encryption key can be generated at least in part based on additional data available after manufacturing the memory device.

[0081] The security server can store cryptographic keys representing the permissions of the owner of the memory device. Using the cryptographic keys, the security server can generate commands that transfer ownership of the memory device and configure and / or transfer selected permissions to enable execution of selected commands on the memory device. After a computing device is reported lost / stolen, the security server can monitor the use of its memory device during memory device verification and requests for services from third-party servers.

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

[0083] Upon request 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 memory device. The command signed by the authorized party is forwarded to the memory device for execution. The signed command includes a message containing the command and a verification code for the message signed / generated using a cryptographic key indicating permission to execute the command in the memory device.

[0084] A memory device can be installed in a computing device as part of the computing device's identity and provide main memory / storage capacity for the computing device. For example, instructions and associated data to be executed in the computing device can be stored in the memory device and protected from corruption, tampering, and / or theft via the memory device's security features. Because the identity data generated by the memory device's identity engine is based at least in part on the instructions / data stored in the memory device, the integrity and / or authenticity of the instructions and data used by the computing device can be 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 the security server remove the security protections provided by third-party servers for operating and computing devices. Using storage devices and the security server's services prevents unauthorized access without requiring significant effort from computing device manufacturers and third-party server operators. As a result, third-party servers can leverage their core capabilities to provide their services without compromising security.

[0086] The third-party server can use the services provided by the secure server to provide services to its subscribers without requiring the subscriber to perform manual operations to configure the computing device used by the subscriber. For example, the subscriber can use the computing device to access the subscribed cellular service in the subscriber's account without having to insert a physical SIM card into the computing device and / or perform other operations to customize the computing device for access using the subscriber's account.

[0087] A subscriber can be represented by an account identity. When a subscriber purchases a computing device, ownership of the computing device can be transferred to the subscriber via a secure server. Security features of the memory device configured in the computing device can be used to generate a 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 the 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 the third party using the account without manually configuring the computing device.

[0088] For example, during verification of the computing device's identity, the owner / subscriber of the computing device is identified by the ownership management service of the secure server. Once the owner / subscriber is identified, the subscriber's identification can be built into the computing device's device identity or associated with the device identity in the secure server's database. Subsequently, when the device identity is verified, services in the subscriber's account can be provided to the computing device by the third party without requiring the subscriber to explicitly direct / request services to the computing device.

[0089] Optionally, the computing device may establish separate credentials with the 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 An example computing system is shown in accordance with some embodiments of the present disclosure.

[0091] exist Figure 1 In the embodiment, the integrated circuit memory device 130 has the security features as discussed above.

[0092] Secure memory device 130 may store a unique device secret 101 for authentication. In one example, unique device secret 101 is injected into memory device 130 in a secure facility and stored in a register of memory device 130. In another example, unique device secret 101 may be obtained from a physically unclonable function (PUF) in memory device 130. Unique device secret 101 may be obtained via the secure facility and hosted on secure server 140. For example, the secure facility may be part of a manufacturing facility for memory devices (e.g., 130). After memory device 130 is manufactured and / or leaves the secure facility, unique device secret 101 in memory device 130 is inaccessible via any interface of memory device 130 (e.g., host interface 147). Therefore, after manufacturing of memory device 130, unique device secret 101 in memory device 130 is sealed within the integrated circuit package of memory device 130. A copy of the unique device secret 101 is protected within the secure server 140 using strong security measures (eg, using a hardware security module (HSM)) to prevent eavesdropping and unauthorized access.

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

[0094] For example, according to the method specified by the Device Identity Composition Engine (DICE) and Robust Internet of Things (RIoT) standards or another method, the encryption key 105 may be generated at boot time based on a combination of the unique device secret 101 and the device information 121 stored and / or obtained in the memory unit 103 of the memory device 130. The device information 121 may include non-secret data that may be obtained by an entity other than the secure server 140 and the memory device 130. To improve security, the device information 121 may include time-related information.

[0095] For example, encryption key 105 may include two pairs of asymmetric encryption keys. The first pair of asymmetric keys is referred to as a device identification key, and the second pair of asymmetric keys is referred to as an alias key. The private device identification key is used to authenticate the authenticity of the alias key, thereby reducing its use and lowering its risk. The alias key can be used for more transactions / communications and can be replaced more frequently than the device identification key to improve security, as the alias key is used more frequently and therefore presents a risk. For example, the private device identification key can be generated at boot time and used to sign a certificate, such as a certificate for the alias public key; the private device identification key is then immediately deleted from memory device 130 to protect its confidentiality.

[0096] In general, one of the encryption keys 105 generated using the unique device secret 101 and the device information 121 may be used as the secret and identity of the memory device 130 to be authenticated by the secure server 140 .

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

[0098] Using encryption engine 107, memory device 130 can prove that memory device 130 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 digitally sign a certificate or message using secret encryption key 105 to provide a verification code of the message and secret encryption key 105. When secure server 140 successfully verifies the verification code, secure server 140 can conclude that memory device 130 possesses secret encryption key 105 and, therefore, has the identity represented by unique device secret 101.

[0099] Memory device 130 includes a host interface 147 that can be used to receive commands from host system 120. Host system controller 116 can send commands to memory device 130 to request to read data from memory unit 103, write data to memory unit 103, erase data from a portion of memory unit 103, modify data in a portion of memory unit 103, activate security features of memory device 130, configure parameters related to security features in memory device 130, etc. At least some of the commands require permission represented by cryptographic key 106 stored in security server 140. Having cryptographic key 106 available to sign a command is considered to indicate having permission to request memory device 130 to execute the command.

[0100] The memory device 130 includes an access controller 109 that is configured to verify, using the cryptographic engine 107, a verification code generated using the cryptographic key 106 that represents the permissions associated with the command. If the command is received with 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 cryptographic keys 105 are stored in the memory device 130 to provide owner authority to the security server 140. Using the owner authority, the security server 140 can sign commands for execution in the memory device 130 to activate or deactivate security features, trigger the replacement of a secret cryptographic key that is the identity of the memory device 130, replace a cryptographic key used by the access controller 109 to verify permission to execute one or more commands in the memory device 130 for one or more regions of the memory unit 103, and so on.

[0102] Optionally, after authenticating the identity of the authorized requester, the security server 140 may sign the command using an encryption key to generate a verification code or digital signature of the command, so that the requester can 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 secure server 140 may provide specific rights to the entity by replacing the encryption key 105 in the memory device 130 or providing the entity with a corresponding encryption key 106 representing the rights.

[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, and the like.

[0105] Memory unit 103 of memory device 130 may provide storage / memory capacity for host system 120 to store instructions and data for implementing the functionality of endpoint 150. For example, processing device 118 of host system 120 is configured to execute instructions loaded from 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 to receive services from the client servers 141 , . . . , 143 .

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

[0108] In addition to services for authenticating the identity of the memory device 130 , the security server 140 may also provide security services to manage permissions to operate the memory device 130 , configure or change security features or settings of the memory device 130 , detect lost / stolen devices, deactivate lost / stolen devices, and the like.

[0109] Memory device 130 and / or endpoint 150 may have a non-secret unique identification 111. Unique identification 111 may 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 identification 111 of the memory device 130 may include a manufacturer's part number (MPN) of the memory device 130 and / or a serial number of the memory device 130. For example, the unique identification 111 of the memory device 130 may include a public key of a pair of asymmetric encryption keys generated based at least in part on a unique device secret.

[0111] To authenticate that the memory device 130 and / or endpoint 150 has the identity represented by the unique identification 111, the security server 140 verifies the message containing the unique identification 111 (and other data 127) via a verification code of the message signed using the memory device's secret encryption key 105. The secret encryption key 105 in the memory device 130 is generated using the unique device secret 101 in the memory device; and a corresponding encryption key 106 for verifying the verification code signed using the secret encryption key 105 of the memory device 130 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 based not only on the unique device secret 101 but also on the device information 121 accessible to the memory device 130 .

[0113] For example, device information 121 may include a hash value 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 / individualizing memory device 130 and / or endpoint 150 during assembly of components to construct endpoint 150. Furthermore, device information 121 may include identification information of 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 packages for endpoint 150 not stored in memory device 130, and / or identification and / or a hash value of firmware configured to control / operate memory device 130. During boot time, identification data may be collected as device information 121 for generating secret encryption key 105 for memory device 130.

[0114] During the registration process, when the storage device 130 is configured with the device information 121, a copy of the device information 121 is uploaded to the secure server 140 for association with the unique identification 111 of the storage device 130 and / or endpoint 150. Registration of the device information 121 allows the identity of the storage 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 The generation of identity data in an integrated circuit memory device according to one embodiment is shown. For example, Figure 2 The technology can be Figure 1 is implemented in a computing system.

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

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

[0118] Alternatively, when symmetric encryption is used, secret key 137 may be generated and used without public key 139 and without key pair 135 .

[0119] In some embodiments, multiple key pairs 135 are generated and used. For example, when using the Device Identity Composition Engine (DICE) and Robust Internet of Things (RIoT) approaches, the first pair of asymmetric keys is referred to as a device identification key, and the second pair of asymmetric keys is referred to as an alias key. The private device identification key can be used to authenticate the authenticity of the alias key and then immediately deleted and purged 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 in part within the host system 120. The alias key can be used to authenticate other transactions and / or communications. For example, the private device identification key can be generated at boot time and used to sign a certificate, such as a certificate for an alias public key, 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 using 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 the endpoint 150 is restarted.

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

[0121] For example, data 123 may include a 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 a 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 device information 121 to calculate secret key 137.

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

[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, a version number and / or release date of the package, and so forth.

[0124] Optionally, data 123 may include tracking data stored in memory unit 103 during the process of building and / or customizing endpoint 150 that includes memory device 130. For example, when memory device 130 is assembled into a component device (e.g., a memory subsystem), a piece of tracking data representing the manufacturer of the component device, the model number of the component device, and / or the serial number of the component device is stored in memory unit 103 as part of device information 121. Subsequently, when the component device is assembled into endpoint 150, the piece of tracking data is added to the memory unit as part of device information 121. Additional tracking data may be added to memory unit 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, the device information 121 may further include data 125 received from the host system 120 connected to the host interface 147 of the memory device 130 .

[0126] For example, endpoint 150 may have a host system 120 and a memory device 130. Some components in host system 120 may be removed or replaced. When endpoint 150 is booted up, a portion of the instructions stored in memory unit 103 are executed to collect data 125 about the components present in host system 120 at boot time. Therefore, 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 unique device secret 101 represents the identity of memory device 130 having the specific configuration.

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

[0128] As discussed above, the secret key 137 and the authentication code 133 of the 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 authentication code 133 is not limited to a particular embodiment.

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

[0130] Optionally, part of the message 131 may provide information in an encrypted form. For example, the information may be encrypted using the public key of the secure server 140 so that the information is not accessible to a third party.

[0131] Message 131 may be a certificate presenting unique identification 111 of 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 cryptographic nonce, and / or other information related to the verification of identity data 113. Memory device 130 may monotonically increase the counter value to invalidate identity data with a lower 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 embodiments, secret key 137 is a private alias key from a pair of asymmetric keys. Data 127 includes a certificate representing the corresponding public alias key from the pair of asymmetric keys. The certificate representing the public alias key is signed using the device identification key of memory device 130. The public alias key can be used to verify both the verification code 133 of message 131 and the private alias key used as secret key 137. Once secure server 140 verifies the certificate representing the public alias key, which is signed using the device identification key of memory device 130 and provided as part of data 127, secure server 140 can use the public alias key to verify verification code 133, which was signed using the private alias key as secret key 137. In this embodiment, secure server 140 can verify verification code 133 using the public alias key provided in message 131 without having to regenerate the pair of alias keys; and memory device 130 can generate alias key pair 135 using data not yet known to secure server 140.

[0134] A certificate presenting a public alias key can Figure 2 1, wherein secret key 137 is a device identification key generated using device information 121 and unique device secret 101. Optionally, memory device 130 initially provides a certificate with a public alias key to secure server 140. Subsequently, memory device 130 may use the private alias key as secret key 137 without including the public alias key in message 131, or without including a certificate with a public alias key in message 131.

[0135] The data 127 in the message 131 that is signed to generate the verification code 133 may include a challenge. For example, to challenge the memory device 130 to prove its possession of 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 memory device 130 may include using multiple secret keys and verification codes signed with the secret keys. For example, the device identification secret key may be used to initially establish the authenticity of the alias secret key and the identity of memory device 130; and subsequently, the alias secret key may be used to verify the authenticity of the identity of memory device 130. Generally speaking, the device identification secret key and the alias secret key may be based on asymmetric or symmetric encryption, as security server 140 may generate the corresponding encryption key generated by memory device 130.

[0137] For increased security, memory device 130 does not use processing power outside of memory device 130 to generate copies of secret key 137, and does not transmit secret key 137 outside of memory device 130. The generation and use of secret key 137 is performed using the logic of cryptographic engine 107 sealed within memory device 130.

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

[0139] Identity data 113 may be generated in response to powering on memory device 130, in response to a request received in host interface 147, and / or in response to endpoint 150 booting up (e.g., by executing a boot loader stored in memory unit 103). Data 127 may include a count value maintained in memory device 130. When an operation to generate identity data 113 is performed, the count value is incremented. Thus, 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 the count value.

[0140] Figure 3 A technique for controlling command execution in a memory device according to one embodiment is shown. For example, Figure 3 The technology can be Figure 1 implemented in computing systems and Figure 2 technology together.

[0141] exist Figure 3 In the example embodiment, 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] The encryption key 145 is configured to indicate the authority. The sender of the command 155 can generate the verification code 153 from the encryption key 145 and the message 151 containing the command 155.

[0143] As discussed above, the encryption key 145 and the authentication code 153 of the 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 authentication code 153 is not limited to a particular embodiment.

[0144] The access controller 109 verifies the authentication code 153 of the command 155 submitted to the host interface 147 using the corresponding access control key 149. The access controller 109 generates a verification result 159 of the received message 151 and the received authentication code 153 using the cryptographic engine 107. Based on the verification result 159, the access controller 109 can selectively allow the command 155 to be executed within the memory device 130 or prevent the execution of the command 155.

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

[0146] For example, encryption key 145 may be stored in secure server 140 to provide associated permissions to secure server 140 .

[0147] In one embodiment, secure server 140 is configured to generate verification code 153 on behalf of an entity in response to the entity requesting verification code 153 to execute command 155 in 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 a session key to be generated as encryption key 145, which is used to indicate permission to execute selected commands in memory device 130 during a time-limited communication session. Optionally, the period of device power-up can be used as a session delimiter, so that a new count value is generated during the next power cycle, thereby enabling the generation of a new session key.

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

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

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

[0152] For example, data 157 may include an execution count value maintained within memory device 130, rendering verification codes generated for lower counts invalid.

[0153] For example, data 157 may include a cryptographic nonce established for a particular instance of a request to execute command 155 so that verification code 153 cannot be reused for another instance.

[0154] For example, data 157 may include a time window in which verification code 153 is valid.

[0155] For example, data 157 may include an identification of a memory region in which command 155 is permitted to execute.

[0156] For example, data 157 may include a type of operation that allows command 155 to be executed in memory device 130 .

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

[0158] exist Figure 4In the example embodiment, memory device 130 stores not only content 161 but also a hash value 163 of content 161 in memory unit 103. To determine the integrity status 165 of content 161, cryptographic engine 107 applies a cryptographic hash function to content 161 to generate a current hash value of content 161. Cryptographic engine 107 compares the current hash value with stored hash value 163 to determine whether they are identical. If they are identical, the integrity of content 161, as required by stored hash value 163, is confirmed.

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

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

[0161] For example, the manufacturer of endpoint 150 may store content 161 in memory unit 103 so that processing device 118 of host system 120 in endpoint 150 can execute programs or routines in content 161 to provide the designed functionality of endpoint 150. Furthermore, the manufacturer and / or security server 140 may store hash value 163 in a separate section for integrity checking. The end user of endpoint 150 can access and use content 161 in memory unit 103, but cannot access hash value 163. If content 161 is corrupted or tampered with, cryptographic engine 107 can detect the change and generate integrity status 165, causing access controller 109 to block use of content 161. When the manufacturer has an updated version of content 161 (or a replacement), the manufacturer may perform an update in memory unit 103 and issue a command 155 with 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] The device information 121 and the encryption key 105 in the memory device 130 may be stored in a secure section in the memory device 130 and protected by owner rights represented as the encryption key 106 stored in the secure server 140 via the access controller 109 .

[0163] Different secrets (eg, unique device secret 101, secret key 137) and content (eg, device information 121, content 161) may be protected at different security levels and / or using different security strategies designed to balance security and practicality.

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

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

[0166] Figure 5 A security service provided by a security server to a client server based on security features implemented in a memory device according to one embodiment is shown.

[0167] For example, Figure 5 The security services shown in Figure 2 、 3 and / or the safety features shown in 4 Figure 1 is implemented in a computing system.

[0168] exist Figure 5 In, the client server 141 is configured to provide services to computing devices, such as Figure 1 The system has an endpoint 150 having a memory device 130 connected to a host system 120.

[0169] To request a service 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 may be Figure 2 Generated in the manner shown in .

[0170] Host system 120 embeds identity data 113 in request 171 that is transmitted to client server 141 .

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

[0172] Security server 140 may perform verification of identity data 113, determine the authenticity of memory device 130 and / or endpoint 150, and provide the results in response 174 to client server 141. Based on the results, 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, 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, corrupted, changed, or tampered with, or from a lost or stolen device.

[0174] In some embodiments, request 173 may identify a command 155 to be executed in memory device 130. After verifying identity data 113 and verifying the authority of client server 141 and / or endpoint 150 to request execution of command 155 within memory device 130, security server 140 may generate a verification code 153 for command 155 using cryptographic key 145 and provide verification code 153 to client server 141 in response 174. Using the security service, client server 141 may be relieved from the security burden associated with the management of permissions and cryptographic keys 145 representing the permissions.

[0175] Optionally, response 174 may include encryption key 145 indicating 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 within a short period of time.

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

[0177] For example, after executing the command 155 in the memory device 130 , the access controller 109 may be configured to deactivate the boot loader stored in the memory unit 103 of the memory device 130 .

[0178] For example, command 155 may cause access controller 109 to block access to one or more sectors of memory unit 103 .

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

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

[0181] For example, command 155 may cause memory device 130 to perform a self-destruct and become irreversibly damaged.

[0182] Instructions retrieved from memory unit 103 for execution in host system 120 may include routines that may accept commands 155 in response to memory device 130 providing identity data 113. In some implementations, client server 141 may provide a connection that allows secure server 140 to send commands 155 to memory device 130 for execution.

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

[0184] For example, memory device 130 may be configured to generate a multi-factor device platform identity for endpoint 150 with improved security. The identity may be generated by combining a unique device secret 101 of memory device 130, platform source code identifying 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 of network interface 114 or a communication device. For example, the unique identifier may be an identifier of a modem installed on endpoint 150 for communicating over communication network 110. For example, the multi-factor device platform identity may 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 is a vehicle, the multi-factor device platform identity may be based at least in part on the vehicle identification number (VIN). Such a robust identity may be used in conjunction with cloud-based subscriber identity module (SIM) functions for login, network access, and registration of cloud services (e.g., cellular subscription services).

[0185] The security features of the secure server 140 and the memory device (e.g., 130) may provide a secure memory device technology platform. The platform may be configured to support authentication of the endpoint 150 by measuring the data stored in the memory unit 103 of the secure memory device (e.g., 130). Additional network security protection for the endpoint may be achieved by controlling access to the content 161 stored in the memory device (e.g., 130). Access control may be implemented through secure hardware manufacturing operations and password-based permission control, as described above in conjunction with Figures 1 to 5 A platform equipped with such a memory device (eg, 130 ) can achieve a sufficient level of network security protection to support a cloud-based virtual SIM solution and eliminate the need for a physical SIM card on the endpoint 150 to access a cellular connection.

[0186] The secure memory device technology platform may include a combination of a secure memory device (e.g., 130) and software that meets DICE RIoT requirements for generating identity data 113 for an endpoint (e.g., 150) that is activated using the secure memory device. Such identity data 113 for endpoint 150 is generated based on the identity of the secure memory device 130 used to activate endpoint 150 and other factors. Such identity data 113 may be passed to client server 141 during onboarding (e.g., registering for a service). Client server 141 may communicate with secure server 140 to confirm the identity of endpoint 150. When identity data 113 is verified, client server 141 may trust endpoint 150 to be authentic and, therefore, register services with endpoint 150.

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

[0188] Typically, a service network (e.g., a payment card network, a cellular communication network) can identify a subscriber via a smart card. Conventional smart cards are configured as an integrated circuit chip 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 the services provided to the account by the service network. The integrated circuit chip can be read via metal contacts disposed 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 commonly used in mobile phones to identify an account used to access services on a cellular communication network. 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 the SIM card is attached to a replacement mobile phone, the replacement mobile phone can access 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. A mobile / cellular network operator can assign an authentication key 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] Europay MasterCard Visa (EMV) cards are another example of smart cards. EMV cards can be used to receive financial services in payment card processing networks to access bank accounts, such as debit and credit accounts.

[0192] The integrated circuit memory device 130 may 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 endpoint 150 on which the memory device 130 is installed. Figure 6 As shown, a secure memory device 130 having security features may be used to implement the functionality of smart cards such as SIM cards and EMV cards using data remotely supplied to the secure memory device and / or using data stored in a secure server.

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

[0194] For example, Figure 6 The systems and methods can be used Figures 2 to 5 The technology in Figure 1 is implemented in a computing system.

[0195] exist Figure 6 In the embodiment, the memory device 130 may use Figures 1 to 5 The access controller 109 of the memory device 130 may use one or more access control keys 213 to control read and write operations of accessing 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 secure server 140 full access to memory regions in 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, the device identity data 211 may be used Figure 2 The technique shown in .

[0198] For example, during the manufacture of memory device 130, a root secret (e.g., unique device secret 101) of memory device 130 is loaded into secure server 140 during the memory registration 231 operation. The root secret can 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 the manufacture of memory device 130. Secure server 140 may include a key management server configured to manage encryption keys for secure memory devices (e.g., 130). The root key can be considered and / or used as a secret encryption key. When memory device 130 is manufactured, the root secret can be obtained from memory device 130 or injected into memory device 130 for use in memory registration 231. Preferably, memory device 130 is manufactured such that the root secret is not available outside of memory device 130 after its manufacture.

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

[0200] After memory device 130 leaves the manufacturing facility, the root secret and other secrets in device identity data 211 are not accessible via the communication interface of memory device 130 (e.g., host interface 147). Because memory device 130 enforces a set of data access policies to prevent the leakage of secrets and tampering of data stored in access-protected areas of memory device 130, memory device 130 can be considered a secure memory device. Secure server 140 stores information that can mimic the calculations performed by memory device 130 to generate derived secrets independently of memory device 130. Therefore, secure server 140 can regenerate the derived secrets of memory device 130 without requiring memory device 130 to transmit the derived secrets via its communication interface (e.g., host interface 147).

[0201] For example, the root secret of the memory device 130 can be implemented via a physically unclonable function (PUF). The root secret of the memory device 130 can be retrieved from the memory device 130 and stored in the secure server 140 for use in memory registration 231 during the manufacture of the memory device 130. The root secret can be used to generate a derived secret from the 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 secure server.

[0202] For example, the device identity data 211 may be used Figure 2 technology generation.

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

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

[0205] After the memory device 130 leaves the manufacturing facility, derived secrets in the device identity data 211 may be generated and / or replaced. Access control keys 213 may be used to control the execution of operations to generate and / or replace derived secrets to prevent tampering. For example, derived secrets may include encryption keys and / or certificates generated according to the Device Identity Composition Engine (DICE) standard.

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

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

[0208] For example, access control key 213 may be used to authenticate a digital signature applied 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 may 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 for specific operations (e.g., writing, erasing, reading). The owner and other authorized users may have different scopes and / or permissions to operate the memory device 130.

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

[0211] Optionally, specific security features of the memory device 130 can be customer-activated. Some aspects of the memory device 130 related to activation of security features can be found in U.S. patent application Ser. No. 17 / 014,203, filed Sep. 8, 2020, and entitled “Customer-Specific Activation of Features in a Semiconductor Device,” the entire disclosure of which is hereby incorporated by reference herein.

[0212] Endpoint 150 may be constructed to include memory device 130 and other components 187. During 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 including memory device 130, or an operating system or software application for endpoint 150. Soft module 217 may include instructions and data configured to implement functionality. The instructions may be executed by logic circuitry of memory device 130, a controller of a memory subsystem in which memory device 130 is installed, and / or a processing device 118 of a host system 120 in which memory device 130 and / or memory subsystem is installed.

[0214] During endpoint configuration 233, endpoint registration 235 can be performed to store tracking data 215 in secure server 140 and / or memory device 130. Tracking data 215 can be part of endpoint 150's configuration and / or identity.

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

[0216] A counterfeit endpoint 150 does not have tracking data 215 and cannot pass endpoint authentication 239, which relies on tracking data 215. Therefore, the security of the system is improved. Further details and examples of techniques related to tracking data 215 can be found in U.S. patent application Ser. No. 17 / 005,565, filed on August 28, 2020, and entitled "Secure Memory System Programming for Host Device Authentication," the entire disclosure of which is hereby incorporated by reference herein.

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

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

[0219] The operations of virtual card registration 237 may be performed to configure endpoint 150 for services of a card-based services network 225 , such as a mobile / cellular communications network, a bank card processing network, or the like.

[0220] For example, endpoint 150 may connect to card server 223 to request a card profile 219 for endpoint 150 represented by device identity data 211. To request card profile 219, endpoint 150 transmits the public 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 card profile may be obtained using a combination of Figure 2 Discussed authentication technology.

[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 of the memory device 130, the 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 can assign and / or store the card profile 219 to the memory 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 soft module 217 in the memory device 130 and / or via a security manager, so that the card profile 219 stored in the memory device 130 cannot be tampered with. Optionally, the security server 140 can generate a verification code for the command 155 used to write the card profile 219 to the secure section of the memory device 130. The write permission of the secure section can be controlled via an encryption key stored in the security server 140. For example, the access controller 109 can use the 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 memory device 130.

[0223] Additionally, the memory device 130 may Figure 4 The integrity of the card profile and / or the soft module 217 responsible for using the card profile 219 is verified in the manner shown in FIG.

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

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

[0226] For example, the card profile 219 may be as follows Figure 7 and Figure 8 As shown in .

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

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

[0229] Card data 241 may include identification of a smart card (e.g., a virtual card), an account, and / or a subscriber. For example, card data 241 may identify the type of smart card, the services to which the account / card subscribes, and / or customer data related to the services (e.g., balance, transaction history, messages, etc.). In some embodiments, card data 241 may include the same set of data stored in a 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 operating on the card data 241 via the cryptographic engine 107 of the memory device 130. For example, the computing functions of an integrated circuit chip for a particular type of smart card may 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 emulate the computing operations of a physical smart card.

[0231] Figure 8 A card profile of a virtual subscriber identity module (SIM) is shown according to one embodiment.

[0232] exist Figure 8 In the embodiment, the card profile 245 includes card data 241, such as an integrated circuit card identifier (ICCI) 251, a mobile equipment identity number 253, an international mobile subscriber identity number 255, an authentication key 257 assigned to the international mobile subscriber identity number 255, and service data 247 related to the mobile / cellular communication service of the international mobile subscriber identity number 255.

[0233] In traditional mobile phones using traditional SIM cards, an integrated circuit card identifier (ICCI) 251 is used to identify a SIM card within a group of SIM cards. A 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 within a group of mobile phones. An International Mobile Subscriber Identity (IMSI) number is used to identify a subscriber / customer / account within a group. When a card profile 245 is attached to an endpoint 150, such numbers in the card profile 245 can be used for similar functions. For example, when endpoint 150 is a mobile phone without a physical SIM card, the card profile 245 can function 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 within a mobile / cellular communication network.

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

[0235] For example, when card profile 245 is installed in endpoint 150, endpoint 150 can communicate with a mobile / cellular network operator to request a 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 have to distinguish between endpoint 150 with card profile 245 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 cryptographic engine of the secure memory device 130 and / or the processing device 118 of the endpoint 150 to perform cryptographic calculations during 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 , after virtual card registration 237, endpoint 150 can receive services from card-based service network 225 using card profile 219 to identify the subscriber / customer / account. For example, card-based service network 225 initially configured to provide services to traditional smart cards can seamlessly further provide services to endpoints (e.g., 150) having virtual smart cards implemented by storing card profiles (e.g., 219) in a secure memory device (e.g., 130).

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

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

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

[0241] Optionally, card profile 219 can be stored in association with endpoint identity data 188 in card server 223. Endpoint 150 can use endpoint identity data 188 to access services 227 in card-based services network 225. In response, card-based services network 225 can 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 can communicate with security server 140 to perform endpoint authentication 239 to verify that endpoint 150 has secure memory device 130 and the same configuration as indicated by the combination of tracking data 215, soft module 217, and component 187 at the time of virtual card registration. If endpoint 150 is tampered with and / or modified, the change can be detected in status check 229 and / or endpoint authentication 239; in response, card-based services network 225 can deny the request to access services 227.

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

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

[0244] In some embodiments, the card server 223 is implemented as part of a network operator of the card-based services 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 IoT service ecosystem. For example, a virtual subscriber identity module (SIM) card can be used by an IoT device (e.g., endpoint 150) to connect to the Internet through a mobile / cellular communication network.

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

[0247] The complexity of enterprise IoT implementations creates challenges for large-scale global deployment of IoT devices. Challenges include implementation difficulties in cellular connectivity and network security. Cellular connectivity offers significant advantages over wireless local area networks (e.g., Wi-Fi) for IoT deployments, such as longer range, better outdoor performance, stronger security, and an existing global infrastructure. The requirement for physical SIM cards and contracts with mobile / cellular network operators slows down the adoption of cellular connectivity by IoT devices. Figure 6 The solution shown addresses such challenges.

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

[0249] like Figure 6 The solution shown is particularly beneficial for the industrial, infrastructure, automotive, aviation, transportation and logistics sectors, which need to provide borderless long-range connectivity to portable devices even in the most remote locations, without the limitations of borders and short-range Wi-Fi networks.

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

[0251] The use of physical smart cards requires close pairing of the card identity and / or device identity with the services provided by the network (eg, 225) during manufacturing to prevent unsecured devices, unsecured operations, fraud, and / or counterfeiting.

[0252] The security server 140 may be used to implement zero-touch authentication and late binding of certificates 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 the card server 223 can be used to securely install soft modules to customize IoT devices. For example, an online soft module store can be provided to allow soft modules to be stored on the endpoint 150 to customize its functionality in a manner similar to the functionality provisioning of different types of smart cards and / or SIM cards discussed above. This customization allows enterprises to access vendor-agnostic IoT services and utilize and experiment with intelligent features and data insights in new ways.

[0254] As the threat landscape becomes increasingly dangerous with sophisticated bad actors and hacker attacks on devices ranging from IoT fish tanks to baby monitors, cybersecurity remains a weak link in IoT adoption. Secure server 140 can provide security-as-a-service, supported by security features implemented in memory devices (e.g., 130) that control access and device identity data 211. Through its silicon root of trust, secure memory device 130 provides a unique level of protection for the lowest layers of IoT software—starting with the boot process, and with its own strong cryptographic identity and security features within memory device 130.

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

[0256] For example, security as a service may optionally further include identifying the owner of the memory device 130 based on a cryptographic key corresponding to the access control key 213 implemented to provide owner privileges.

[0257] For example, security as a service may optionally further include identifying a service provider for endpoint 150 having memory device 130 based on the identity of the owner / manufacturer of memory device 130 before distributing endpoint 150 to an end user / customer. Based on the service provider, security server 140 may download a soft module 217 related to the services provided by the service provider to customize endpoint 150. For example, customization may be performed during endpoint registration 235. Optionally, the end user or enterprise user may select a service provider, and security server 140 and / or card server 223 may push the soft module 217 to memory device 130. Furthermore, in response to endpoint authentication 239, security server 140 may automatically push software updates to the memory device. Thus, security vulnerabilities of field endpoints (e.g., 150) may be automatically reduced and / or minimized without requiring additional effort from the respective OEM of the endpoint (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 of an endpoint 150 registered as lost or stolen with security server 140, security server 140 may request access controller 109 of memory device 130 to disable access to and / or erase data from a specific memory area. In some cases, access controller 109 may disable normal operations of endpoint 150 by restricting access to resources such as boot loaders, operating systems, and applications. In some cases, access controller 109 may perform operations that irreversibly destroy the memory functionality of memory device 130.

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

[0260] When an updated version of soft module 217 is available, security server 140 can recalculate endpoint identity data 188 for authentication of endpoint 150. Thus, when endpoint 150 has an outdated soft module 217, security server 140 can detect the presence of the outdated version and request / initiate an update of soft module 217 over the air. Optionally, security server 140 can track a history of configuration changes to endpoint 150 that affect endpoint identity data 188. For example, when requested, security server 140 can communicate with memory device 130 to revert to a previous configuration.

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

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

[0263] When endpoint 150 attempts to connect to card-based service network 225, the public identity of endpoint 150 (e.g., IMEI number) is authenticated in endpoint authentication 239 using endpoint identity data 188. In response, the subscription registered to International Mobile Subscriber Identity number 255 is identified and used to generate card profile 219 to bind card profile 219 to endpoint 150. Binding can be in the form of storing card profile 219 in secure memory device 130 in endpoint 150. Alternatively, binding can be in the form of associating 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 to achieve cellular connectivity. For example, the enterprise client's IoT devices may not require cellular connectivity at the same time. When the enterprise client's endpoint 150 requires cellular connectivity, an available card profile 219 representing the virtual SIM card is dynamically "installed" for the endpoint 150 after endpoint authentication 239 during the communication session for immediate use with cellular service. When the communication session ends, the virtual SIM card can be used by another endpoint of the enterprise client. Physical SIM cards 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 SIM cards from one mobile phone to another is inefficient and impractical for large-scale deployment. The instant installation of virtual SIM cards can overcome the limitations of physical SIM cards and provide 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 a cellular connection. For example, the cellular connection can be used to perform over-the-air firmware / software updates. For example, the cellular connection can be used to periodically report the status of the endpoint 150 (e.g., daily, weekly, or monthly). For example, the endpoint 150 can report its health and / or location in connection with warranty service based on the location of the endpoint 150.

[0266] For example, security as a service may optionally further include identity services that allow 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 card-based service network 225 using the alternate public identity number in 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 the device represented by the IMEI number.

[0267] When such a secure memory device 130 is used together 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 having to perform its own separate security operations, such as secure key injection, designing and implementing secure elements, hardware components, or dedicated system-on-chip (SoC) features. Therefore, the secure server 140 and the secure memory device (e.g., 130) can provide plug-and-play security for the OEM of the IoT device (e.g., endpoint 150).

[0268] The services of the 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 from the manufacturing supply chain to field installation and management to achieve platform hardening and device protection throughout the entire life cycle.

[0269] Figure 9 A technique for authenticating a memory device according to one embodiment is shown. For example, Figure 9 The technology can be used to Figure 2 Identity data implementation Figure 5 security services.

[0270] pass Figure 9 By performing an authentication operation, a session key 263 can be established to protect communications between the secure server 140 and the memory device 130, without trusting the client server 141 to handle security to protect the secrets of the memory device 130. Optionally, the session key 263 can be used by the access controller 109 to enforce permissions to request selected commands 155 to be executed in the memory device 130.

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

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

[0273] In response to the request 271 for the identity data 113 of the memory device 130 , the memory device 130 provides a response 273 including a message that includes the unique identification 111 identifying the memory device 130 .

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

[0275] To protect response 273 and / or verification code 133 from security attacks (e.g., reuse of response 273 and / or attempts to recover key 137), verification code 133 is generated for message 131 containing unique identification 111, counter value 265, and cryptographic nonce 267. Counter value 265 is obtained from counter 261 in memory device 130. The value of counter 261 increases monotonically. For example, counter 261 may be used to store a value representing a count of requests received for identity data and / or other security-related data items or operations. Therefore, a response containing a counter value 265 that is lower than a previously seen counter value may be considered invalid. Cryptographic nonce 267 is used once in generating response 273 and is discarded by memory device 130. If cryptographic nonce 267 has been previously provided to or generated by security server 140, response 273 need not explicitly include cryptographic nonce 267 in response 273.

[0276] The client server 141 forwards the response 273 to the secure server 140 to request authentication of the memory device 130. Using the unique identification 111 provided in the response 273, the secure server 140 can locate the corresponding encryption key 106 to verify the authentication code 133. For example, the corresponding encryption key 106 can be the secret key 137, or the corresponding public key when asymmetric encryption is used.

[0277] Based on the verification of the verification code 133, the secure server 140 provides an authenticity indicator 275 to the client server 141. The authenticity indicator 275 indicates whether the memory device 130 is authentic. For example, the secure server 140 may generate and provide a certificate signed by the secure server 140 to extend the certificate chain of the memory device 130 back to the verifier (e.g., the secure server). Optionally, the secure server 140 may allow downloading of a certificate signing request (CSR), which allows the requester to use a certificate authority (CA) of their choice (rather than the secure server 140).

[0278] By authenticating the memory device 130, the memory device 130 and the security server 140 can establish a session key 263 for communicating with each other in subsequent communication sessions. The session can be limited to a predetermined time period after the response 273 or verification of the verification code 133. After the time period, the session key 263 expires and can be destroyed or discarded. In addition, a subsequent request for identity data can end a previous session started by a previous request for identity data.

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

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

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

[0282] Figure 10 A technique for generating commands to control secure operations of a memory device according to one embodiment is shown. 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 to be verified using client permission data 283 , secure server 140 may provide verification code 153 for command 155 to client server 141 in response to request 281 from client server 141 .

[0284] Figure 9 and Figure 10 For example, in some cases, request 281 may include identity data 113 provided by memory device 130 as response 273 to request 271 of memory device 130 .

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

[0286] As discussed above, verification code 153 may be implemented using techniques such as hash digests, digital signatures, and / or hash-based message authentication codes. Verification of verification code 153 may be performed by access controller 109 using access control key 149 for command 155. Verification code 153 may be generated using encryption key 277 stored in security server 140, which represents permission to execute command 155 in memory device 130. For example, when encryption via asymmetric encryption is not used, encryption key 277 may be access control key 149; alternatively, when asymmetric encryption is used, access control key 149 is the public key in a key pair, while 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 of 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 the verification code 153 is based on the session key 263, the verification code 153 expires when the session key 263 expires, which prevents the verification code 153 from being reused outside of the session in which the session key 263 is valid.

[0289] The message 151 provided in the request 285 may include the command 155 and the cryptographic nonce 287. The cryptographic nonce 287 is arranged for use with the command 155 / request 285 and is therefore different from the cryptographic nonce 267 used to transmit the identity data of the memory device 130.

[0290] For example, in response to request 281, secure server 140 may generate a cryptographic nonce 287 and use it to generate verification code 153. Cryptographic nonce 287 may be provided with verification code 153 for client server 141 to generate request 285. Alternatively, client server 141 may generate cryptographic nonce 287 and provide it to secure server 140 along with request 281. Alternatively, client server 141 may request cryptographic nonce 287 from secure server 140 to generate request 281.

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

[0292] For example, command 155 may be configured to activate a security feature of memory device 130 .

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

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

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

[0296] In some embodiments, the replacement secret key is transmitted from the memory device 130 to the secure server 140 in encrypted form in a ciphertext generated using the session key 263 .

[0297] Figure 11 A method for 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 As shown in the above combination Figure 1-5 The security features of the secure server 140 and the memory 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 an integrated circuit package of the memory device 130 based at least in part on a root secret of the memory device 130 .

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

[0300] For example, the logic circuitry or controller may include a cryptographic engine configured to perform cryptographic calculations without using a processor external to the integrated circuit package.

[0301] At block 303 , the memory device 130 stores the 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 , logic circuitry controls access to the first memory region based on the access control key 213 .

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

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

[0305] At block 309 , the card profile 219 is written to the integrated circuit memory cells of the memory device 130 to emulate the functionality of a smart card based on the card profile 219 .

[0306] For example, endpoint 150 may be configured via memory device 130 to generate endpoint identity data 188 that represents the configuration of components of endpoint 150 at the time of its boot-up. Endpoint identity data 188 may be calculated using device identity data 211, trace data 215 stored in memory device 130 during configuration 233 of endpoint 150, and identification data of components of endpoint 150 that are located outside the integrated circuit package of memory device 130.

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

[0308] For example, card profile 219 may include a soft module (eg, soft card module 243, authentication module 259) having instructions executable by logic circuitry or a processor of endpoint 150, or any combination thereof, to emulate the functionality of a smart card.

[0309] For example, the card profile 219 may be stored in the memory device 130 to emulate a subscriber identity module (SIM) card that is typically used to authenticate a mobile phone when accessing a cellular communication network. For example, the card profile 219 may include 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 number 255, the mobile / cellular network operator may issue a security challenge to authenticate endpoint 150. In response, card profile 219 may be used to generate a response to the security challenge by signing a message with a random number using authentication key 257 to prove that the endpoint possesses authentication key 257. For example, the message with the random number may be signed using authentication key 257. The response to the security challenge may include a portion of a digital signature used for authentication; another portion of the digital signature may be used as a symmetric encryption key for encrypting the communication session associated with the cellular connection.

[0311] Figure 12A method for providing security services based on security features of a memory device according to an embodiment is shown. For example, Figure 12 The method can be used Figure 9 and 10 The technology is based on the above Figure 1-5 The security features of the memory device 130 discussed are Figure 1 is implemented in a computing system.

[0312] At block 321 , the secure server 140 receives a request (eg, 173 and / or 281 ) from the client server 141 . The request includes the identity data 113 of the memory device 130 having access to the controller 109 .

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

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

[0315] At block 325 , the secure server 140 generates a verification code 153 for the command 155 .

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

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

[0318] At block 327 , the secure server 140 transmits a response 174 containing the verification code 153 to the client server 141 .

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

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

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

[0322] For example, when executed in memory device 130 , command 155 causes access control key 149 to be changed for use by access controller 109 to verify a verification code (eg, 153 ) generated using encryption key 145 , which represents 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 activation of a security feature of memory device 130 or deactivation of a security feature.

[0324] For example, command 155 , when executed in memory device 130 , causes memory device 130 to disable a boot loader stored in memory device 130 after endpoint 150 containing memory device 130 has been reported lost or stolen.

[0325] For example, when executed in the memory device 130 , the command 155 causes the access controller 116 to prevent access to one or more sectors of the memory unit 103 in the memory device 130 .

[0326] For example, when executed in the memory device 130 , the command 155 causes the memory device 130 to clear the decryption key of the data stored in the 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 verification of the identity data 113, the session key 263 can be established and known between the security server 140 and the memory device 130 without transmitting the session key 263 via the connection between the security server 140 and the memory device 130. The access control key 149 used by the access controller 109 to verify the verification code 153 of the command 155 can be based on the session key 263.

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

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

[0331] At block 341, the server system receives a request (e.g., 171 and / or 173) associated with a service from endpoint 150. The service is provided via a computer network (e.g., network 110) that serves multiple subscribers represented by different accounts. The request includes identity data 113 generated by 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 in communication with the security server 140.

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

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

[0335] At block 345 , based on the identity data 113 , a subscriber is identified among a plurality of subscribers based on ownership data of the endpoint 150 .

[0336] For example, during the manufacture of endpoint 150 (e.g., 150) at the facility of its manufacturer, memory device 130 is connected to host system 120, and a software package for the operation of endpoint 150 is installed in memory device 130. Endpoint 150 is tested. In endpoint registration 235, memory device 130 is configured to generate a key 137 that not only represents memory device 130 with unique device secret 101, but also represents endpoint 150 with memory device 130 having data 123 in memory unit 103 and data 125 from host system 120 at boot time.

[0337] When endpoint 150 is transferred from the manufacturer to the distributor and end user or subscriber, data associating the public identification of endpoint 150 with the identity of the subscriber is stored in the server system. Ownership data can be stored in the server system without physically manipulating 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 identification 111 of 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 may be associated with the account.

[0339] For example, client authority data 283 may include ownership data of endpoint 150 and / or subscriber data showing a subscriber account.

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

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

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

[0343] In some embodiments, client authority data 283 stored in secure server 140 indicates an association between a subscriber's identity data 113 and an account. Thus, during verification of the authenticity of endpoint 150 based on received identity data 113, the account can be identified from client authority data 283.

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

[0345] use Figure 13 In this manner, services subscribed to an account can be provided / directed to endpoint 150 without customizing endpoint 150 itself for the subscriber and / or the subscriber's account. For example, a subscriber can simply open the package enclosing endpoint 150 during the manufacture of endpoint 150 and use endpoint 150 to access services subscribed to 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 manufactured, prior to the request received in block 341, endpoint 150 is not customized for a subscriber and is not customized for an account. Endpoint 150 is manufactured to be usable by any of a plurality of subscribers. In response to the request received in block 341, endpoint 150 is automatically linked to the specific account of the subscriber receiving the service.

[0347] For example, endpoint 150 contains no hardware components inserted into endpoint 150 to represent the subscriber, the account, or any combination thereof, before and / or after receiving service for the subscriber's account.

[0348] For example, at least prior to the request received in block 341 , endpoint 150 contains no data stored in endpoint 150 representing a subscriber, an account, or any combination thereof.

[0349] For example, at least prior to the request received in block 341 , endpoint 150 has no indication of a subscriber, account, or any combination thereof, and no ownership data for endpoint 150 ; and the ownership data is stored in the server system and not in endpoint 150 .

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

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

[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 part of device information 121 used to generate secret key 137 when generating updated identity data 113. For example, the additional data may be included in data 127 of message 131 in updated identity data 113 generated by memory device 130 after execution of the command. For example, the additional data may include card profile 219 identifying the subscriber's account.

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

[0354] Because no operations are required on endpoint 150 to direct services for a subscriber's account to endpoint 150, endpoint 150 can be configured as an IoT device with cellular connectivity without requiring a user interface for customizing it to receive cellular connectivity services. For example, endpoint 150 can be configured without a slot for inserting a card to identify the subscriber. For example, endpoint 150 can be configured without a user interface for receiving input from the end user to identify the subscriber.

[0355] In some embodiments, endpoints 150 have a common hardware configuration that can run different firmware to provide different functionality. Furthermore, updated versions of firmware can be installed in endpoints 150 to correct defects or errors in endpoints 150 running previous versions of firmware, to improve performance, and / or to provide new functionality. Optionally, firmware applications can be run on top of the base version of firmware to add functionality, features, and / or services.

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

[0357] The endpoint 150 may be customized for different client servers 141 , . . . , 143 after being assembled by installing different firmware and shipped to end users or subscribers.

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

[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 be dependent on services provided by a client server or a service provider.

[0360] The functionality of endpoint 150 may be at least partially defined by its firmware. For example, when endpoint 150 runs one version of firmware, endpoint 150 may provide one functionality to a user of endpoint 150; and when endpoint 150 runs another version of firmware, endpoint 150 may provide different functionality to a user of endpoint 150.

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

[0362] Secure server 140 may be coupled to an online firmware store to provide firmware updates to an endpoint (eg, 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 the online firmware store and installed on endpoint 150 via an over-the-air (OTA) update.

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

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

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

[0367] For example, a user of endpoint 150 can access an online store to subscribe to a service provider's services, change subscribed services, and / or move subscriptions from one service provider to another. The subscriptions that the user has subscribed to for endpoint 150 can be tracked as part of client entitlement data 283 associated with the identity of endpoint 150. When security server 140 verifies endpoint 150's identity data 113, security server 140 can check whether endpoint 150 requires a firmware update for the subscribed services and / or to replace an outdated version of firmware. If so, security server 140 can customize and / or update endpoint 150 with the firmware update 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 connects endpoint 150 to the service provider's current client server 141.

[0368] Generally speaking, the secure server 140 can be connected to or include an online service store and / or an online firmware store. The server system can include the secure server 140, the online service store, and / or the online firmware store. The server system can track accounts used to subscribe to services from different service providers and track firmware customizations selected / purchased by users of endpoints (e.g., 150).

[0369] The user's account of endpoint 150 and the service provider subscribed to endpoint 150 can be tracked using the user's identity 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 an online service store and / or online firmware store 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 identification of endpoint 150 as part of endpoint 150's identity data 113.

[0370] In some embodiments, endpoint 150 initially connects to secure server 140 for service. Secure server 140 can identify the current provider of subscription services registered in the online service store based on client authority data 283. After verifying the authenticity of endpoint 150 and determining the service provider, secure 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 services ordered from the online service store with minimal user effort.

[0371] Figure 14 An endpoint customization technique using an online firmware store according to one embodiment is shown. For example, Figure 14 The technology can be used in reference Figures 1 to 5 Security services and features discussed Figure 1 and / or Figure 6 is implemented in a computing system. Figure 14 The technology can be used with Figures 9 to 13 Use a combination of technologies.

[0372] exist Figure 14 , online firmware store 170 is configured to facilitate selection of firmware and / or firmware applications for endpoint (eg, 150 ) customization and / or updating, and verification of the identity of the endpoint (eg, 150 ) by secure server 140 .

[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 endpoint 150's host system 120.

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

[0375] Generally speaking, a firmware update for endpoint 150 may be replacing the entire firmware 363 executing in host system 120 or adding and / or replacing one or more firmware applications (eg, applications 367, ..., 369).

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

[0377] In some embodiments, firmware 363 can be customized via one or more firmware applications (e.g., applications 367, ..., 369). For example, an endpoint 150 running firmware 363 can further run optional applications (e.g., applications 367, ..., or 369) to provide new functionality not present in firmware 363, disable existing functionality in firmware 363, change or customize existing functionality 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 a service provider's client server 141 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 in a different manner 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 the different service provider.

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

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

[0381] For example, a firmware application (e.g., application 367) may be programmed to communicate with client server 141 to obtain services provided via client server 141. Examples of services of client server 141 include computing resources of client server 141 to process data for endpoint 150, data storage facilities of client server 141 for data generated by endpoint 150, messaging facilities for notifications and / or alerts to one or more other devices associated with endpoint 150, connectivity via client server 141 and one or more other devices associated with endpoint 150, internet access for endpoint 150 via a Wi-Fi access point, communication satellite, and / or communication connection or device controlled by client server 141, and the like.

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

[0383] Optionally, the baseline version of firmware (e.g., 363) can provide a set of standardized functions, upon which firmware applications (e.g., applications 367, ..., 369) can operate. Thus, the same firmware application (e.g., application 367) can be installed to customize endpoints (e.g., 150) having 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 having different hardware implementations to provide the same customized functions for the respective endpoints and / or the same services for client server 141.

[0384] The use of firmware applications (e.g., applications 367, ..., 369) can reduce the size of data to be downloaded from firmware store 170 to endpoint 150 when performing a firmware update. Alternatively, different sets of firmware functions can be implemented using different firmware (e.g., 363, ..., 365) without the need for additional firmware applications. Generally speaking, a firmware update in endpoint 150 can 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 a user of endpoint 150 to select and / or order 371 firmware 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 secure server 140 may store data indicating a desired firmware configuration and / or requested service for endpoint 150. For example, client entitlement data 283 may be updated to reflect the firmware and / or service selections made using user computer 180.

[0386] Generally speaking, user computer 180 can be distinct and separate from endpoint 150. Thus, no hardware and / or software interface is required that can be accessed by a user of endpoint 150 to customize endpoint 150 for use with an account and / or service provider. Optionally, some embodiments and / or classes of endpoint 150 can include a user interface that allows it, as user computer 180, to order 371 firmware for endpoint 150.

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

[0388] For example, endpoint 150 may be identified via a public identification of endpoint 150 , such as the model and serial number of endpoint 150 , mobile equipment identity number 253 , international mobile subscriber identity number 255 , unique identification 111 , and / or another identifier included in data 127 of identity data 113 .

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

[0390] The security server 140 may verify 373 the identity data 113 submitted from the endpoint 150 and / or its memory device 130, as described above in conjunction with Figure 2 、 5 and 9 discussed above.

[0391] In general, identity data 113 may be submitted to secure server 140 via a client server (e.g., 141 or 143), via firmware store 170, via another server or gateway, or without passing through any of client servers 141, ..., 143 and firmware store 170.

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

[0393] For example, when a server (e.g., client server 141 or 143, firmware store 170, or another server) receives a request 171 for identity data 113 from endpoint 150, the server (e.g., 141) provides identity data 113 to secure server 140 in request 173 for verification. In response to such request 173, secure server 140 may communicate with firmware store 170 to identify 375 whether a firmware update is available for endpoint 150. If so, secure server 140 may cause firmware store 170 to update 377 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 memory device 130, a command 155 signed using cryptographic key 145 is executed in memory device 130, causing the new version of firmware and / or firmware application (e.g., application 367) to execute in memory device 130 and become part of the identity of memory 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 provided in firmware store 170 for accessing the same service of client server 141, secure server 140 may initiate installation of the new version in response to successful verification of identity data 113. Optionally, update 377 may be implemented via installation of a firmware application (e.g., application 367) running on existing firmware 363, or via installation of new firmware (e.g., 365).

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

[0396] In some cases, endpoint 150 first accesses secure server 140 . After secure server 140 verifies 373 the identity of endpoint 150 , secure server 140 may communicate with online firmware store 170 to identify 375 a firmware update for endpoint 150 .

[0397] In general, a firmware update may include installing a firmware application (eg, application 367 ), replacing an existing firmware application with another firmware application, and / or installing new firmware 365 .

[0398] After identifying a desirable firmware update, firmware store 170 communicates 377 with endpoint 150 to update endpoint 150 .

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

[0400] For example, after the data required for the firmware update is stored in the section of the memory device 130, a command 155 may be sent to the host interface 147 to execute the firmware update operation in the memory device 130. The authority to execute the command 155 in the memory device 130 may be represented by the encryption key 145. The encryption key 145 may be previously configured or generated in response to verifying the identity data 113 of the memory device 130 from the endpoint 150. For example, the encryption key 145 may be based on verifying the authenticity of the endpoint 150 in a manner similar to Figure 9 and secure server 140 may use encryption key 145 to generate verification code 153 of a command for firmware store 170 to update endpoint 150. Alternatively, secure server 140 may provide session key 263 and / or encryption key 145 to firmware store 170 to update 377 the firmware of 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 application. For example, a hash value 163 of the installed firmware and / or firmware application may be stored as part of the device information 121 to verify their integrity, such as Figure 4 Subsequently, identity data 113 generated by memory device 130 of endpoint 150 is based on updated device information 121 and reflects the configuration of endpoint 150 with updated firmware functionality or configuration.

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

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

[0404] Figure 15A technique for directing services to endpoints via an online service store according to one embodiment is shown. For example, Figure 15 The technology can be used with Figure 14 Use a combination of technologies.

[0405] exist Figure 15 , online service store 190 is configured to facilitate selection of a service for endpoint 150 from a plurality of services provided by one or more service providers (e.g., 381). The services of the service provider (e.g., 381) can 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 online service store 190 to order 391 services from service provider 381 using computer 180. The services provided by service provider 381 can be used with endpoints of multiple endpoint platforms (e.g., 361, ..., 362). The endpoints (e.g., 150) in the endpoint platforms (e.g., 361, ..., 362) run different firmware to obtain the services of service provider 381. Service store 190 has subscription data 387 that identifies the services and / or endpoints (e.g., 150) to which the subscriber has subscribed.

[0407] For example, the services provided by service provider 381 may be implemented via client server 141; and subscription data 387 may identify a server to connect to for the endpoint to receive the services to which the endpoint is subscribed, respectively.

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

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

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

[0411] When endpoint 150 is implicitly subscribed to services, the subscriber's identity may be used to determine the subscriber's endpoint's services based on a match between the subscriber's identity used to subscribe to the services and the identity of the owner of endpoint 150 .

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

[0413] In response to services being ordered or changed, or in response to identity data 113 of endpoint 150 being verified, secure server 140 and service store 190 may communicate with each other to identify 393 the services to which endpoint 150 is subscribed.

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

[0415] In general, the service request 171 may be initially received in a client server (eg, 141 or 143 ) or in the service store 190 or firmware store 170 or directly in the secure server 140 .

[0416] After security server 140 verifies 373 the identity and authenticity of endpoint 150 , security server 140 may identify 393 the services to which endpoint 150 is subscribed based on client authority data 283 stored in security server 140 and / or based on subscription data 387 in service store 190 .

[0417] Based on the identified services, the secure server 140 may communicate with the firmware store 170 to identify 375 firmware updates for the endpoint 150. For example, the endpoint 150 may be updated by replacing the firmware or installing a firmware application (e.g., application 367) to customize the endpoint 150 for the subscribed service. Figure 14 to be implemented and protected in the manner discussed.

[0418] For example, endpoint 150 may be manufactured using a generic version of firmware 363 that is not capable of receiving services from service provider 381, is unaware of client server 141 for services provided by service provider 381, and / or does not implement a communication protocol for communicating with client server 141. A firmware application (e.g., application 367) may be installed and run on generic firmware 363 to customize endpoint 150 for the services subscribed to endpoint 150. Once customized via the firmware application (e.g., application 367), endpoint 150 may receive services from service provider 381 from client server 141. For example, after installing the firmware application (e.g., application 367) to update 377 the firmware, endpoint 150 may have 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 utilizing the services provided by client server 141.

[0419] For example, the services subscribed to for the operation of endpoint 150 may include computations performed by client server 141 to process data for endpoint 150, storage of data generated by endpoint 150 in client server 141, sending notifications and / or alerts to one or more other devices associated with endpoint 150, connecting via client server 141 and one or more other devices associated with endpoint 150, connecting endpoint 150 to a computer network or the Internet using a cellular base station, a Wi-Fi access point, a communication satellite, and / or a communication connection or device controlled by client server 141, and the like.

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

[0421] Generally speaking, service store 190 can be used by a user (or a user's representative) to subscribe endpoint 150 to services from service provider 381, change subscribed services, and move subscriptions from one service provider 381 to another. The firmware 363 of endpoint 150 is automatically updated to support the currently subscribed services without requiring the user of endpoint 150 to operate endpoint 150 to customize endpoint 150 for the subscribed services.

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

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

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

[0425] For example, endpoint 150 may be in a state shipped from a manufacturer of endpoints (eg, 150) without customization for a particular server and / or service provider.

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

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

[0428] At block 405, an update of 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 in the endpoint 150 to generate the request received in block 401.

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

[0430] For example, the public identification of endpoint 150 may be used to identify order 391 for endpoint 150. Identity data 113 may include the public identification in message 131 signed using secret key 137 to generate verification code 133 provided in identity data 113. After verifying that message 131 has not been altered, secure server 140 may instruct online firmware store 170 and / or endpoint 150 to update 377 firmware 363 for endpoint 150.

[0431] At block 407 , in response to determining that the endpoint 150 is authentic, the server system generates a verification code 153 of a command 155 executable in the memory device 130 to perform the update.

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

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

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

[0435] For example, the data downloaded to memory device 130 may include a firmware application (e.g., application 367) that, after executing command 155 for a firmware update, runs using the first firmware that was executed to generate the request. 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 may 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 377 the firmware, device information 121 is updated to include a hash value 163 of the second firmware stored as content 161 in memory unit 103. Subsequently, memory device 130 is configured to generate identity data 113 for endpoint 150 using an encryption key generated at least in part based on the memory device's secret (e.g., unique device secret 101) and the second firmware stored in memory device 130.

[0438] Figure 17 An endpoint customization method using a service store and a secure server according to one embodiment is shown. For example, Figure 17 The method can be used Figure 14 and Figure 15 technical implementation.

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

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

[0441] At block 423, the security server 140 verifies the identity data 113 in response to the request received in block 421 and based on information about the endpoint 150 stored in the security server 140. Such information includes secrets of the memory device 130, such as the unique device secret 101. Such information may further include device information 121 representing the software / hardware configuration of the endpoint 150. Verification may be combined with the above Figure 2 Execute in the manner discussed.

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

[0443] At block 427 , a client server 141 configured to provide the service is identified.

[0444] For example, before receiving the request in block 421 , the online service store 190 may receive an order 391 for services from the endpoint 150 . The client server 141 may be identified based on the order 391 .

[0445] For example, order 391 may be received in online service store 190 via user computer 180 and therefore not through endpoint 150. Order 391 for endpoint 150 may be identified / placed using the public identification of endpoint 150. Identity data 113 may include the public identification. Alternatively, order 391 may be associated with the identity of the user who is the owner of endpoint 150 in the client authority data 283 of the secure server.

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

[0447] For example, in response to determining that the identity data 113 in the request received in block 421 is valid, the server system may configure the 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 may update the firmware of endpoint 150. For example, the firmware update may be combined with the above Figures 14 to 16 Execute in the manner discussed.

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

[0450] For example, after firmware update 377, 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 an identification of client server 141 for directing the endpoint to access client server 141 for services ordered in online service store 190. In one embodiment, the second firmware is a combination of the first firmware and the 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, to configure endpoint 150 for services ordered in service store 190, server system identifies the account used to subscribe endpoint 150 to services. Memory device 130 is configured to store an identifier of the account and include the identifier in updated identity data 113 as part of message 131.

[0452] For example, to perform firmware update 377, the server system may generate a verification code 153 for command 155 using encryption key 145 that indicates permission to execute command 155 in memory device 130. When executed in memory device 130, command 155 causes the first firmware to be replaced with the second firmware. After memory device 130 receives command 155 and verification code 153, memory device 130 verifies verification code 153 against the permission before executing command 155.

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

[0454] The memory device 130 may store the content 161 in the memory unit 103 and separately store the hash value 163 as part of the device information 121, such as Figure 4When 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 include a core package of endpoint 150. The integrity of the core package may affect the operation of endpoint 150 when communicating with security server 140 when verifying 373 the identity of endpoint 150. Instances of the core package may include at least a portion of the boot loader, firmware, and / or operating system of endpoint 150. When the core package is modified, corrupted, or tampered with, the security of operations of endpoint 150 performed for authentication may not be trusted. When integrity status 165 generated by cryptographic engine 107 indicates a change in the core package, access controller 109 may prevent host system 120 from accessing content 161 until the core package is repaired.

[0456] For example, memory device 130 may store a reliable backup copy of the core package in a separate section; and when the hash value of the core package in content 161 stored in memory unit 103 differs from the corresponding hash value 163 of stored device information 121, memory device 130 may replace the core package stored in memory unit 103 with the copy stored in the separate section. Optionally, 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, secure server 140 may initiate an update (e.g., using firmware store 170) after verifying the identity data 113 of memory device 130 and / or endpoint 150 submitted via the replacement copy.

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

[0458] Optionally, data 127 provided in identity data 113 may include a current hash value of a packet stored in content 161 in memory unit 103. During the operation of verifying 373 identity data 113 of 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 is out of date, security server 140 may initiate repair or recovery of the packet.

[0459] In addition, some packets of endpoint 150 may be stored in another device that does not have the security features of memory device 130. Executing the core packet in host system 120 may generate a current hash value of the packet as a health indicator of the packet. 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 the integrity of the packet.

[0460] Generally speaking, identity data 113 may include data indicating the health of packages in endpoint 150. As part of verifying 373 identity data 113 of endpoint 150, security server 140 may determine whether to repair and / or update any packages. The repair or update may be performed before security server 140 confirms the authenticity of endpoint 150.

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

[0462] For example, an owner or user of endpoint 150 may request that security server 140 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 location information of endpoint 150 and / or the type of service requested by endpoint 150 via submission of identity data 113 .

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

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

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

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

[0468] Optionally, a parent may use the portal of security server 140 to set parental control preferences to restrict the activities of endpoint 150 ; and security server 140 may enforce the restriction preferences in conjunction with authenticating the identity of endpoint 150 .

[0469] Figure 18 A diagram illustrating the generation of identity data to facilitate monitoring of integrity and / or endpoint activity according to one embodiment.

[0470] For example, Figure 18 The technology can be used to Figures 1 to 5 Security services and features discussed Figure 1 and / or Figure 6 computing system. Figure 18 The technology can be used with Figures 9 to 17 Use a combination of technologies.

[0471] exist Figure 18 130, the endpoint 150 stores the packet 167 with the hash value 169. The packet 167 may be stored in the memory device 130 having the security features discussed above, or in another memory device of the endpoint 150 that may or may not have the security features of the memory device 130. When the packet 167 is stored in the memory device 130, the cryptographic engine 107 of the memory device 130 may calculate the hash value 169 of the packet 167 without relying on the processing device 118 of the host system 120 in the endpoint 150. When the packet 167 is stored outside the memory device 130, the hash value 169 may be executed by the processing device 118 of the host system 120 to verify that it is stored in the memory device 130 and has not been changed (e.g., as shown in FIG. 130). Figure 4 (in) routine to obtain.

[0472] In general, the packet 167 may include instructions and / or data, such as resources that may be the same for a group of endpoints (eg, 150 ) and configuration parameters that may be different for different endpoints (eg, 150 ).

[0473] Hash value 169 of packet 167 indicates the health of packet 167 .

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

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

[0476] For example, a healthy and up-to-date copy of package 167 may be stored in a server (e.g., secure server 140, firmware store 170, or another server) to facilitate repair or recovery of package 167 in endpoint 150. If hash value 169 extracted from identity data 113 differs from the hash value of the healthy and up-to-date copy, secure server 140 may perform a similar operation in conjunction with Figures 14 to 17 The update is initiated by way of update 377 of firmware 363 of endpoint 150 as discussed.

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

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

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

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

[0481] Alternatively, a secret key may be used with symmetric encryption to protect the personalization package 167. For example, the session key 263 generated during verification of the identity data 113 of the endpoint 150 upon successful configuration of the personalization package 167 in the endpoint 150 may be used to encrypt the personalization package 167 for transmission to and / or storage on a server (e.g., the secure server 140, the firmware store 170, or another server).

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

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

[0484] For example, activity information 177 may include the date and time that identity data 113 was generated.

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

[0486] For example, activity information 177 may include one or more attributes of the requested service, such as the category of service, identification of another party involved in the service, the quantity or amount involved in the service, and so on.

[0487] For example, when identity data 113 is submitted for a communication connection, the attributes may include identification of the type of connection, an indication of the connection, and the like.

[0488] For example, when identity data 113 is submitted for payment, the attributes may include identification of the purchase category, the payee, the payment amount, and the like.

[0489] Activity information 177 may be used by security server 140 to detect fraudulent activity, unauthorized use of endpoints, and to enforce activity restrictions (eg, as specified in parental control preferences), among other things.

[0490] To improve security and / or privacy protection, activity information 177 may be included in encrypted form in message 131. For example, session key 263 associated with the verification of identity data 113 may be used to generate a ciphertext of activity information 177; and upon successful verification of 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 A technique for maintaining the integrity of packets stored in an endpoint is shown according to one embodiment.

[0492] exist Figure 19 In FIG. 4 , endpoint 150 stores a plurality of packets 441 , 443 , . . . , 445 . Some packets are stored in memory device 130 having a security feature. Some packets may be stored outside memory device 130 .

[0493] The core package 441 stored in the memory device 130 can be executed in the processing device 118 of the host system 120 connected to the memory device 130 in the endpoint 150. The package 441 controls the operation of the endpoint 150 when submitting the identity data 113 of the endpoint 150 to the security server 140 and for communicating with the package repository 191 to repair and / or update the packages 441, 443, ..., 445. For example, the package 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 package 441 , free from tampering and / or corruption during the operations of verifying 373 the identity of endpoint 150 and repairing 385 the package.

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

[0496] After endpoint 150 generates identity data 113, endpoint 150 executing package 441 transmits identity data 113 to secure server 140 for verification 373. For example, identity data 113 may be generated using Figure 18 technology generation.

[0497] Identity data 113 may include package health information 447, such as current hash values ​​of packages 441, 443, ..., 445, and / or an indication of whether any of packages 443, ..., 445 is corrupted based on comparing the current hash value and stored hash values ​​of healthy versions of the corresponding packages.

[0498] Optionally, portions of the message 131 may be provided as ciphertext generated using the session key 263. For example, the encrypted portion of the message may include packet health information 447 and / or activity information 177. The session key 263 may be used to determine the packet health information 447 and / or activity information 177. Figure 9 The discussed manner is generated to be shared between the memory device 130 and the secure server and used to verify 373 the identity of the endpoint 150 .

[0499] Generally speaking, the identity data 113 may 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 the firmware store 170 in 15, Figure 15 Service Shop 190 or Figure 19 package repository 191) is transmitted from endpoint 150 to secure server 140.

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

[0501] For example, package 441 may be valid in endpoint 150. However, package 441 may be outdated because a new version of package 441 has been published in package repository 191. Therefore, updating package 441 may improve the operational security of endpoint 150 and the integrity of the system.

[0502] For example, package 443 or 445 may have been altered, and therefore corrupted, in endpoint 150. Health data 195 for the corresponding package 193 in repository 191 may be compared to package health information 447 provided in identity data 113 to detect the change.

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

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

[0505] After repair 385 or update 377, endpoint 150 may submit updated identity data 113. When security server 140 determines that identity data 113 is valid and package health information 447 in identity data 113 indicates that packages 441, 443, ..., 445 in endpoint 150 are healthy and up to date, security server 140 may authenticate the authenticity of endpoint 150.

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

[0507] For example, Figure 20 The security operation can be combined with Figures 1 to 5 The security features of the memory device discussed are combined Figure 9 、 10 , 14, 15 and / or 19 and combined Figure 1 and / or system implementation of 6.

[0508] exist Figure 20 In , the user computer 180 may be used to access the activity tracker 451 to set preferences 455 and / or examine the tracked activity record 453 for the endpoint 150 having the unique identification 111 .

[0509] As in Figure 14 and 15 In an embodiment, user computer 180 is typically distinct and separate from endpoint 150. In some cases, endpoint 150 may include a user interface that allows it to be used as computer 180 to set preferences 455 and / or review activity log 453.

[0510] Activity tracker 451 is coupled to secure server 140 to store activity records 453 regarding activities of endpoint 150 , where identity data 113 of endpoint 150 is verified by secure server 140 .

[0511] Preferences 455 may include active security settings for endpoint 150. For example, security settings may 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 may identify the geographic region of endpoint 150. When endpoint 150 sends identity data 113 from a location outside of the geographic region, activity tracker 451 may generate a security alert to the registered owner or user of endpoint 150.

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

[0514] For example, preferences 455 may include a user-selected option associated with a predetermined condition specified in preferences 455. When the activity associated with the submission of identity data 113 meets the condition, the selected option causes security server 140 and / or client server 141 to generate a denial of access response 172 to corresponding access request 171. Alternatively or in combination, the option may trigger a security alert to the contacts registered in preferences 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 a cellular communication connection, an Internet connection, a connection 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 the access request 171 may include activity information 177, such as Figure 18 . Alternatively, or in combination, client server 141 may provide similar or separate activity information in verification request 173 transmitted to security server 140. For example, client server 141 may specify access attributes 449 in verification request 173. Access attributes 449 identify certain aspects of the current activity of endpoint 150 for which the identity of endpoint 150 is to be authenticated by security server 140. Client server 141 transmits verification request 173 to security server 140, which verifies identity data 113 to determine the authenticity of the identity of endpoint 150.

[0517] After verifying 373 the identity data 113 provided in the authentication 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 authentication request 173.

[0518] Based on activity record 453, activity tracker 451 determines whether the current activity satisfies any of the conditions specified in preferences 455. If a condition in preferences 455 is satisfied, activity tracker 451 may perform a security operation to implement the alternative selected for the condition.

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

[0520] For example, the security operation may include instructing the security server 140 to provide a verification response 174 indicating a security restriction, a security issue, unauthorized use of the endpoint 150, or the like.

[0521] Optionally, activity tracker 451 may identify activity patterns of endpoint 150 based on records 453 of past activity.

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

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

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

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

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

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

[0528] For example, the server system may include a secure server 140 that stores secrets of a memory device (eg, 130) and / or other servers, such as a package repository 191, a firmware store 170, and / or another server.

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

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

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

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

[0533] For example, receipt of identity data in block 461 may be a result of endpoint 150 executing package 167 stored in endpoint 150. Package 167 may contain at least a portion of firmware 363 or an operating system of endpoint 150. Health information 447 may be used to determine whether package 167 is out of date.

[0534] In another example, receipt of the identity data in block 461 may be a result of endpoint 150 executing first package 441 stored in endpoint 150. First package 441 may include at least a portion of firmware 363 or an operating system of endpoint 150. Health information 447 may be used to determine whether the second package (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 may obtain a copy of the second package (e.g., 443 or 445) when the second package (e.g., 443 or 445) in endpoint 150 is successfully configured. For example, the second package (e.g., 443 or 445) may include one or more configuration parameters for endpoint 150. In response to successfully configuring the second package (e.g., 443 or 445), the server system may receive a healthy version of the second package (e.g., 443 or 445) from endpoint 150. Subsequently, if the health information 447 extracted at block 465 indicates that the second package (e.g., 443 or 445) needs to be repaired, the healthy version stored in repository 191 may be used.

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

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

[0538] At block 467 , based at least in part on health information 447 , secure server 140 determines that a package stored in endpoint 150 requires updating or repairing.

[0539] At block 469 , the secure server 140 initiates operations to perform an update or repair of the package stored in the endpoint 150 .

[0540] For example, to replace or repair a package stored in memory device 130, security server 140 generates a second verification code 153 for command 155 using an encryption key indicating permission to execute command 155 in memory device 130. For example, when executed in memory device 130, command 155 causes a package (e.g., 441 or 443) in memory device 130 to be replaced.

[0541] In some embodiments, to repair a 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 may be replaced by executing instructions in package 441 loaded from memory device 130. Optionally, a second verification code 153 may be generated to write the replacement to memory device 130 and / or allow the repair or replacement of package 445 to be performed.

[0542] Figure 22 A method for performing security operations based on one or more activities of an endpoint according to one embodiment is shown. For example, Figure 22 The method can be used Figure 18 and 20 technical implementation.

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

[0544] For example, the server system may include a secure server 140 that stores secrets of a memory device (eg, 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 block 483 , the server system receives the authentication request 173 containing the identity data 113 generated by the memory device 130 configured in the endpoint 150 .

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

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

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

[0549] For example, the conditions may be specified in preferences 455 of endpoint 150 .

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

[0551] For example, the security operation may include transmitting an alert or notification to contacts registered in the one or more references 455 .

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

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

[0554] For example, after security server 140 determines that verification code 133 in identity data 113 is valid, security server 140 can trust that activity information 177 embedded in identity data 113 has not been changed since verification code 133 was generated by memory device 130. Thus, activity information 177 can be extracted from identity data 113 to evaluate the condition. Optionally, activity information 177 can be provided in a message in ciphertext form, which is encrypted using Figure 9 or another secret encryption key of the memory device 130 to decrypt the session key 263 generated in the manner discussed in

[15] .

[0555] Alternatively, or in combination, security server 140 may extract access attributes 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. Additionally, client server 141 may add access attributes 449 to provide information about the activity of endpoint 150 in the context of requesting a service from client server 141.

[0556] For example, a condition may include a mismatch between activity information 177 and access attributes 449 ; and the mismatch may trigger a rejection of access request 171 and / or rejection of identity data 113 in verification response 174 , even when 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 the one or more preferences 455 of the endpoint 150 .

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

[0559] For example, activity tracker 451 of the server system may store a plurality of records 453 of activity of endpoint 150. Based on the plurality of records 453, activity tracker 451 may determine an activity pattern of endpoint 150. The pattern may include a geographic area, a time of day or week, a range of activity attributes, or any combination thereof. A condition triggering a security operation of block 489 may be satisfied by activity that deviates from the pattern.

[0560] Optionally, activity tracker 451 can present activity of endpoint 150 to an owner or authorized user of endpoint 150 based on record 453. For example, based on an examination 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 the subscription account represented by the account identifier to receive services provided to the account by client server 141. When endpoint 150 is not using the service, the association between the identity of endpoint 150 and the subscription account can be removed to allow another endpoint to use the subscription account. Thus, 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 may 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. The group of endpoints can use the subscription account represented by the SIM card by physically installing the SIM card in one endpoint in the group at a time. In order for another endpoint in the group to use the subscription account, the SIM card would be physically moved from one endpoint to the other.

[0563] As above combined Figure 6 The system discussed allows attachment to an endpoint (eg, 150 ) through virtual card registration 237 using a virtual subscriber identity module (vSIM) and based on identity verification or endpoint authentication 239 performed using a secure server 140 . Figure 6 The system may be further configured to disassociate an endpoint (e.g., 150) from a card profile 219 representing a subscription account so that a virtual card registration 237 may 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 may be shared among a group of endpoints owned by an enterprise (or another entity). The endpoints in the group (e.g., 150) may not all require the account's services at the same time. Therefore, it may be advantageous to configure the endpoints in the 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 portion of the group may use the subscription account's services simultaneously.

[0565] For example, the server system can be configured to track the current usage status of endpoints in the group. When an endpoint communicates with the client server to request a service, the endpoint can be dynamically bound to a subscription account. When the endpoint is not actively using a service, the subscription account can be released from the endpoint. When the number of endpoints using services provided to a subscription account exceeds the number of subscription accounts that can be shared, active endpoints can use the account's services simultaneously. When a subscription account is currently bound to and being used by part of the group, requests for services from another endpoint can be rejected until one of the subscription accounts is no longer in use and thus becomes available for sharing.

[0566] For example, in response to an enterprise's Internet of Things (IoT) device requesting a cellular connection, a virtual subscriber identity module (vSIM) can be bound to the IoT device. If the cellular connection remains idle for a period of time longer than a threshold, the cellular connection can be disconnected, and the virtual subscriber identity module (vSIM) can be released from the IoT device and made available for binding to another enterprise IoT device. Thus, the enterprise can subscribe to a reduced number of vSIMs, and while all of these vSIMs are in use, a request for a cellular connection from another device can be placed on hold until one of the connections is disconnected and the vSIM is freed for assignment to the remaining device.

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

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

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

[0570] The endpoint group 501 has a plurality of unique identifications 111, ..., 112. Each of the unique identifications (eg, 111) represents a memory device (eg, 130) installed in a corresponding endpoint (eg, 150) in a 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 of the service of client server 141. For example, each subscriber identification number (e.g., 505) can be used to identify a unique subscription account for use by one subscriber at a time.

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

[0573] When the SIM card is inserted into a cell phone, communications with the subscriber are connected to the cell phone and the cell phone has service in the subscriber's account. When the SIM card is inserted into a replacement cell phone, communications with the subscriber are connected to the replacement cell phone that currently has the SIM card.

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

[0575] exist Figure 23 In FIG. 5 , the security server 140 is configured to dynamically link the subscriber identity number 505 in the subscriber group 503 and the unique identification 111 in the endpoint group 501 .

[0576] For example, in response to a verification request 173 from client server 141 with identity data 113, security server 140 may determine whether identity data 113 has a valid verification code 133 for memory device 130 with unique identification 111. If identity data 113 is valid, security server 140 may determine whether subscriber group 503 currently has a subscriber identity number 505 available for use by memory device 130 with unique identification 111 and / or endpoint 150. If so, 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 provided to the account identified by subscriber identity number 505 to endpoint 150.

[0577] In some embodiments, if no subscriber identity number 505 is currently available in subscriber group 503 for endpoint 150 to use, then verification response 174 does not identify the subscriber identity number of identity data 113 , which may cause client server 141 to reject the service request from endpoint 150 .

[0578] Figure 23 The authentication request 173 in may include an access attribute 449 indicating a requested time period for associating the unique identification 111 identified in the identity data 113 with a subscriber identity number (eg, 505 ) available to the endpoint 150 having the unique identification 111 .

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

[0580] When endpoints having unique identifications 111 , . . . , 112 compete for use of a subscriber identity number (eg, 505 ) in subscriber group 503 , service store 190 may control allocation of use of the subscriber identity number (eg, 505 ) in subscriber group 503 .

[0581] For example, the service store 190 may track endpoints in the group 501 that deny access requests due to no available subscriber identity numbers 505 and prioritize subsequent allocations of available subscriber identity numbers 505 based on the tracked priorities.

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

[0583] In some embodiments, endpoints with unique identifiers 111, ..., 112 in endpoint group 501 may compete for an opportunity to use a subscriber identity 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) may wait for a random period of time before making a subsequent request. By randomizing the waiting period after a rejection, opportunities to gain service access using subscriber group 503 can be distributed to endpoints in need of the service.

[0584] In some embodiments, an endpoint 150 that is temporarily assigned a subscriber identity number 505 may notify the client server 141 and / or the security server 140 to release the subscriber identity number 505 from its assignment to the endpoint 150. For example, after the endpoint 150 completes communication using the service provided to the subscriber identity number 505, the endpoint 150 may return the subscriber identity number 505 to the pool of subscriber identity numbers in the group 503, which may be assigned to and / or used by another endpoint in the group 501 having the unique identifier 112.

[0585] In some embodiments, the system may track active activity of endpoints 150 using subscriber identity number 505. After a period of inactivity, service store 190 may remove the assignment of subscriber identity number 505 from unique identification 111.

[0586] Figure 23 173 and / or the authentication response 174. Alternatively and / or in combination, the client server 141 may connect to the service store 190 to perform the assignment and / or use the assignment to provide services, such as Figure 24 shown.

[0587] exist Figure 24 , client server 141 is coupled to service store 190 and activity tracker 451. Based on verification response 174 indicating the authenticity of endpoint 150 having unique identification 111 and the availability of subscriber identity number 505 for endpoint group 501, client server 141 may cause service store 190 to store data indicating a temporary assignment of subscriber identity number 505 to unique identification 111.

[0588] The client server 141 may then use the activity tracker 451 to determine whether to remove the assignment of the subscriber identity number 505 from the unique identification 111 .

[0589] For example, after a predetermined length of inactive period in which endpoint 150 does not use the services provided to the account represented by subscriber identity number 505, client server 141 may cause service store 190 to update subscription data 387 and terminate the assignment of subscriber identity number 505 to unique identifier 111.

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

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

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

[0593] At block 521 , the server system stores data associating the endpoint group 501 with at least one subscriber identifier (eg, identity number 505 ). The endpoint group 501 may have a plurality of endpoints (eg, 150 ) identified by unique identifications 111 , . . . , 112 .

[0594] For example, the server system may include a secure server 140 that stores secrets of a memory device (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 shown in .

[0595] At block 523, the server system receives the authentication request 173 containing the identity data 113 generated by the memory device 130 configured in the endpoint 150. The identity data 113 identifies the endpoint 150 using its unique identification 111 within the endpoint group 501.

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

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

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

[0599] At block 529, the server system assigns a subscriber identifier to endpoint 150 based on the data associating endpoint group 501 with the subscriber identifier (e.g., identity number 505). The assignment enables services provided to the account represented by and / or associated with the subscriber identifier (e.g., identity number 505) to be provided to the endpoint.

[0600] For example, a subscriber identifier (eg, identity number 505 ) represents a unique subscriber of a service provided in a network (eg, 225 ) having multiple endpoints (eg, 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 a cellular communication connection, an Internet connection, a connection to a user computer, an online storage facility, online computing resources, payments, transactions, or messaging, or any combination thereof.

[0602] For example, assigning a subscriber identifier (eg, identity number 505 ) to endpoint 150 includes configuring endpoint 150 to have a unique identity represented by the subscriber identifier (eg, identity number 505 ) in a serving network (eg, 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 include a subscriber identifier. Identity data 113 and / or unique identification 111 of memory device 130 and / or endpoint 150 may be dynamically assigned to or associated with a subscriber identifier (e.g., identity number 505) to configure endpoint 150 for a service network (e.g., 225).

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

[0605] For example, the server system may remove the data representing the assignment of the subscriber identifier to the endpoint after the time period to discontinue endpoint 150 from receiving services in the network as a subscriber. After the data is removed, endpoint 150 no longer has a subscriber identity represented by the subscriber identifier (e.g., identity number 505) in the serving network (e.g., 225).

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

[0607] Alternatively, releasing endpoint 150 from being configured as a subscriber identifier (eg, identity number 505 ) in a serving network (eg, 225 ) may be performed in response to a message or request from endpoint 150 .

[0608] Alternatively, the length of the time period after release of the subscriber identifier (eg, identity number 505 ) from binding to endpoint 150 may be a predetermined length from the time the subscriber identifier (eg, identity number 505 ) was assigned to endpoint 150 .

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

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

[0611] In general, endpoint 150 can be identified using different identifications for different services, in different networks, and / or in different contexts. Each identification of endpoint 150 can be used to represent endpoint 150 as a member, subscriber, account, authorized device, and / or entity of a number of groups specific to a certain type of service, connection, communication, etc.

[0612] For example, endpoint 150 can be configured to communicate with different client servers 141, ..., 143 for their respective services. Endpoint 150 can use different subscriber identifications to identify different client servers 141, ..., 143. Each subscriber identification of endpoint 150 represents a unique subscriber and / or account recognized by a corresponding client server (e.g., 141, ..., 143) for its service to a group of subscribers.

[0613] For example, endpoint 150 may be configured to communicate with client server 141 to obtain different types of services. The different identifications of endpoint 150 may be used to represent endpoint 150 as a subscriber to different types of services.

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

[0615] Security server 140 may be configured to manage the identity of endpoint 150 using security features of memory device 130 configured in endpoint 150 .

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

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

[0618] For example, in response to a request to bind a public identification to endpoint 150, security server 140 may verify that the public identification is not currently bound to another endpoint and may operate memory device 130 using a cryptographic key generation command representing owner authority to store the public identification in memory device 130 as part of device information 121 used to generate identity data 113 for memory 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 identification of endpoint 150. In response to authentication request 173 in the application domain, security server 140 authenticates identity data 113 provided in endpoint 150 and looks up the public identification of endpoint 150 in the application domain. The public identification may be provided in authentication response 174.

[0620] The secure, dynamic binding of a public identity to endpoint 150 can be used to facilitate secure operations. For example, if endpoint 150 is lost or stolen, the owner of endpoint 150 can request that security server 140 bind the public identity of the lost or stolen endpoint 150 to a replacement endpoint. Once security server 140 binds the public identity of the lost or stolen endpoint 150 to the replacement endpoint, services subscribed to the lost or stolen endpoint 150 are transferred to the replacement endpoint. Optionally, the owner of lost or stolen endpoint 150 can request that data be transferred from the lost or stolen endpoint 150 to a replacement device; and after the transfer, the owner can request that the lost or stolen endpoint 150 be deactivated to minimize the loss or impact of endpoint 150.

[0621] Figure 26 A technique for managing endpoint identification according to one embodiment is shown.

[0622] For example, Figure 26 The technology can be used in combination with Figures 1 to 5 The security features of the memory devices discussed in 9 to 10 are Figure 1 and / or 6 systems. For example, Figure 26 The technology can be used with Figure 14 and 15 Firmware store, Figure 15 、 23 and 24 service shops 190 and / or Figure 20 The activity tracker 451 is used in conjunction with the services.

[0623] exist Figure 26 In FIG, the secure server 140 stores the unique identification 111 of the memory device 130 and its unique device secret 101. In addition, the secure server 140 stores device information 121 that characterizes the hardware, software, and / or data configuration of the endpoint 150 where the memory device 130 is installed. Figure 2 , 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 secure server 140 verifies that verification code 133 was generated using secret key 137, which indicates that identity data 113 was generated by memory device 130 having unique device secret 101.

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

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

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

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

[0628] The security server 140 may update 543 the device information 121 in a manner similar to an update 377 of the firmware of the endpoint 150 and / or a repair 385 of a package installed in the endpoint 150. For example, the security server 140 may generate a verification code 153 for a command 155 to store the public identification 541 in the memory unit 103 of the memory device 130. The verification code 153 is generated using a cryptographic key 145 representing the owner's rights to operate the memory device 130, including the rights to execute the command 155 in the memory device 130 as controlled by the access controller 109 of the memory device 130.

[0629] Optionally, the association of public identification 541 with endpoint 150 does not require the generation of a new secret key to represent memory device 130 and / or endpoint 150. Public identification 541 may be included in message 131 used to generate verification code 133 signed using secret key 137. Verification of verification code 133 indicates that public identification 541 provided in message 131 has not been altered; and verification code 133 is signed by memory device 130 installed in endpoint 150.

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

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

[0632] In one embodiment, endpoint 150 has a package stored in memory device 130. When the package is loaded from memory device 130 and executed in host system 120, endpoint 150 may communicate with server 140 to obtain update 543. Communication between endpoint 150 and server 140 may be through 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 intermediary server.

[0633] For example, a manufacturer of an endpoint (e.g., 150) may use computer 180 to configure the endpoint (e.g., 150) and request that an identification (e.g., 541) assigned by the manufacturer be bound to the endpoint (e.g., 150). For example, such a public identification may be a mobile equipment identity number (e.g., 253) representing each device in the communication network.

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

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

[0636] At block 561 , the server system stores data associating the secret (eg, 101 ) of the memory device 130 configured in the endpoint 150 , the first identification 111 of the endpoint 150 , and the device information 121 .

[0637] For example, the server system may include a secure 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 shown in .

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

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

[0640] In one embodiment, authority to attach such second identification 541 to endpoint 150 is associated with the entity operating the computer and having ownership of memory device 130 (eg, as a manufacturer, retailer, service provider, 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 first identification 111 and may be verified by the server system as to whether current identity data 113 from memory device 130 is authentic.

[0642] For example, in response to the request, the server system may store data associating the first identification 111 with the second identification 541 .

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

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

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

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

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

[0648] For example, a memory device stores an executable set of instructions in endpoint 150. The set of instructions may be part of content 161 or a package 441 of the endpoint's firmware or operating system. Memory device 130 is configured to verify the integrity of the set of instructions before allowing endpoint 150 to load the set of instructions for execution. Because the set of instructions is protected via memory device 130, a server system can reliably communicate with endpoint 150 executing the set of instructions to cause memory device 130 to execute commands 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 block 565, the server system receives a verification request 173 containing identity data 113 generated by the memory device 130. The identity data 113 includes a verification code 133 generated from the message 131 present 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 embodiments, the message 131 presented in the identity data contains the second identification 541. Optionally, when the second identification 541 is configured as part of the device information 121, the encryption key (e.g., secret key 137) used to sign the message 131 in the form of the verification code 133 can be further derived based on the second identification 541; alternatively, the encryption key is independent of the second identification 541.

[0651] In some embodiments, the message 131 presented in the identity data 113 does not include the second identification 541 .

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

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

[0654] At block 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 identification 541 .

[0655] For example, the server system may identify the second identification 541 in the verification response 174 by looking up the second identification 541 associated with the first identification in data stored in the secure server 140 or extracting the second identification 541 from the identity data 113. Alternatively, the server system may indicate that the identity data 113 is valid, including the second identification 541 presented in the message 131 included in the identity data 113.

[0656] Figure 28 An example machine of computer system 600 is shown within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed. 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 operations of security manager 160 (e.g., executing instructions to perform operations corresponding to reference Figure 1-27 In some embodiments, the machine may be connected (e.g., using a network) to other machines in a LAN, an intranet, an extranet, and / or the Internet. The machine may operate in the capacity of a server or a client user machine in server-client user network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or a client user machine in a cloud computing infrastructure or environment.

[0657] The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a network appliance, a server, a network router, a switch or a bridge, or any machine capable of executing (sequentially or otherwise) a set of instructions that specify actions to be taken by the machine. Further, while a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or collectively execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0658] The 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] The processing device 602 represents one or more general-purpose processing devices, such as a microprocessor, a central processing unit, or the like. 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 that implements other instruction sets, or a processor that implements a combination of instruction sets. The processing device 602 may also be one or more special-purpose processing devices, such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), a network processor, or the like. The processing device 602 is configured to execute instructions 626 for performing the operations and steps discussed herein. The computer system 600 may further include a network interface device 608 that communicates via a network 620.

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

[0661] In one embodiment, instructions 626 include implementing instructions corresponding to security manager 160 (e.g., reference Figure 1-27 The machine-readable storage medium 624 is a memory device that stores instructions for performing the functions of the security features of the security server 140 and / or memory device 130 described herein. Although the machine-readable storage medium 624 is shown as a single medium in the example embodiment, the term "machine-readable storage medium" should be taken to include a single medium or multiple media that store one or more sets of instructions. The term "machine-readable storage medium" should also be taken to include any medium that is capable of storing or encoding a set of instructions for execution by a machine and causing the machine to perform any one or more of the methods of the present disclosure. The term "machine-readable storage medium" should therefore be taken to include, but not be limited to, solid-state memory, optical media, and magnetic media.

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

[0663] The memory subsystem can be a storage device, a memory module, or a mixture of a storage device and a memory module. Examples of storage devices include solid-state drives (SSDs), flash drives, universal serial bus (USB) flash drives, embedded multimedia controller (eMMC) drives, universal flash storage (UFS) drives, secure digital (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, the computing system may be a computing device such as a desktop computer, a laptop computer, a network server, a mobile device, a vehicle (e.g., an airplane, drone, train, car, or other transportation vehicle), a device with Internet of Things (IoT) capabilities, an embedded computer (e.g., an embedded computer included in a vehicle, industrial equipment, or networked commercial device), or such a computing device that includes a memory and a processing device.

[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 communication connection or a direct communication connection (e.g., without intervening components), whether wired or wireless, including electrical, optical, magnetic, etc.

[0666] The 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). The host system 120 uses a memory subsystem, for example, to write data to the memory subsystem and read data from the memory subsystem.

[0667] The host system 120 can be coupled to the memory subsystem via a physical host interface. Examples of a physical host interface include, but are not limited to, a Serial Advanced Technology Attachment (SATA) interface, a Peripheral Component Interconnect Express (PCIe) interface, a Universal Serial Bus (USB) interface, Fibre Channel, a Serial Attached SCSI (SAS) interface, a Double Data Rate (DDR) memory bus interface, a Small Computer System Interface (SCSI), a Dual In-line Memory Module (DIMM) interface (e.g., a DIMM socket interface supporting Double Data Rate (DDR)), an Open NAND Flash Interface (ONFI), a Double Data Rate (DDR) interface, a Low Power Double Data Rate (LPDDR) interface, or any other interface. The physical host interface can be used to transfer data between the host system 120 and the memory subsystem. The host system 120 can further utilize an NVM Express (NVMe) interface to access components (e.g., memory device 130) when the memory subsystem is coupled to the host system 120 via the PCIe interface. The physical host interface can provide an interface for passing control, address, data, and other signals between the memory subsystem and the host system 120. In general, the 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 device 118 of the host system 120 can be, for example, a microprocessor, a central processing unit (CPU), a processing core of a processor, an execution unit, etc. In some cases, the controller 116 can be referred to as a memory controller, a memory management unit, and / or an initiator. In one example, the controller 116 controls communications via a bus coupled between the host system 120 and the memory subsystem. Generally speaking, the controller 116 can send commands or requests to the memory subsystem to access the memory device 130. The controller 116 can further include interface circuitry for communicating with the memory subsystem. The interface circuitry can convert 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 data, writing data, or erasing data at the memory device 130, as well as other such operations. In some cases, the controller 116 is integrated into the same package as the processing device 118. In other cases, the controller 116 is separate from the package of the processing device 118. The controller 116 and / or the processing device 118 can include hardware, such as one or more integrated circuits (ICs) and / or discrete components, buffer memory, cache memory, or a combination thereof. The controller 116 and / or the processing device 118 can be a microcontroller, dedicated logic circuitry (e.g., a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), or another suitable processor.

[0670] Memory device 130 may include any combination of different types of non-volatile memory components and / or volatile memory components. Volatile memory devices may be, but are 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" (or NOT AND) type flash memory and write-in-place memory, such as three-dimensional cross-point ("3D cross-point") memory. Non-volatile memory cross-point arrays can perform bit storage based on changes in bulk resistance in conjunction with a stackable cross-grid data access array. In addition, compared to many flash-based memories, cross-point non-volatile memory can perform write-in-place operations, where non-volatile memory cells can be programmed even if they have been previously erased. NAND-type flash memory includes, for example, two-dimensional NAND (2D 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 cells (MLC), triple-level cells (TLC), quad-level cells (QLC), and penta-level cells (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, which may refer to a logical unit of a memory device for storing 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 cross-point and NAND-type memories (e.g., 2D NAND, 3D NAND) are described, the memory device 130 may be based on any other type of non-volatile memory, such as read-only memory (ROM), phase-change memory (PCM), selectable memory, other chalcogenide-based memories, ferroelectric transistor random access memory (FeTRAM), ferroelectric random access memory (FeRAM), magnetic random access memory (MRAM), spin transfer torque (STT)-MRAM, conductive bridging RAM (CBRAM), resistive random access memory (RRAM), oxide-based RRAM (OxRAM), NOR (NOR) flash memory, and electrically erasable programmable read-only memory (EEPROM).

[0674] The memory subsystem controller can communicate with the memory device 130 to perform operations such as reading data, writing data, or erasing data and other such operations at the memory device 130 (e.g., in response to commands dispatched by the controller 116 on a command bus). The memory subsystem controller can include hardware such as one or more integrated circuits (ICs) and / or discrete components, buffer memory, or a combination thereof. The hardware can include digital circuitry with dedicated (e.g., hard-coded) logic to perform the operations described herein. The memory subsystem controller can be a microcontroller, dedicated logic circuitry (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 a local memory. In the example shown, the local memory of the memory subsystem controller includes an embedded memory configured to store instructions for executing various processes, operations, logic flows, and routines that control the operation of the memory subsystem, including handling communications between the memory subsystem and the host system 120.

[0676] In some embodiments, the local memory may include memory registers that store memory pointers, fetched data, etc. The local memory may also include read-only memory (ROM) for storing microcode. Although some memory subsystems have a memory subsystem controller, other memory subsystems do not include a memory subsystem controller 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 speaking, the memory subsystem controller may receive commands or operations from the host system 120 and convert the commands or operations into instructions or appropriate commands to achieve the desired access to the memory device 130. The memory subsystem controller may be responsible for other operations such as wear leveling operations, garbage collection operations, error detection and error correction code (ECC) operations, encryption operations, cache operations, and address conversion between logical addresses (e.g., logical block addresses (LBAs), namespaces) and physical addresses (e.g., physical block addresses) associated with the memory device 130. The memory subsystem controller may further include host interface circuitry for communicating with the host system 120 via a physical host interface. The host interface circuitry may convert commands received from the host system into command instructions for accessing the memory device 130 and convert 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 decoders and column decoders) that can receive addresses from a memory subsystem controller and decode the addresses to access memory device 130.

[0679] In some embodiments, memory device 130 includes a local media controller that, in conjunction with a memory subsystem controller of the memory subsystem, performs 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 raw 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, the 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 logic circuitry and / or execute instructions when implementing the security manager 160. For example, the memory subsystem controller or the processing device 118 (e.g., a processor) of the 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 memory subsystem's firmware, the host system 120's operating system, a device driver, or an application, or any combination thereof.

[0681] Some portions of the previous detailed description have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the most effective means for those skilled in the art of data processing to convey their work to others skilled in the art. Here, and generally speaking, an algorithm is conceived to be a self-consistent sequence of operations that produces a desired result. The operations are those requiring physical manipulation of physical quantities. Typically, but not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, combined, compared, and otherwise manipulated. It has proven convenient at times, primarily for common reasons, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0682] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. The present disclosure may refer to the actions and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other such information storage systems.

[0683] The present disclosure also relates to an apparatus for performing the operations described herein. This apparatus may be specially constructed for the desired purpose, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored on a computer-readable storage medium, 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 or optical cards, or any type of medium 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 programs according to the teachings herein, or it may prove convenient to construct more specialized devices to perform the methods described. Structures for various such systems will be presented in the following description. Furthermore, the present disclosure is not described with reference to any particular programming language. It will be appreciated that the teachings of the present disclosure as described herein can be implemented using a variety of programming languages.

[0685] The present disclosure may be provided as a computer program product or software, which may include a machine-readable medium having stored thereon instructions that can be used to program a computer system (or other electronic device) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer). In some embodiments, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., computer) readable storage medium, such as a read-only memory ("ROM"), a random access memory ("RAM"), a magnetic disk storage medium, an optical storage medium, a flash memory component, or the like.

[0686] In this specification, in order to simplify the description, various functions and operations are described as being performed by computer instructions or caused by computer instructions. However, those skilled in the art will recognize that the intention of such expressions is that the functions are derived from the execution of computer instructions by one or more controllers or processors (e.g., microprocessors). Alternatively or in combination, the functions and operations can be implemented using dedicated circuit systems with or without software instructions, such as using application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). Embodiments can be implemented using hard-wired circuit systems without software instructions or in combination with software instructions. Therefore, the technology is not limited to any specific combination of hardware circuit systems and software, nor to any specific source of instructions executed by the data processing system.

[0687] In the foregoing description, the embodiments of the present 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 the present disclosure as set forth in the appended claims. The description and drawings are, therefore, to be regarded in an illustrative rather than a restrictive sense.

Claims

1. A method for identity authentication, the method comprising: receiving, in a server system, from an endpoint, identity data generated by a memory device configured in the endpoint; The identity data is verified by the server system based on information about the endpoint stored in the server system, the information comprising: a secret of the memory device, wherein the secret is unique to the memory device; and a portion of the content stored in the memory device, wherein the identity data is verified using a cryptographic key generated based at least in part on the secret, and the memory device does not require the secret of the memory device to be transmitted outside of the memory device; as well as In response to determining that the identity data is valid, extracting health information of a package stored in the endpoint from the identity data; determining, based at least in part on the health information, that the package stored in the endpoint requires updating or repairing; as well as An operation is initiated to perform the update or repair of the package stored in the endpoint.

2. The method of claim 1 , wherein the health information comprises a current hash value of the packet stored in the endpoint; and the method further comprising: The current hash value is compared to a hash value of a version of the package stored in the server system. 3 . The method of claim 2 , wherein the receiving of the identity data is performed via executing the package stored in the endpoint. The method of claim 3 , wherein the package comprises at least a portion of firmware or an operating system of the endpoint.

5. The method of claim 2, wherein the packet is a second packet; and the receiving of the identity data is performed via executing a first packet stored in the endpoint.

6. The method of claim 5, wherein the second packet contains data customized for the endpoint; and the method further comprises: receiving the second packet from the endpoint in response to successfully configuring the second packet in the endpoint; as well as The second package received from the endpoint is stored as the version that can be used to repair the second package in the endpoint. The method of claim 6 , wherein the second packet includes one or more configuration parameters of the endpoint.

8. The method of claim 2, wherein extracting the health information from the identity data comprises decrypting a portion of a message provided in the identity data.

9. The method of claim 8, wherein verification of the identity data comprises determining whether a first verification code provided in the identity data is generated from the message and the secret of the memory device.

10. The method according to claim 9, further comprising: A second authentication code for the command is generated using the encryption key indicating permission to cause a command to be executed in the memory device, wherein the command, when executed in the memory device, causes the package in the memory device to be replaced.

11. The method of claim 10, wherein the memory device does not transmit the secret outside of the memory device after fabrication of the memory device is completed in a secure facility.

12. The method according to claim 11, further comprising: A session key is established based on the verification of the identity data, wherein decryption of the portion of the message provided in the identity data is performed using the session key. 13 . The method of claim 12 , wherein the memory device is configured to verify the second verification code based on an access control key configured based on the session key.

14. The method according to claim 13, further comprising: storing the secret during manufacture of the memory device in the secure facility; as well as Based at least in part on the secret, the encryption key for authenticating the identity data is generated.

15. The method of claim 14, wherein the encryption key used to verify the identity data is further generated based on data received from a host system of the memory device at boot time of the endpoint.

16. A computing system comprising: a memory storing an encryption key for the memory device; as well as At least one processor configured via a set of instructions to: receiving identity data generated by said memory device configured in an endpoint; and In response to receiving the identity data: verifying the identity data based at least in part on a secret of the memory device, wherein the secret is unique to the memory device, wherein the identity data is verified using the cryptographic key generated at least in part based on the secret, and the memory device does not require the secret of the memory device to be transmitted outside of the memory device; extracting health information of the package stored in the endpoint from the verified identity data; as well as Based at least in part on the health information, a determination is made whether to update or repair the package stored in the endpoint.

17. The computing system of claim 16, wherein the at least one processor is further configured to transmit a replacement version of the package to the memory device to update or repair the package stored in the endpoint; and wherein the identity data includes a verification code generated using a cryptographic engine implemented via logic circuitry in the memory device.

18. The computing system of claim 17, wherein the memory device is configured to use the encryption engine to: generating the cryptographic key representing the identity of the endpoint based at least in part on the secret of the memory device and firmware currently configured in the memory device for execution by the endpoint; and Commands executed in the memory device are controlled based on the permissions represented by the encryption key.

19. A non-transitory computer storage medium storing instructions that, when executed by a server system, cause the server system to perform a method comprising: receiving identity data generated by a memory device configured in the endpoint; verifying the identity data based at least in part on a secret of the memory device, wherein the secret is unique to the memory device, wherein the identity data is verified using a cryptographic key generated based at least in part on the secret, and the memory device does not require the secret of the memory device to be transmitted outside of the memory device; as well as In response to determining that the identity data is valid, extracting health information of a package stored in the endpoint from the identity data; and Based at least in part on the health information, a determination is made whether to update or repair the package stored in the endpoint.

20. The non-transitory computer storage medium of claim 19, wherein the method further comprises: A replacement version of the package is downloaded to the memory device to update or repair the package stored in the endpoint.

Images