CN115037495B

CN115037495B - Track activity of endpoints with secure storage devices during authentication for security operations

Info

Publication number: CN115037495B
Application number: CN202210199645.7A
Authority: CN
Inventors: J·C·夏纳; L·W·多弗; O·杜瓦尔
Original assignee: Micron Technology Inc
Current assignee: Micron Technology Inc
Priority date: 2021-03-03
Filing date: 2022-03-02
Publication date: 2025-04-25
Anticipated expiration: 2042-03-02
Also published as: CN115037495A

Abstract

The present disclosure relates to tracking the activity of an endpoint having a secure memory device during authentication for security operations. A security server is used to implement security operations based on activity data of the endpoint during authentication of the endpoint. For example, a server system stores data representing preferences of the endpoint. After receiving a verification request containing identity data generated by a memory device configured in the endpoint, the server system may verify the identity data based at least in part on a secret of the memory device. If the identity data is valid, the server system may further determine whether the activity identified by the identity data and/or the verification request satisfies a condition specified for the endpoint. If so, the server system may perform a security operation associated with the condition when providing a verification response in response to the verification request.

Description

Tracking activity of endpoints with secure memory devices for secure operations during authentication

RELATED APPLICATIONS

The present application claims the benefit of the filing date of provisional U.S. patent application serial No. 63/105,820 filed on 10 months 26 in 2020 and entitled "virtual subscriber identification Module and virtual Smart card (Virtual Subscriber Identification Module and Virtual SMART CARD)", wherein the present application also claims the benefit of the filing date of provisional U.S. patent application serial No. 63/156,238, filed on 3 months 3 in 2021 and entitled "tracking the activity of endpoints with secure memory devices during authentication for secure operation (Track Activities of Endpoints having Secure Memory Devices for Security Operations during Identity Validation)", the entire disclosure of which is hereby incorporated by reference.

The present application relates to U.S. patent application Ser. No. 17/005,565, filed on month 8 and 28 of 2020, entitled "secure memory System Programming for host device authentication" (Secure Memory System Programming for Host Device Verification), which claims the benefit of the filing date of U.S. patent application Ser. No. 63/059,617, filed on month 7 and 31 of 2020, U.S. patent application Ser. No. 17/080,684, filed on month 10 and 26 of 2020, entitled "end-point authentication (Endpoint Authentication based on Boot-Time Binding of Multiple Components) based on startup time binding of multiple components", filed on month 4 of 2019, entitled "login software (Onboarding Software on Secure Devices to Generate Device Identities for Authentication with Remote Servers)" on secure device for generating device identity for authentication with remote server", and published as U.S. patent application publication No. 16/374,905, 10 of 2020, and U.S. patent application Ser. No. 17/014,203, filed on month 9 and entitled "client specific activation of functions in semiconductor devices", filed on month 9 and entitled "client specific activation (Custon-Specific Activation of Functionality in a Semiconductor Device", which are hereby incorporated herein by reference in their entirety.

Technical Field

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

The memory subsystem may include one or more memory devices that store data. The memory device may be, for example, a nonvolatile memory device and a volatile memory device. In general, a host system may utilize a memory subsystem to store data at and retrieve data from a memory device.

Standards for Device Identity Composition Engine (DICE) and robust Internet of things (RIoT) have been established for data computation for computing device identity recognition and authentication based on cryptographic computation.

Disclosure of Invention

In one aspect, the present disclosure is directed to a method comprising storing, in a server system, data representing one or more preferences of an endpoint, receiving, in the server system, a validation request containing identity data generated by a memory device configured in the endpoint, validating, by the server system, the identity data based at least in part on a secret of the memory device and at least a portion of content stored in the memory device, and determining, in response to determining that the identity data is valid, that an activity associated with the identity data satisfies a condition specified for the endpoint, and performing a security operation associated with the condition when a validation response is provided in response to the validation request.

In another aspect, the disclosure is directed to a computing system that includes a memory that stores an encryption key of a memory device, and at least one processor configured via a set of instructions to receive an authentication request containing identity data generated by a memory device configured in an endpoint, and in response to the authentication request, determine that the identity data is valid based at least in part on a secret of the memory device, determine that an activity identified via the authentication request satisfies a condition specified for the endpoint, and perform a secure operation associated with the condition when an authentication response is provided in response to the authentication request.

In yet another aspect, the present disclosure is directed to 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 an authentication request containing identity data generated by a memory device configured in an endpoint, and in response to the authentication request, determining that the identity data is valid based at least in part on a secret of the memory device, determining that an activity identified via the authentication request satisfies a condition specified for the endpoint, and performing a secure operation associated with the condition when an authentication response is provided in response to the authentication request.

Drawings

Embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.

FIG. 1 illustrates an example computing system according to some embodiments of the disclosure.

FIG. 2 illustrates the generation of identity data in an integrated circuit memory device according to one embodiment.

FIG. 3 illustrates a technique for controlling command execution in a memory device, according to one embodiment.

FIG. 4 illustrates a technique for verifying the integrity of data stored in a memory device, according to one embodiment.

Fig. 5 illustrates security services provided to a security server of a client server based on security features implemented in a memory device, according to one embodiment.

Fig. 6 illustrates a system and method for configuring and authenticating endpoints of a card-based service according to one embodiment.

Fig. 7 illustrates a card profile of a virtual smart card according to one embodiment.

Fig. 8 illustrates a card profile of a virtual Subscriber Identity Module (SIM) according to one embodiment.

FIG. 9 illustrates a technique for authenticating a memory device according to one embodiment.

FIG. 10 illustrates a technique for generating commands to control secure operation of a memory device, according to one embodiment.

Fig. 11 illustrates a method of virtualizing a smart card according to one embodiment.

FIG. 12 illustrates a method of security services provided based on security features of a memory device, according to one embodiment.

Fig. 13 illustrates a method of logging into an endpoint of a service subscribed to by an account, according to one embodiment.

FIG. 14 illustrates a technique for end point customization using an online firmware store, according to one embodiment.

FIG. 15 illustrates a technique for directing services to endpoints via an online service store, according to one embodiment.

FIG. 16 illustrates a firmware update method using a firmware store and a secure server, according to one embodiment.

FIG. 17 illustrates an endpoint customization method using a service store and a security server according to one embodiment.

FIG. 18 shows a diagram of generating identity data to facilitate monitoring of integrity and/or endpoint activity, according to one embodiment.

Fig. 19 illustrates a technique for maintaining packet integrity stored in an endpoint in accordance with one embodiment.

FIG. 20 illustrates a system that implements secure operations based on tracking endpoint activity, according to one embodiment.

FIG. 21 illustrates a method for updating or repairing packets stored in an endpoint, according to one embodiment.

FIG. 22 illustrates a method for performing security operations based on one or more activities of an endpoint, according to one embodiment.

Fig. 23 and 24 illustrate a system configured to implement subscription sharing among a set of endpoints, according to one embodiment.

FIG. 25 illustrates a method for facilitating subscription sharing among a set of endpoints, according to one embodiment.

FIG. 26 illustrates a technique for managing endpoint identification, according to one embodiment.

FIG. 27 illustrates a method for managing endpoint identification, according to one embodiment.

FIG. 28 is a block diagram of an example computer system in which embodiments of the present disclosure may operate.

Detailed Description

At least some aspects of the present disclosure relate to a secure server and a memory device having a security feature. The security server is configured to provide online security services in a computer network (e.g., the internet) based on the security features of the memory device. The host system of the memory device may store instructions and/or data for processing and store processing results using the memory and/or storage functions of the memory device.

In general, a memory subsystem may include storage devices and/or memory modules. The 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 for retrieval from the memory subsystem.

For example, a portion of the data stored in the memory device may be instructions, such as instructions programmed for software, firmware, boot loader, operating system, routines, device drivers, application packages, and the like. The instructions may be stored for a computing device implemented using a host system coupled to a memory device.

Another portion of the data stored in the memory device may provide an operand or input to the instruction when the instruction is executed in one or more processing devices of the host system.

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

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.

Security features implemented in the memory device may be used for secure communications between the memory device and the security server via a computer network. The communication path between the memory device and the secure server may be unsafe. The identity of the memory device and/or control of access to the memory device may be verified through communication between the secure server and the memory device to prevent and detect counterfeiting, tampering, hacking, and/or unsafe operation.

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

For example, the secure server and memory device may implement replacement of a Subscriber Identity Module (SIM) in combination.

SIM cards are commonly used to represent subscriber identities for cellular services in a telecommunications network. The cellular telephone may access cellular services provided to the subscriber's account when the SIM card is inserted into the cellular telephone, and the subscriber may access cellular services associated with the account using the alternate cellular telephone when the SIM card is inserted into the alternate cellular telephone.

The need for a physical SIM card may be eliminated when the identity of a memory device installed in a cellular telephone can be securely configured to represent the subscriber identity. The identity of the memory device may be configured and protected via the security features of the memory device and the security services of the security server.

In general, a security server may be configured on the internet to provide security-related services to third party computers and servers based on security features built into the memory device. The security features are built and packaged into the memory device. The security features and security services may be used without trusting the security implementation of the computing device in which the memory device is installed. Thus, the security implementation may be focused on the security features of the memory device and the design of the security server. By simply using a memory device with security features, the security of a computing device using the memory device may be improved without requiring too much effort by the designer and/or manufacturer of the computing device.

The security server may provide services to verify the identity and/or authenticity of the device, detect counterfeit devices and/or tampered devices, track and manage device ownership, facilitate transfer of device ownership/control, facilitate configuration of services for the computing device to access the third party server and/or the services network, and so forth.

The security features of the memory device may be implemented within an Integrated Circuit (IC) package of the memory device during fabrication of the memory device. A memory device may have logic circuits (or controllers) and memory cells formed on one or more integrated circuit die. At least some of the memory cells in the memory device may be non-volatile such that data may be stored in the non-volatile memory cells even if the memory device is powered down for a long 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 operation of the host system of the memory unit.

The memory device may have a Unique Device Secret (UDS). The unique device secret may be protected within the memory device such that after fabrication of the memory device is completed, the unique device secret is not transferred out of the memory device and is not readable by the host system via any interface of the memory device.

The presence of a unique device secret in the memory device may be verified by the secure server through cryptographic computations, 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.

Encryption calculations that encrypt a message using an encryption key involve calculations for representing the ciphertext of the message. The message may be effectively recovered from the ciphertext using the corresponding encryption key by performing a predefined decryption calculation. Recovering the message from the ciphertext is generally not feasible without a corresponding encryption key for decryption. The difficulty level of recovering a message without knowing the corresponding encryption key used for decryption represents the security level of the encryption computation. The security level is generally dependent on the encryption key length used for encryption and the algorithm used for encryption.

When symmetric encryption is used, the encryption key used for decryption and the encryption key used for encryption are the same. When asymmetric encryption is used, the decryption key and the encryption key are different and generated in pairs. One of the pair may be used as a private key and thus as a secret and the other of the pair may be used as a public key. Computing a private key from a public key is generally not feasible. The level of difficulty in recovering the private key from the public key represents the security level of asymmetric encryption.

An encryption calculation that hashes a message maps the message to a hash value that represents the message. But some amount of information is lost in the hash calculation so that the message cannot be recovered from the hash value. Many messages may be mapped to the same hash value. Generating a modified version of a message that can be hashed to the same hash value is generally not feasible, particularly when the modified version is similar to the original message.

The encryption computation of the key generation involves computing an encryption key for symmetric encryption or a pair of encryption keys for asymmetric encryption based on a set of data. The probability of generating the same key or the same key pair without the same set of data is low. The probability level represents the strength of the encryption computation used for key generation.

In general, any encryption computing technique for encryption, hashing, and key generation may be used with the memory device and the secure server. Thus, the present disclosure is not limited to particular encryption, hashing, and/or key generation techniques.

In addition to the unique device secrets, the memory device may also store additional data to represent data and/or hardware configuration of the memory device and/or the computing device in which the memory device is installed. A portion of the additional data may or may not be kept as a secret for the memory device. The unique device secret and the additional data may be used to generate a secret encryption key that represents an identity of the memory device and/or the computing device.

Logic circuitry (or a 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 encryption computations (e.g., hashing, encryption/decryption, key generation) within the memory device to support the operation of the identity engine and the access controller. Implementation of an encryption engine in a memory device eliminates the need to rely on an external processor for secure computation of the memory device and thus improves security by preventing secret transmissions out of the memory device and preventing tampering and hacking of the encryption computation. Optionally, at least part of the encryption computation involved in the security features of the memory device may be implemented via storing instructions in the memory device for execution by the host system of the memory device, while there is a level of tradeoff between the security level and complexity of the logic circuitry (or local controller) of the memory device.

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

The access controller of the memory device is configured to control execution of commands received in the memory device using the encryption key. For example, permissions may be required to request a memory device to perform commands to read, write, delete, modify, etc. various portions of the non-volatile memory of the memory device. Rights may be represented by a corresponding encryption key. After receiving the entitlement command in the memory device for execution, the access controller may use the encryption engine to perform the computation in determining whether the command is from a sender having an encryption key representing the entitlement. After the calculation indicates that the sender has the encryption key and therefore the rights, the access controller allows the command to execute within the memory device. Otherwise, the access controller may reject, ignore, or discard the command. Such access control may prevent unauthorized access to data stored in the memory device, prevent unauthorized changes to the memory device, and prevent tampering and/or hacking of counterfeit and/or unsecured devices that form the memory device.

Generally, verifying whether the sender of a message has an encryption key involves verifying the verification code of the message. The verification code may be in the form of a hash digest, a digital signature, a hash-based message authentication code (HMAC), a encrypted message authentication code (CMAC), etc. The authentication code is generated using an encryption key and the message as input to a hashing, encryption, and/or other computing operation, such that generating the authentication code without the encryption key and generating the authentication code from a modified version of the message is generally not feasible. Thus, when the receiving side confirms that the received authentication code is valid for the received message and the encryption key, the receiving side can conclude that the transmitting side has the corresponding encryption key and that the received message is identical to the message used to generate the received encryption key.

In some embodiments, the recipient performs verification of the message authentication code using the same encryption key as used by the sender to generate the authentication code. For example, the recipient generates a verification code of the received message using the same encryption key and compares the generated verification code with the received verification code. If there is a match, the received authentication code is valid for the received message and the sender may 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 is generated using a different encryption key, or both.

In some embodiments, the recipient performs verification of the message authentication code using a public encryption key in the key pair, and the sender generates the authentication code using a private encryption key in the key pair. For example, the passcode may be generated by applying a hash function to the message to generate a hash value for the message. Ciphertext of a hash value obtained by encrypting the hash value performed using the encryption key may be used as the authentication code. The recipient of the message and the verification code performs verification using a corresponding decryption key, which is identical to the encryption key when symmetric encryption is used and is 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 may 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 may perform authentication using the encryption key without performing decryption. The recipient may use the encryption key to generate an authentication code for the message for comparison with the received authentication code.

In some embodiments, the message and encryption key combination generates a hash value as the verification code, as in a hash-based message authentication code (HMAC) technique. For example, an encryption key may 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 may be applied to the key modified message to generate a hash value that is further combined with the other key to generate the other 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 may use the same encryption key to generate a hash-based message authentication code of the received message for comparison with the received hash-based message authentication code. If there is a match, then the verification is successful, otherwise the verification fails.

In general, any technique for generating and verifying a verification code of a message from a sender and an encryption key for use by the sender in generating the verification code may be used to determine whether the sender has an encryption key. The recipient will perform the verification using the appropriate encryption key, which may be the same encryption key used to generate the verification code, or in the same asymmetric encryption key pair. Thus, the present disclosure is not limited to particular techniques for hashing digests, digital signatures, and/or hash-based message authentication codes.

For convenience, the verification code generated for representing the message and the encryption key using the message of the encryption key may be collectively referred to as a digital signature of the message signed using the encryption key, but it should be understood that the verification code may be generated using a variety of techniques, such as a hash-based message authentication code.

The memory device may be configured to store an associated encryption key for verifying a verification code signed using an encryption key configured to indicate rights requesting the memory device to execute the command.

For example, the access controller may provide the owner of the memory device with a set of permissions such that the owner may 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 a section of the memory device that is not readable by other users of the memory device.

For example, the access controller may provide an authorized user of the memory device with specific rights to read, write, erase, or modify a specific section of the memory device.

When a memory device receives a command requiring access rights to execute, the access controller may retrieve the corresponding encryption key to verify the verification code or digital signature of the message containing the command. If verification of the received verification code for the received command is successful, the received command is considered to be from the sender of the encryption key having rights to execute the command in the memory device. In response, the access controller allows the command to be executed in the memory device. Otherwise, the access controller prevents execution of the command.

The memory device may be manufactured to be initially owned by the secure server. The security server may then provide and/or transfer some or all of the rights to one or more owners and users in a process from a memory device assembled to the computing device to a computing device having a memory device used by an end user. The access controller may be resistant to tampering, hacking, and unauthorized access while providing flexibility to support different owners and users' different rights transfer modes, such as manufacturers of component computing devices that install memory devices, computing device manufacturers that install component computing devices, retailers, enterprise users, end users, and alternate end users, among others.

The identity engine of the memory device is configured to generate data indicative of an identity of the memory device and/or an identity of a computing device in which the memory device is installed. To generate identity data, the identity engine generates a secret encryption key using an encryption engine from the unique device secret and other data stored in and/or collected by the memory device (e.g., during a boot process of the computing device). The presence of a secret encryption key in a memory device may be considered as proof that the memory device possesses a unique device secret and other data used to generate the secret encryption key. The presence of the secret encryption key in the memory device may be verified by the secure server via a verification code or digital signature signed using the secret encryption key.

During manufacture of the memory device, a copy of the unique device secret is hosted in a secure server and/or securely shared without exposure. The secure server is then configured to derive the same secret encryption key (and/or a corresponding public key when using asymmetric encryption) independent of the memory device without the memory device having to transfer its unique device secret out of the memory device. Thus, the security server may verify that the memory device has a unique device secret by verifying that the memory device has a secret encryption key, and the secret encryption key as the memory device identity may be changed in a process in which the memory device is integrated into a component, device, system and transferred among manufacturers, retailers, distributors, companies and/or end users. The memory device entity represented by the secret encryption key may be updated to represent the memory device being assembled into a component, device, system, customized and/or personalized and/or owned and/or operated by a different entity or user without changing the unique device secret.

Encryption operations and communications may be performed to allow the secure server to verify that the memory device has a secret encryption key.

For example, the identity data presented by the memory device for verification may include a message showing a public identification of the memory device. The common identification may be used to distinguish the memory device from other memory devices. The identity data may comprise a verification code or digital signature of a message in the identity data signed using a secret encryption key. The identity data contains a copy of the message and a verification code or digital signature. Once the authentication code and message data are authenticated by the secure server, the secure server may conclude that the public identification provided in the identity data is authentic and that the identity data is from a memory device having a secret encryption key.

The secret encryption key of the memory device may be generated using not only the unique device secret of the memory device but also additional data representing some aspects of the memory device and/or the computing device in which the memory device is installed. The additional data may represent software, firmware, a boot loader, an application, trace data stored in a memory device, an identifier of a computing device component in the computing device at a last boot time of the computing device. If the additional data has been altered, the identity engine generates an altered secret encryption key. Thus, the verification code generated using the modified secret encryption key cannot pass the verification performed at the secure server. Thus, verification of the verification code generated by the identity engine also verifies the integrity and authenticity of the hardware/software/data composite of the memory device and the computing device in which the memory device is installed.

Authentication of the identity of the memory device and/or its host system may detect counterfeit, tampered with, and stolen/lost devices. Based on the request from the owner, the secure server may configure the stolen/lost device to operate in one of several degraded modes, such as not bootable, not readable, encrypting/erasing data in non-volatile memory, self-destruction of memory/storage functions of the memory device, and so forth.

The security server is configured with an information database for verifying identity data generated by an identity engine of the memory device. The database allows the secure server to generate a corresponding secret encryption key for the memory device (and/or a corresponding public key when asymmetric encryption is used). The encryption key may be generated by the secure server without the need for the memory device to transfer its unique device secret out of the memory device after its manufacture. The encryption key may be generated based at least in part on additional data available after manufacture of the memory device.

The secure server may store an encryption key that represents the owner rights of the memory device. Using the encryption key, the secure server may generate a command to transfer ownership of the memory device and configure and/or transfer the selected rights such that the selected command is executed in the memory device. After reporting the loss/theft of the computing device, the security server may detect the use of its memory device during memory device authentication, as well as a request for service by a third party server.

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 identity data generated by the memory device from the computing device to a secure server for verification. The third party server may provide a service to the computing device if the identity data is verified by the security server, otherwise the service request may be denied, discarded, or ignored.

When requested by an authorized party, the security server may sign the command or generate a verification code for the command to grant or cancel access to the non-volatile memory of the memory device. Commands that are signed by the authorized party are forwarded to the memory device for execution. The signed command contains the message with the command and a verification code of the signed/generated message using an encryption key representing the right to execute the command in the memory device.

The memory device may be installed in the computing device as part of the identity of the computing device and provide main memory/storage capacity for the computing device. For example, instructions and associated data to be executed in a computing device may be stored in a memory device and protected from tampering, and/or theft via security features of the memory device. Because the identity data generated by the identity engine of the memory device 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 to be used by the computing device is verified at least during the process of verifying the identity of the memory device and/or the computing device.

The security services provided by the security server remove security from the operating and computing devices by the third party server. Services using memory devices and security servers may prevent unauthorized access without requiring significant effort from the computing device manufacturer and operators of third party servers. Thus, the third party server may operate with its core capabilities to provide the respective services without compromising security.

The third party server may provide services to its subscribers using the services provided by the secure server without requiring the subscriber to perform manual operations to configure the computing device used by the subscriber. For example, a subscriber may access subscribed cellular services in a subscriber account using a computing device without inserting a physical SIM card into the computing device and/or performing other operations to customize the computing device to use the subscriber account access.

The subscriber may be represented by an account identification. When a subscriber purchases a computing device, ownership of the computing device may be transferred to the subscriber through the secure server. Security features of a memory device configured in a computing device may be used to generate a device identity. When a computing device connects to a third party server to obtain a service, the third party server requests the secure server to verify the device identity. Based on the ownership of the computing device and the ownership of the account, the computing device may be dynamically linked to the account such that the computing device can access services provided by a third party using the account without requiring manual operations to configure the computing device.

For example, during verification of the identity of the computing device, 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 identification may be built into or associated with the device identity in the database of the secure server. Subsequently, when verifying the device identity, the service in the subscriber account may be provided to the computing device by a third party without the subscriber having to explicitly direct/request the service to the computing device.

Optionally, the computing device may establish a separate certificate with the third party server such 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 service.

In fig. 1, integrated circuit memory device 130 has security features as discussed above.

The secure memory device 130 may store the unique device secret 101 for authentication thereof. In one example, the unique device secret 101 is injected into the memory device 130 in the security facility and stored in a register of the memory device 130. In another example, the unique device secret 101 may be obtained from a Physical Unclonable Function (PUF) of the memory device 130. The unique device secret 101 may be obtained via a secure facility and registered in the secure server 140. For example, the security facility may be part of a manufacturing facility of the memory device (e.g., 130). After the memory device 130 is manufactured and/or leaves the security facility, the unique device secret 101 in the memory device 130 is not accessible via any interface of the memory device 130 (e.g., the host interface 147). Thus, after fabrication of the memory device 130, the unique device secret 101, such as in the memory device 130, is sealed in the integrated circuit package of the memory device 130. The copy of the unique device secret 101 is secured within the secure server 140 using powerful security measures, such as using a Hardware Security Module (HSM), to prevent theft and unauthorized access.

The memory device 130 includes logic or a local controller that implements the encryption engine 107. Encryption engine 107 may perform encryption computations, such as hashing, key derivation, encryption and/or decryption, independent of processing capabilities external to memory device 130, such as processing device 118 of host system 120.

For example, 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, according to a method specified by the Device Identity Composition Engine (DICE) and the robust Internet of things (RIoT) standards, or another method. The device information 121 may contain non-secret data that may be obtained by entities other than the secure server 140 and the memory device 130. To improve security, the device information 121 may include time-related information.

For example, encryption key 105 may comprise two pairs of asymmetric encryption keys. The first pair of asymmetric keys is referred to as the device identification key and the second pair of asymmetric keys is referred to as the alias key. The private device identification key is used to authenticate the authenticity of the alias key and thus reduce its use and reduce its risk. The alias key may be used for more transactions/communications and replacement of the alias key may be more frequent than the device identification key in order to increase security, as the alias key is used more frequently and is therefore risky. For example, the private device identification key may be generated at boot time and used to sign a certificate, such as a certificate of an alias public key, and then immediately delete the private device identification key from the memory device 130 to protect its confidentiality.

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 verified by the secure server 140.

For example, authentication of the memory device 130 may be performed by verifying that the memory device 130 has the secret encryption key 105. Having the secret encryption key 105 in the memory device 130 may be considered as proof that the memory device 130 has a unique device secret 101 and stores an untampered version of non-secret data.

Using encryption engine 107, memory device 130 may prove that memory device 130 has secret encryption key 105 without having to communicate secret encryption key 105 and/or unique device secret 101 out of memory device 130. For example, the memory device 130 may digitally sign a certificate or message using the secret encryption key 105 to provide a verification code for the message and the secret encryption key 105. When the security server 140 successfully verifies the passcode, the security server 140 may conclude that the memory device 130 has the secret encryption key 105 and thus the identity represented by the unique device secret 101.

Memory device 130 includes a host interface 147 that can be used to receive commands from host system 120. The controller 116 of the host system may send commands to the memory device 130 to request data to be read from the memory unit 103, to write data to the memory unit 103, to erase data from a portion of the memory unit 103, to modify data in a portion of the memory unit 103, to activate security features of the memory device 130, to configure parameters related to the security features in the memory device 130, and so forth. At least some of the commands require rights represented by the encryption key 106 stored in the secure server 140. Having an encryption key 106 available to sign a command is considered to indicate having the right to request the memory device 130 to execute the command.

The memory device 130 includes an access controller 109 configured to verify, using the encryption engine 107, a verification code generated using the encryption key 106 that represents rights associated with the command. If the command receives a valid passcode, the access controller 109 allows the memory device 130 to execute the command, otherwise the command may be rejected, ignored, or discarded.

When the memory device 130 is manufactured, one or more associated encryption keys 105 are stored in the memory device 130 to provide the owner rights to the secure server 140. Using the owner rights, the security server 140 may sign a command for execution in the memory device 130 to activate or deactivate a security feature, trigger replacement of a secret encryption key as an identity of the memory device 130, replace an encryption key used by the access controller 109 to verify rights to execute one or more commands in the memory device 130 for one or more regions of the memory unit 103, and so forth.

Optionally, after authenticating the identity of the authorized requester, the security server 140 may sign the command using the encryption key to generate a verification code or digital signature of the command so that the requester may send the command with the verification code to the host interface 147 of the memory device 130 so that the command is executed within the memory device 130.

Optionally, the secure server 140 may provide the entity with a specific right by replacing the encryption key 105 in the memory device 130, or a corresponding encryption key 106 representing the right.

Typically, the memory device 130 is connected to the host system 120 to form an endpoint 150 in the communication network 110, such as the internet. In general, endpoint 150 is a computing device. Examples of endpoints 150 include personal computers, mobile computers, personal media players, tablet computers, smart phones, smart TVs, smart speakers, smart appliances, internet of things (IoT) devices, and the like.

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, the processing device 118 of the host system 120 is configured to execute instructions loaded from the memory device 130 to initiate and perform operations.

Host system 120 may include network interface 114 or another communication device to communicate with one or more of client servers 141, 143 to receive services from client servers 141, 143.

The service request sent from endpoint 150 to client server 141 may include identity data generated by encryption engine 107 of memory device 130. The client server 141 may request the security server 140 to verify the verification code contained in the identity data.

In addition to the services of authenticating the identity of the memory device 130, the security server 140 may also provide security services to manage the rights 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 so forth.

Memory device 130 and/or endpoint 150 may have a unique identification 111 that is non-secret. 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.

For example, the unique identification 111 of the memory device 130 may include a Manufacturer 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 the unique device secret.

To authenticate that the memory device 130 and/or the endpoint 150 has an identity represented by the unique identification 111, the secure server 140 verifies the message containing the unique identification 111 (and other data 127) via a verification code of the message signed using the secret encryption key 105 of the memory device. 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 from the corresponding unique device secret 101 in the secure server 140.

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 device information 121 accessible to the memory device 130.

For example, the device information 121 may include a hash value of instructions and/or data stored in the memory unit 103. Further, the device information 121 may include tracking data stored into the memory unit 103 for personalizing/personalizing the memory device 130 and/or the endpoint 150 during assembly of the components to build the endpoint 150. Further, the device information 121 may include identification information of other components in the endpoint 150, such as identification of the controller 116, identification of the processing device 118, identification of the network interface 114, identification of additional software or data packets of the endpoint 150 that are not stored in the memory device 130, and/or identification and/or hash values of firmware configured to control/operate the memory device 130. During the boot time, the identification data may collect device information 121 that is a secret encryption key 105 used to generate the memory device 130.

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

FIG. 2 illustrates the generation of identity data in an integrated circuit memory device according to one embodiment. For example, the technique of FIG. 2 may be implemented in the computing system of FIG. 1.

In fig. 2, encryption engine 107 of memory device 130 (e.g., as in fig. 1) is configured to generate at least secret key 137 using its unique device secret 101 and device information 121.

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

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

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) methods, the first pair of asymmetric keys is referred to as the device identification key and the second pair of asymmetric keys is referred to as the alias key. The private device identification key may 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 in the host system 120. The alias key may be used to authenticate other transactions and/or communications. For example, the private device identification key may be generated at boot time and used to sign a certificate, such as a certificate of an alias public key, and then deleted. After verifying or validating 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 may be used as the secret key 137 for the memory device 130 in subsequent operations until the endpoint 150 reboots.

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

For example, the 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 for comparison with the known hash value. If the two hash values agree with each other, the integrity of the set of instructions is verified and the hash value of the integrity of the set of instructions can be used as part of the device information 121 that calculates the secret key 137.

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 changed (e.g., due to data corruption and/or tampering or hacking), the verification of the secret key 137 by the secure server 140 will fail.

Optionally, the data 123 may include an identification of the set of instructions, such as a hash value of the source code of the instruction, a name of the software/firmware package represented by the instruction, a version number and/or issue date of the package, and so forth.

Optionally, data 123 may include tracking data stored into memory unit 103 during a process of building and/or customizing endpoint 150 that includes memory device 130. For example, when the memory device 130 is assembled into a component device (e.g., a memory subsystem), a piece of trace 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 into the memory unit 103 as part of the device information 121. Subsequently, when the component device is assembled into the endpoint 150, a piece of trace data is added to the memory unit as part of the device information 121. Other tracking data may be added to the memory unit 103 as part of the device information 121 to reflect the history of the memory device 130 for personalizing the identity of the memory device 130.

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

For example, endpoint 150 may have host system 120 and memory device 130. Some components in the host system 120 may be removed or replaced. Upon booting the endpoint 150, a portion of the instructions stored in the memory unit 103 are executed to collect data 125 about components present in the host system 120 at boot time. Thus, device information 121 may represent a particular configuration of software/data and hardware combinations of memory device 130 and/or endpoint 150. The secret key 137 generated based on the device information 121 and the unique device secret 101 represents the identity of the memory device 130 having the particular configuration.

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

As discussed above, the secret key 137 and the verification code 133 of the message 131 may be constructed and/or verified using various techniques, such as a hash digest, a digital signature, or a hash-based message authentication code, symmetric encryption, and/or asymmetric encryption. Thus, the verification code 133 is not limited to a particular embodiment.

Optionally, message 131 may contain a user identification, such as a name, an email address, a registered user name, or another identifier of the owner or authorized user of endpoint 150 in which identity data 113 was generated.

Optionally, portions of message 131 may provide information in encrypted form. For example, the information may be encrypted using the public key of the secure server 140 such that the information is not accessible to third parties.

Message 131 may be a certificate that presents 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 random number, and/or other information regarding verification of identity data 113. Memory device 130 may monotonically increase the counter value to invalidate the identity data with a lower counter value to prevent replay attacks.

In some implementations, the data 127 can include a portion of the device information 121 that is used to generate the secret key 137.

In some embodiments, the secret key 137 is a private alias key of a pair of asymmetric keys. The data 127 includes a certificate that presents a corresponding public alias key of the pair of asymmetric keys. Certificates presenting the public alias key use the device identification key signature of the memory device 130. The public alias key may be used to authenticate the authentication code 133 of the message 131 and the private alias key used as the secret key 137. Once the secure server 140 verifies the certificate that presents the public alias key, which uses the device identification key signature of the memory device 130 and is provided as part of the data 127, the secure server 140 can verify the verification code 133 signed using the private alias key as the secret key 137 using the public alias key. In this embodiment, the secure server 140 may use the public alias key verification code 133 provided in the message 131 without having to regenerate the pair of alias keys, and the memory device 130 may use data that is not yet known to the secure server 140 to generate the alias key pair 135.

Certificates presenting the public alias key may be generated and verified in the manner of fig. 2, where the secret key 137 is a device identification key generated using the device information 121 and the unique device secret 101. Optionally, the memory device 130 initially provides the certificate with the public alias key to the secure server 140. Memory device 130 may then use the private alias key as secret key 137 and either no public alias key is included in message 131 or no certificate for the public alias key is included in message 131.

Data 127 in message 131 signed to generate verification code 133 may include a challenge. For example, to challenge the memory device 130 to prove that it owns 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.

Further, verifying the identity of the memory device 130 may include using multiple secret keys and a verification code signed with the secret key. For example, the device identification secret key may be used to initially establish the authenticity of the alias secret key and the identity of the memory device 130, and subsequently, the alias secret key may be used to verify the authenticity of the identity of the memory device 130. In general, the device identification secret key and the alias secret key may be based on asymmetric encryption or symmetric encryption, as the secure server 140 may generate corresponding encryption keys generated by the memory device 130.

To increase security, memory device 130 does not use processing power external to memory device 130 to generate a copy of secret key 137 and does not transfer secret key 137 external to memory device 130. The generation and use of the secret key 137 is performed using logic of the encryption engine 107 sealed within the memory device 130.

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

The identity data 113 may be generated in response to memory device 130 powering up, in response to a request received in host interface 147, and/or in response to endpoint 150 booting (e.g., by executing a boot loader stored in memory unit 103). The data 127 may include a count value maintained in the memory device 130. When the operation of generating the identity data 113 is performed, the count value is incremented. Thus, a version of the identity data 113 having a count value that is lower than the count value invalidates a previous version of the identity data 113 having a count value that is lower than the count value.

FIG. 3 illustrates a technique for controlling command execution in a memory device, according to one embodiment. For example, the technique of FIG. 3 may be implemented in the computing system of FIG. 1 and used with the technique of FIG. 2.

In FIG. 3, 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 right to request the memory device 130 to execute the command 155.

Encryption key 145 is configured to represent rights. The sender of command 155 may generate authentication code 153 from encryption key 145 and message 151 containing command 155.

As discussed above, encryption key 145 and authentication code 153 of message 151 may be constructed and/or verified using various techniques, such as a hash digest, a digital signature, or a hash-based message authentication code, symmetric encryption, and/or asymmetric encryption. Thus, the verification code 153 is not limited to a particular implementation.

The access controller 109 verifies the verification code 153 of the command 155 submitted to the host interface 147 using the corresponding access control key 149. The access controller 109 uses the encryption engine 107 to generate a received message 151 and a verification result 159 of the received verification code 153. Based on the verification result 159, the access controller 109 may selectively allow the command 155 to execute within the memory device 130 or prevent execution of the command 155.

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

For example, encryption key 145 may be stored in secure server 140 to provide associated rights to secure server 140.

In one embodiment, the security server 140 is configured to generate the authentication code 153 on behalf of the entity in response to the entity requesting the authentication code 153 to execute the command 155 in the memory device 130.

Optionally, an encryption key 145 is generated during authentication of the identity data 113 generated using the secret key 137, and a secret known between the memory device 130 and the secure server 140 (e.g., the secret key 137) allows the session key to be generated as the encryption key 145 to represent the rights to execute the selected command in the memory device 130 during the communication session having the time limit. Optionally, the period of device power up may be used as a session delimiter such that a new count value is generated during the next power cycle, enabling the generation of a new session key.

The encryption key 145 may be configured to be valid for a short period of time after verifying the identity data 113 and establishing the session key. After the security server 140 verifies that the entity is authorized to run the command 155 in the memory device 130, the security server 140 may generate the verification code 153 and provide the verification code 153 to the entity. The entity may then send message 151 and authentication code 153 to 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 permits the memory device 130 to execute the received command 155, otherwise the access controller 109 may reject or ignore the received command 155.

In another embodiment, after the security server 140 configures the access control key 149 in the memory device 130, the security server 140 may provide the entity with an encryption key 145 that represents the rights to execute the command 155 in the memory device 130.

Message 151 may contain data 157 representing a restriction on the request to execute command 155.

For example, data 157 may include an execution count value maintained within memory device 130 such that a validation code generated for a lower count is invalidated.

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

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

For example, the data 157 may include an identification of a memory region in which the command 155 is allowed to be executed.

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

FIG. 4 illustrates a technique for verifying the integrity of data stored in a memory device, according to one embodiment. For example, the technique of fig. 4 may be used with the memory device 130 of fig. 1 and used in conjunction with the techniques of fig. 2 and/or 3.

In fig. 4, the memory device 130 stores not only the content 161 but also a hash value 163 of the content 161 in the memory unit 103. To determine the integrity state 165 of the content 161, the encryption engine 107 applies a cryptographic hash function to the content 161 to generate a current hash value of the content 161, and the encryption engine 107 compares the current hash value with the stored hash value 163 to determine if they are the same. If so, the integrity of the content 161 required by the stored hash value 163 is confirmed.

The hash value 163 may be stored as part of the device information 121 that is used to generate a secret key 137 to verify the identity of the memory device 130.

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

For example, a manufacturer of endpoint 150 may store content 161 into memory unit 103 such that processing device 118 of host system 120 in endpoint 150 may run programs or routines in content 161 to provide designed functionality of endpoint 150. Further, the manufacturer and/or the security server 140 may store the hash value 163 into a separate section for integrity checking. An end user of endpoint 150 may access and use content 161 in the memory unit, but may not access hash value 163. If the content 161 is corrupted or tampered with, the encryption engine 107 may detect the change and generate an integrity state 165 that causes the access controller 109 to prevent use of the content 161. When the manufacturer has an updated version of content 161 (or replacement), the manufacturer may perform the update in memory unit 103 and issue command 155 with authentication code 153 to update hash value 163. Optionally, the security server 140 may generate the verification code 153 in response to a request from the manufacturer.

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 via the access controller 109 by owner rights represented as the encryption key 106 stored in the secure server 140.

Different secrets (e.g., unique device secret 101, secret key 137) and content (e.g., device information 121, content 161) may be protected with different security levels and/or using different security policies to balance security and utility.

The unique device secret 101 may be protected in the memory device 130 with the highest security level. For example, the unique device secret 101 may not be changed via a command to the host interface 147 (and/or any interface of the memory device 130) once the memory device 130 leaves the memory device's manufacturing security facility and/or after the manufacturing operation of the memory device 130 is completed. Preferably, the unique device secret 101 is only accessible by the encryption engine 107 during generation of a secret key (e.g., 137) used to represent the identity of the memory device 130 and/or the endpoint 150. For example, the unique device secret 101 may be configured to be available only for a limited time when the endpoint 150 is booted.

For example, the device identification key may be protected by minimizing its use. The alias identification key is more secure than the device identification key and the replacement frequency is higher. Different operations and/or rights may be used to replace the device identification key and the alias identification key.

For example, the security services shown in fig. 5 may be implemented in the computing system of fig. 1 based on the security features shown in fig. 2, 3, and/or 4.

In fig. 5, a client server 141 is configured to provide services to computing devices, such as endpoint 150 in fig. 1 having a memory device 130 connected to host system 120.

To request a service from client server 141, host system 120 (e.g., executing instructions retrieved from memory device 130) requests identity data 113 of memory device 130. For example, the identity data 113 may be generated in the manner shown in fig. 2.

Host system 120 embeds identity data 113 in request 171 transmitted to client server 141.

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

The security server 140 may perform verification of the identity data 113, determine the authenticity of the memory device 130 and/or endpoint 150, and provide the results to the client server 141 in response 174. Based on the results, client server 141 may provide response 172 to host system 120.

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.

In some implementations, the request 173 can identify a command 155 to be executed in the memory device 130. After verifying the identity data 113 and verifying that client server 141 and/or endpoint 150 requests permission for command 155 to execute within memory device 130, security server 140 may generate an authentication code 153 for command 155 using encryption key 145 and provide authentication code 153 to client server 141 in response 174. Using the security service, the client server 141 can be freed from the security burden associated with the management of rights and the encryption key 145 representing the rights.

Optionally, response 174 may include encryption key 145 that represents the rights to execute command 155 in memory device 130. In order to reduce the security burden on client server 141, encryption key 145 may be configured to expire in a short time.

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 authentication code 153 such that when the command 155 is executed in the memory device 130, the access controller 109 may deactivate at least some features accessible to the host system 120 via the host interface 147.

For example, after executing command 155 in memory device 130, access controller 109 may be configured to disable a boot loader stored in memory unit 103 of memory device 130.

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

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

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

For example, command 155 may cause memory device 130 to perform self-destruct and irreversibly damaged.

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

The techniques discussed above may be used to implement new ways of authenticating a service subscriber.

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 the unique device secret 101 of the memory device 130, platform source code identifying one or more applications running on the endpoint 150 to establish a secure connection to a service or network (e.g., client server 141 or 143), and a unique identifier of the network interface 114 or communication device. For example, the unique identifier may be an identifier of a modem installed on endpoint 150 to communicate over communication network 110. For example, the multi-factor device platform identity may be based at least in part on an International Mobile Equipment Identity (IMEI) number of the endpoint 150 configured to access cellular services. For example, when endpoint 150 relates to a vehicle, the multi-factor device platform identity may be based at least in part on a Vehicle Identification Number (VIN). Such powerful identities may be used in connection with cloud-based Subscriber Identity Module (SIM) functions in log-in, network access and registration of cloud services (e.g., cellular subscription services).

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 endpoint 150 by measuring data stored in memory unit 103 of a secure memory device (e.g., 130). Additional network security protection of endpoints may be achieved by controlling access to content 161 stored in a memory device (e.g., 130). Access control may be implemented through secure hardware manufacturing operations and password-based admission control, as discussed above in connection with fig. 1-5. A platform equipped with such a memory device (e.g., 130) may reach a sufficient level of network security protection to support a cloud-based virtual SIM solution and no longer require a physical SIM card on endpoint 150 to access the cellular connection.

The secure memory device technology platform may include a combination of a secure memory device (e.g., 130) and software meeting DICE RIoT requirements for generating identity data 113 for an endpoint (e.g., 150) that is booted using the secure memory device. Such identity data 113 for endpoint 150 is generated based on the identity of secure memory device 130 used to boot endpoint 150 and other factors. Such identity data 113 may be transferred to the client server 141 during a login (e.g., registration service). Client server 141 may communicate with security server 140 to confirm the identity of endpoint 150. When identity data 113 is verified, client server 141 may trust endpoint 150 as authentic and thus register the service with endpoint 150.

For example, such services may be cellular connections that are typically registered with a physical SIM card. Identity data 113 verified by the secure memory device technology platform and secured by secure login may provide identification of the endpoint (e.g., 150) in the same or a more secure manner as if the endpoint were identified using a physical SIM card. The cloud-based virtual SIM may be bound to identity data 113 that the secure storage technology platform verifies during the service subscription lifecycle.

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

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 accounts for accessing cellular communication network services. When the SIM card is attached to the mobile telephone, the cellular communication network provides services to the mobile telephone in accordance with the account identified by the SIM card. When the SIM card is attached to the alternate mobile phone, the alternate mobile phone may access the services configured for the account.

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

The Europay MASTERCARD VISA (EMV) card is another example of a smart card. The EMV card may be used to receive financial services in a payment card processing network to access bank accounts, such as debit accounts and credit accounts.

The integrated circuit memory device 130 may be configured to prevent unauthorized access to its memory cells 103 and to ensure a unique identity of the memory device 130 itself and/or the endpoint 150 in which the memory device 130 is installed. As shown in fig. 6, a secure memory device 130 having a security feature may be used to implement the functionality of a smart card, such as a SIM card and an EMV card, using data supplied to the secure memory device remotely and/or using data stored in a secure server.

For example, the system and method of fig. 6 may be implemented in the computing system of fig. 1 using the techniques of fig. 2 through 5.

In fig. 6, the memory device 130 may be implemented using an integrated circuit memory device 130 having the security features of fig. 1-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 that access at least some memory regions in the memory device 130.

For example, memory device 130 is initially manufactured with access control keys 213, allowing secure server 140 to fully access memory regions in memory device 130. Memory device 130 is further manufactured to include at least a portion of device identification data 211 that uniquely identifies memory device 130 in a group of memory devices.

For example, the device identity data 211 may be generated using the technique shown in fig. 2.

For example, during manufacture of the memory device 130, a root secret (e.g., unique device secret 101) of the memory device 130 is loaded into the security server 140 in operation of the memory registration 231. The root secret may be a number generated by a Physical Unclonable Function (PUF) of the memory device 130 or a random number selected during manufacture of the memory device 130 and stored into the memory device 130. The secure server 140 may include a key management server configured to manage encryption keys for secure memory devices (e.g., 130). The root key may be considered and/or used as a secret encryption key. When the memory device 130 is manufactured, a root secret may be obtained from the memory device 130 or injected into the memory device 130 for memory registration 231. Preferably, the fabrication of the memory device 130 is such that after its fabrication, the memory device 130 does not provide a root secret outside of the memory device 130.

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

After the memory device 130 leaves the manufacturing facility, the root secret and other secrets in the device identity data 211 are not available via the communication interface (e.g., host interface 147) of the memory device 130. Because memory device 130 enforces a set of data access policies to prevent secret leakage and tampering of data stored in an access protected area of memory device 130, memory device 130 may be considered a secure memory device. The security server 140 stores information that may impersonate the computations performed by the memory device 130 to generate the derived secret independently of the memory device 130. Thus, the security server 140 can regenerate the derived secret of the memory device 130 without the memory device 130 having to communicate the derived secret via its communication interface (e.g., host interface 147).

For example, the root secret of the memory device 130 may be implemented via a Physical Unclonable Function (PUF). The root secret of the memory device 130 may be retrieved from the memory device 130 and stored into the security server 140 for memory registration 231 during manufacture of the memory device 130. The root secret may be used to generate a derived secret from the device identity data 211. For example, a PUF may be used to derive a diffie-Huffman (DIFFIE HELLMAN) key pair, and the diffie-Huffman key pair may be used to create a Unique Device Secret (UDS) 101 that may be securely shared between the device and a secure server.

For example, the device identity data 211 may be generated using the technique of fig. 2.

The derived secret is generated in a manner (e.g., based on a cryptographic hash function, a random number, and/or a monotonic count 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 comprise a private key of a pair of asymmetric encryption keys. For example, the derived secret may contain a symmetric encryption key.

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, among others. The public identification number may 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 may be used to authenticate/confirm that the memory device 130 is identified by the public identification number.

After the memory device 130 leaves the manufacturing facility, derived secrets in the device identity data 211 may be generated and/or replaced. The access control key 213 may be used to control the execution of operations that generate and/or replace derived secrets to prevent tampering. For example, the derived secret may contain encryption keys and/or certificates generated in accordance with the Device Identity Composition Engine (DICE) standard.

During memory registration 231, at least the root secret of memory device 130 is stored in secure server 140 in association with the public identification number of memory device 130. During the manufacturing process of the memory device 130, the root secret of the memory device 130 is known between the memory device 130 and the secure server 140 during the memory registration 231 in the secure environment. Additional information for generating the derived secret may then be disclosed without compromising the confidentiality of the derived secret. The derived secret may be used for authentication of the memory device 130 and may optionally be replaced.

The access control key 213 is configured to prevent unauthorized access and/or manipulation of secrets in the device identity data 211. For example, once access control key 213 is configured in memory device 130, the secret is limited for use by encryption engine 107 (e.g., regenerating the derivative secret and/or generating a digital signature). For example, a command/request received in the host interface 147 of the memory device 130 needs to be digitally signed in a manner that can be verified using the access control key 213, as shown in fig. 3. If the digital signature applied to the command/request is invalid according to the access control key 213, the command/request may be denied and/or ignored.

For example, the access control key 213 may be used to authenticate a digital signature applied on the command to perform certain operations related to the device identity data 211, such as replacing an encryption key or an asymmetric encryption key pair.

Further, one or more additional access control keys 213 may be used to authenticate the digital signature of the owner and/or authorized user of memory device 130. Different authorized users may be limited to accessing different areas of the memory device for specific operations (e.g., write, erase, read). Owners and other authorized users may have different scope and/or rights to operate memory device 130.

The security server 140 may be configured as the initial owner of the memory device 130. For example, the public key of the secure server 140 may be initially stored in the memory device 130 as an owner access control key 213 to provide owner rights for commands signed using the private key of the secure server 140. After the memory device 130 is delivered to the client, the client's public key may be stored as a substitute for the owner access control key 213 to transfer the owner rights to the client.

Optionally, a particular security function of the memory device 130 may be activated for the customer. Some aspects of the memory device 130 related to activation of security functions may be found in U.S. patent application No. 17/014,203, filed on 9/8 2020, entitled "customer specific activation of functions in semiconductor devices," the entire disclosure of which is hereby incorporated by reference.

Endpoint 150 may be configured 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 tracking data 215 may be stored into memory device 130.

For example, soft module 217 may include a boot loader of endpoint 150, memory device 130, and/or firmware of a memory subsystem containing memory device 130, or an operating system or software application of endpoint 150. Soft module 217 may contain instructions and data configured to implement functions. 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 processing device 118 of memory device 130 and/or host system 120 of the memory subsystem.

During endpoint construction 233, endpoint registration 235 may be performed to store tracking data 215 into security server 140 and/or memory device 130. The tracking data 215 may be part of the configuration and/or identity of the endpoint 150.

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

A counterfeit of endpoint 150 does not have trace data 215 and cannot pass endpoint authentication 239 that relies on trace data 215. Thus, the security of the system is improved. Additional details and examples of techniques related to tracking data 215 may be found in U.S. patent application No. 17/005,565, filed on 8/28/2020, entitled "secure memory system programming for host device authentication," the entire disclosure of which is hereby incorporated by reference.

Endpoint identity data 188 may be generated using the technique of fig. 2 to represent the configuration of endpoint 150 at its start-up time. For example, endpoint identity data 188 may include credentials (e.g., message 131) generated based on a combination of a portion of device identity data 211, tracking data 215, and identification data of other components (e.g., network interface 114, processing device 118, controller 116) that are present at the time of initiating endpoint 150.

The device identity data 211 and/or endpoint identity data 188 may include one or more certificates generated using a device identity composition engine (dic) according to standards developed by the Trusted Computing Group (TCG) that combine 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, filed on 4/2019, entitled "Login software on Security device for generating device identities for authentication with remote servers" and published on 10/2020, U.S. patent application publication Ser. No. 16/374,905, the entire disclosure of which is hereby incorporated by reference.

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

For example, endpoint 150 may connect to card server 223 to request a card profile 219 of endpoint 150 represented by device identity data 211. To request the card profile 219, the endpoint 150 transmits the public portion of the endpoint identity data 188 to the card server 223. The card server 223 forwards the endpoint identity data 188 to the security server 140 for authentication 239 of the endpoint 150. For example, the authentication techniques discussed in connection with fig. 2 may be used.

Once the security server 140 verifies that the endpoint identity data 188 was formed using the correct combination of device identity data 211, tracking data 215, and other data of the endpoint 150 of the memory device 130 submitted and/or recorded in the security server 140 during the endpoint registration 235, the card server 223 may 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.

The virtual card registration 237 may be performed via the protected soft module 217 in the memory device 130 and/or via the security manager such that the card profile 219 stored in the memory device 130 cannot be tampered with. Optionally, the security server 140 may generate a verification code for the command 155 to write the card profile 219 into the secure section of the memory device 130. The write rights of the secure section may be controlled via an encryption key stored in the secure server 140. For example, the access controller 109 may 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.

Further, the memory device 130 may verify the card profile and/or the integrity of the soft module 217 responsible for using the card profile 219 in the manner shown in fig. 4.

When the card profile 219 is protected in the memory device 130 in the endpoint 150, the memory device 130 and/or the endpoint 150 may operate in an equivalent manner as a corresponding smart card installed in the endpoint 150. The card profile 219 securely attached to the device identity data 211 may be regarded as a virtual smart card.

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

For example, card profile 219 may be as shown in fig. 7 and 8.

In fig. 7, 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.

The card data 241 may include identification of smart cards (e.g., virtual cards), accounts, and/or subscribers. For example, the card data 241 may identify the type of smart card, the services to which the account/card is subscribed, and/or customer data related to the services (e.g., margins, transaction records, messages, etc.). In some implementations, the 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).

The soft card module 243 may include instructions for operating on card data 241 through the encryption 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. Soft card module 243 allows endpoint 150 to simulate the computing operations of a physical smart card.

In fig. 8, the card profile 245 contains card data 241 such as an Integrated Circuit Card Identifier (ICCI) 251, a mobile device 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 mobile/cellular communication services of the international mobile subscriber identity number 255.

In a conventional mobile phone using a conventional SIM card, an Integrated Circuit Card Identifier (ICCI) 251 is used to identify the SIM card among a group of SIM cards. The mobile equipment identity number 253, for example in the form of an International Mobile Equipment Identity (IMEI) number or an IMEI software version (IMEISV), is used to identify a mobile phone among a group of mobile phones. International Mobile Subscriber Identity (IMSI) numbers are used to identify subscribers/customers/accounts among a group. Such numbering in the card profile 245 may be used for similar functions when the card profile 245 is attached to the endpoint 150. For example, when endpoint 150 is a mobile phone without a physical SIM card, card profile 245 may be used as a virtual SIM card to identify the card, subscriber, and endpoint/mobile phone. For example, integrated Circuit Card Identifier (ICCI) 251 corresponds to and/or represents device identity data 211 of memory device 130, mobile device identity number 253 corresponds to and/or represents endpoint identity data 188 of endpoint 150, and international mobile subscriber identity number 255 represents a subscriber/customer/account in a mobile/cellular communications network.

For example, authentication key 257 is a secret assigned to international mobile subscriber identity number 255. When endpoint 150 uses international mobile subscriber identity number 255 to request a connection in a mobile/cellular communications network, the mobile/cellular network operator may look up authentication key 257 from a database and challenge endpoint 150 to prove that it owns authentication key 257. The security challenge may include digitally signing a message including a random number (RAND) using an authentication key 257. The reply to the security challenge may contain a portion of a digital signature for verification by the mobile/cellular network operator. The operator signs the message independently using a corresponding authentication key 257 associated with the international mobile subscriber identity number 255 in the database. The digital signature is verified if the reply is consistent with the reply calculated by the mobile/cellular network operator, and thus, endpoint 150 is considered to have an authentication key 257 assigned to international mobile subscriber identity number 255 and is eligible to receive services associated with international mobile subscriber identity number 255. Further, symmetric encryption keys may be derived from the digital signature for protecting communications between endpoint 150 and the mobile/cellular communication network in subsequent communication sessions.

For example, when the card profile 245 is installed in the endpoint 150, the endpoint 150 may communicate with a mobile/cellular network operator to request a connection and respond to a security challenge using the same protocol used by a mobile phone with a physical SIM card. Thus, the mobile/cellular network does not have to distinguish between the endpoint 150 with the card profile 245 as a virtual SIM card and other mobile phones with physical SIM cards.

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

In fig. 6, after virtual card registration 237, endpoint 150 may receive services from card-based services network 225 using card profile 219 to identify a subscriber/customer/account. For example, the card-based services network 225, which is initially configured to provide services to legacy smart cards, may 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).

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

For example, endpoint 150 may function as a smart card for a card reader. The endpoint 150 may include metal contacts for connection to a card reader. For example, endpoint 150 may include a transceiver comparable to a card reader of a wireless smart card. Alternatively, additional card readers may be configured in the card-based services network 225 to read virtual cards from the endpoints 150 using alternative communication connections. Examples of alternative connections may include Near Field Communication (NFC) connections, bluetooth connections, wi-Fi connections, universal Serial Bus (USB) connections, and so forth.

In another example, endpoint 150 may function as a mobile station having a built-in card reader to read a smart card inserted into the mobile station, such as a mobile phone having a SIM card. Endpoint 150 may communicate with card-based services network 225 to access services 227 using the same communication protocol of a mobile station having a physical SIM card.

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

Optionally, virtual card registration 237 may be performed in time in connection with a request to access service 227. In response to the request, endpoint identity data 188 is verified by endpoint authentication 239. After the endpoint verification is successful, the card profile 219 may associate and/or store the card profile 219 with the endpoint identity data 188 in the memory device 130.

In some embodiments, the card server 223 is implemented as part of the security server 140.

In some embodiments, the card server 223 is implemented as part of a network operator of the card-based services network 225.

For example, the system of fig. 6 may be used to simplify, protect, and accelerate the large-scale global deployment of internet of things (IoT) devices and rich IoT service ecosystems. For example, a virtual Subscriber Identity Module (SIM) card may be used by an IoT device (e.g., endpoint 150) to connect to the internet through a mobile/cellular communication network.

The security server 140 may serve as a memory-based security-as-a-service platform for endpoints such as IoT edge devices (e.g., 150). The card server may be used to provide a cellular connectivity solution for such endpoints. The combination as shown in fig. 6 may create a generic end-to-end solution for zero-contact sign-in of cellular connected IoT devices onto cloud services.

The complexity of enterprise IoT implementations presents challenges to the large-scale global deployment of IoT devices. Challenges include implementation difficulties in cellular connectivity and network security. Cellular connectivity has significant advantages over wireless local area networks (e.g., wi-Fi) in terms of IoT deployment, such as greater distance, better outdoor performance, greater security, and existing global infrastructure. The requirement of a physical SIM card and the contract with the mobile/cellular network operator slow down the use of cellular connections by IoT devices. The solution shown in fig. 6 solves such challenges.

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 may eliminate the need for a physical SIM card. Deployment of virtual SIM cards provides highly scalable IoT security, cloud-based SIM management, secure zero-contact device registration and IoT service registration, fluent global connectivity, instant SIM activation.

The solution shown in fig. 6 is particularly advantageous for industrial, infrastructure, automotive, aeronautical, transportation and logistics departments, which need to provide a borderless long-range connection for portable devices even in the most remote locations, without being limited by the borders and the short-range Wi-Fi network.

The system as shown in fig. 6 can greatly simplify flexible global connectivity and provide rich possibilities for innovation of IoT markets.

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

The security server 140 may be used to implement zero-contact authentication and late-binding of credentials for third party services, enabling end users to freely and securely access more diverse third party IoT services.

The security server 140 and/or the card server 223 may be used to securely install soft modules to customize IoT devices. For example, an online soft module store may be provided to allow soft modules to be stored in endpoint 150, whose functionality is customized 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-independent IoT services to leverage and leverage intelligent features and data insight in new ways.

With the complex adverse behavior and hacking on devices from IoT fish tanks to baby monitors, etc., threat environments become more and more dangerous, network security has been a weak link for IoT adoption. The security server 140 may provide security as a service supported by security features implemented in a memory device (e.g., 130) that controls 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 layer of IoT software—starting from the boot process, and has an inherent strong cryptographic identity and security features in memory device 130.

For example, a 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 the memory device (e.g., 130) purported to have a common identification number by verifying whether the memory device (e.g., 130) has a root secret recorded via the memory registration 231 performed during manufacture of the memory device 130.

For example, the security-as-a-service may optionally further include identifying the owner of the memory device 130 based on an encryption key corresponding to the access control key 213 implemented to provide the owner rights.

For example, the security-as-a-service may optionally further include identifying the service provider of endpoint 150 with memory device 130 based on the identity of the owner/manufacturer of memory device 130 prior to distributing endpoint 150 to the end user/customer. Based on the service provider, the security server 140 may download soft modules 217 associated with the services provided by the service provider to customize the 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 the security server 140 and/or card server 223 may push the soft module 217 to the memory device 130. Further, in response to endpoint authentication 239, security server 140 may automatically push software updates into the memory device. Thus, security vulnerabilities of the field endpoint (e.g., 150) may be automatically reduced and/or minimized without requiring additional effort by the respective OEMs of the endpoint (e.g., 150).

For example, the security-as-a-service may optionally further include tracking of lost/stolen devices. In response to endpoint authentication 239 of endpoint 150 registering as lost or stolen in 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 particular memory region. In some cases, the access controller 109 may disable normal operation of the endpoint 150 by restricting access to resources such as boot loaders, operating systems, applications, and the like. In some cases, the access controller 109 may perform operations that irreversibly destroy memory functions of the memory device 130.

For example, the security-as-a-service may optionally further include an audit service of the integrity of endpoint 150. For example, memory device 130 may construct endpoint identity data 188 based on the cryptographic hash value of soft module 217 stored in memory device 130 such that when soft module 217 changes, security server 140 may verify whether current soft module 217 is a valid distribution from the corresponding vendor of soft module 217. When 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 an active distribution of the online software store.

When updated versions of soft module 217 are available, security server 140 may recalculate endpoint identity data 188 for authentication of endpoint 150. Thus, when endpoint 150 has an outdated soft module 217, security server 140 may detect the presence of an outdated version and request/initiate an update of soft module 217 over the air. Optionally, the security server 140 may track the configuration change history of the endpoint 150 affecting the endpoint identity data 188. For example, when requested, the security server 140 may communicate with the memory device 130 to revert to the previous configuration.

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

Endpoint identity data 188 may include the public identity of endpoint 150, such as an International Mobile Equipment Identity (IMEI) number (e.g., mobile equipment identity number 253). Subscription of the public identity of endpoint 150 to a service (e.g., cellular connection) of card-based services network 225 may be preregistered at card server (223) without using endpoint 150. For example, the IMEI number may be associated with an international mobile subscriber identity number 255 in a database of the card server 223.

When the endpoint 150 attempts to connect to the card-based services network 225, the public identity (e.g., IMEI number) of the endpoint 150 is authenticated in endpoint authentication 239 using endpoint identity data 188. In response, subscriptions registered with international mobile subscriber identity number 255 are identified and used to generate card profile 219 to bind card profile 219 to endpoint 150. The binding may be in the form of storing the card profile 219 in the secure memory device 130 in the endpoint 150. Alternatively, the binding may be in the form of the association of the card profile 219 with the endpoint identity data 188 in a database of the card server 223.

In some cases, a group of endpoints (e.g., owned by an enterprise client) may share a reduced number of virtual SIM cards to enable cellular connectivity. For example, ioT devices of an enterprise client may not need to be cellular connected at the same time. When the enterprise client's endpoint 150 requires a cellular connection, the available card profile 219, representing the virtual SIM card, is dynamically "installed" for the endpoint 150 after the endpoint authentication 239 during the communication session for cellular service in time. When the communication session ends, the virtual SIM card may be used by another endpoint of the enterprise client. The physical SIM card may be moved from one mobile phone to another to allow different mobile phones to access cellular services registered with the same SIM card. Physically moving the SIM card from one mobile phone to another is inefficient and cannot be deployed on a large scale. The immediate installation of the virtual SIM card may overcome the limitations of the physical SIM card and provide improved security via endpoint authentication 239 prior to installation of the virtual SIM card.

For example, such instant installation of a virtual SIM card may be used to facilitate infrequent or one-time use of cellular connections. For example, a cellular connection may be used to perform over-the-air firmware/software updates. For example, a cellular connection may be used to report the status of endpoint 150 periodically (e.g., daily, weekly, or monthly). For example, endpoint 150 may report its health and/or location associated with a warranty service based on the location of endpoint 150.

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

When such a secure memory device 130 is used with security, i.e., services, provided by the secure server 140, an Original Equipment Manufacturer (OEM) of the endpoint (e.g., 150) may provide security by assembling the secure memory device 130 into the endpoint (e.g., 150) without performing its separate security operations, such as secure key injection, designing and implementing secure elements, hardware components, or system-on-a-chip (SoC) features. Thus, the secure server 140 and the secure memory device (e.g., 130) may provide plug and play security for OEMs of IoT devices (e.g., endpoints 150).

The services of the secure server 140 may be used to authenticate, activate, and manage the secure memory device (e.g., 130) at the edge after deployment. This capability can extend throughout the life cycle from the manufacturing supply chain to field installation and management for platform reinforcement and device protection.

FIG. 9 illustrates a technique for authenticating a memory device according to one embodiment. For example, the technique of FIG. 9 may be used to implement the security service of FIG. 5 using the identity data of FIG. 2.

Through the authentication operation of fig. 9, session key 263 may be established to secure communications between secure server 140 and memory device 130 without trust in client server 141 to handle security to secure the secrets of memory device 130. Optionally, the session key 263 may be used by the access controller 109 to enforce the rights of the selected command 155 that is requested to be executed in the memory device 130.

In fig. 9, client server 141 may send request 271 to memory device 130 for identity data 113 of memory device 130.

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

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

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

To protect the response 273 and/or the verification code 133 from security attacks (e.g., re-use the response 273 and/or attempt to recover the key 137), the verification code 133 is generated for the message 131 containing the unique identification 111, the counter value 265, and the cryptographic random number 267. The counter value 265 is obtained from the counter 261 in the memory device 130. The value of the 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. Thus, a response containing a counter value 265 lower than the previously seen counter value may be deemed invalid. The cryptographic random number 267 is used once in the generation of the response 273 and is discarded by the memory device 130. When the cryptographic random number 267 has been previously provided to the secure server 140 or generated by the secure server 140, the response 273 does not have to explicitly include the cryptographic random number 267 in the response 273.

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 response 273, the secure server 140 may locate the corresponding encryption key 106 to verify the verification code 133. For example, the corresponding encryption key 106 may be the secret key 137, or a corresponding public key when asymmetric encryption is used.

Based on the verification of the verification code 133, the security server 140 provides the authenticity indicator 275 to the client server 141. The authenticity indicator 275 indicates whether the memory device 130 is authentic. For example, the security server 140 may generate and provide certificates signed by the security server 140 to extend the chain of certificates of the memory device 130 back to the verifier (e.g., the security server). Optionally, the secure server 140 may allow download of Certificate Signing Requests (CSRs) that allow requesters to use their selected Certificate Authority (CA) (instead of the secure server 140).

Through authentication of the memory device 130, the memory device 130 and the secure server 140 may establish a session key 263 for communicating with each other in a subsequent communication session. The session may be limited by a predetermined length of time period after verification of the response 273 or verification code 133. After the period of time, session key 263 expires and may therefore be destroyed or discarded. Further, subsequent requests for identity data may end a previous session that was started by a previous request for identity data.

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

For example, session key 263 may be derived based at least in part on secret key 137. Further, session key 263 may be based at least in part on counter value 265 and/or cryptographic random number 267. Optionally, session key 263 may be based at least in part on authentication code 133. For example, authentication code 133 and secret key 137 may be combined to generate session key 263.

In some implementations, the session key 263 is independent of the authentication code 133, and the authentication code 133 may be generated using the session key 263 derived from the secret key 137 or another secret known between the secure server 140 and the memory device 130.

FIG. 10 illustrates a technique for generating commands to control secure operation of a memory device, according to one embodiment. For example, the technique of fig. 9 may be used to implement the security service of fig. 5 using the techniques of fig. 3 and 10.

For example, after client server 141 requests authentication of the rights to execute command 155 in memory device 130 using client rights data 283, security server 140 may provide authentication code 153 of command 155 to client server 141 in response to request 281 from client server 141.

Some of the communications in fig. 9 and 10 may be combined. For example, in some cases, the request 281 may include the identity data 113 provided by the memory device 130 as a response 273 to the request 271 of the memory device 130.

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

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

In one embodiment, access control key 149 and encryption key 277 are preconfigured for the rights 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 may 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 of a pair of asymmetric keys that may be used to implement encryption key 277 and access control key 149 that involve encryption performed using asymmetric encryption.

When authentication code 153 is based on session key 263, authentication code 153 expires when session key 263 expires, which prevents reuse of authentication code 153 outside of the session for which session key 263 is valid.

The message 151 provided in the request 285 may contain the command 155 and the cryptographic nonce 287. The cryptographic random number 287 is arranged for the command 155/request 285 and is thus different from the cryptographic random number 267 used for transmitting the identity data of the memory device 130.

For example, in response to the request 281, the secure server 140 may generate a cryptographic random number 287 and use it to generate the authentication code 153. The cryptographic nonce 287 may be provided with the authentication code 153 for the client server 141 to generate the request 285. Alternatively, client server 141 may generate password random number 287 and provide it to security server 140 along with request 281. Alternatively, to generate request 281, client server 141 may request password nonce 287 from security server 140.

After client server 141 sends request 285 with authentication code 153 obtained from security server 140, memory device 130 verifies authentication code 153 of message 151 contained in request 285 using access control key 149. 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 command 155 from being executed in the memory device 130.

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

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

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

In some implementations, the replacement secret key used to replace the existing secret key 137 of the memory device 130 is generated by the memory device 130 and the secure server 140 independently from the secret (e.g., unique device secret 101) and additional data exchanged through the client server 141. Optionally, the additional data may be protected by encryption performed using session key 263.

In some implementations, the replacement secret key is transferred from the memory device 130 to the secure server 140 in an encrypted form using ciphertext generated by the session key 263.

Fig. 11 illustrates a method of virtualizing a smart card according to one embodiment. For example, the method of fig. 11 may be implemented in the system shown in fig. 6 with the security features of the security server 140 and memory device 130 discussed above in connection with fig. 1-5 using the techniques of fig. 9 and 10.

At block 301, device identity data 211 representative of the memory device 130 is generated by logic circuitry or a controller in an integrated circuit package that encloses the memory device 130 based at least in part on a root secret of the memory device 130.

For example, the memory device 130 may have a Physical Unclonable Function (PUF) to generate the root secret.

For example, the logic circuit or controller may include an encryption engine configured to perform encryption calculations without using a processor external to the integrated circuit package.

At block 303, the memory device 130 stores device identity data 211 in a first memory region of integrated circuit memory cells formed on one or more integrated circuit dies enclosed within the integrated circuit package.

At block 305, logic circuitry controls access to the first memory region based on the access control key 213.

At block 307, the memory device 130 stores in a second memory region of the integrated circuit memory unit a startup instruction executable by the endpoint 150 having the memory device 130 as one of the plurality of components of the endpoint 150.

For example, the device identity data 211 may be calculated and/or updated based on a hash value resulting from applying a cryptographic hash function to the boot instructions stored in the second memory region of the memory device 130. Thus, the device identity data 211 may lock not only the hardware of the memory device 130, but also the boot instructions (and/or other data, such as the trace data 215) stored in the memory device.

At block 309, the card profile 219 is written to an integrated circuit memory unit of the memory device 130 to simulate the functionality of the smart card based on the card profile 219.

For example, endpoint 150 may be configured via memory device 130 to generate endpoint identity data 188 representative of the component configuration of endpoint 150 at its startup time. Endpoint identity data 188 may be calculated using device identity data 211, trace data 215 stored into memory device 130 during construction 233 of endpoint 150, and identification data of components of endpoint 150 that are located outside the integrated circuit package of memory device 130.

For example, card profile 219 may identify, generate, and/or be assigned to endpoint 150 based on authentication of endpoint identity data 188.

For example, card profile 219 may include a soft module (e.g., soft card module 243, authentication module 259) with instructions executable by logic circuits or a processor of endpoint 150, or any combination thereof, to simulate the functionality of a smart card.

For example, the card profile 219 may be stored in the memory device 130 to simulate 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.

For example, when the endpoint 150 requests a cellular connection to the international mobile subscriber identity number 255, the mobile/cellular network operator may issue a security challenge to authenticate the endpoint 150. In response, the card profile 219 may be used to generate a response to the security challenge by signing a message with a random number using the authentication key 257 to prove that the endpoint owns the authentication key 257. For example, a message with a random number may be signed using authentication key 257. The response to the security challenge may include a portion of a digital signature for authentication, and another portion of the digital signature may be used as a symmetric encryption key for encrypting a communication session associated with the cellular connection.

FIG. 12 illustrates a method of security services provided based on security features of a memory device, according to one embodiment. For example, the method of fig. 12 may be implemented in the computing system of fig. 1 based on the security features of the memory device 130 discussed above in connection with fig. 1-5 using the techniques of fig. 9 and 10.

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

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

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

At block 325, the security server 140 generates the verification code 153 for the command 155.

For example, after determining that client server 141 has the authority to execute command 155 in memory device 130 based on client authority data 283 stored in secure server 140, authentication code 153 may be generated for client server 141 and provided in response 174 based on the authority.

For example, after determining that memory device 130 is in an endpoint 150 that has reported lost or stolen, an authentication code 153 may be generated for command 155 to deactivate memory device 130.

At block 327, the security server 140 transmits a response 174 containing the authentication code 153 to the client server 141.

For example, response 174 may be based on determining that memory device 130 has a secret when identity data 113 contains an authentication code 133 that is generated using the secret.

At block 329, client server 141 transmits command 155 and authentication code 153 to memory device 130.

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

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

For example, when executed in memory device 130, command 155 causes a change in the setting of the security features of memory device 130. For example, the change may include activation of a security feature of the memory device 130 or deactivation of a security feature.

For example, after an endpoint 150 containing memory device 130 has reported lost or stolen, when executing in memory device 130, command 155 causes memory device 130 to disable the boot loader stored in memory device 130.

For example, when executed in memory device 130, command 155 causes access controller 116 to block access to one or more sections of memory cells 103 in memory device 130.

For example, when executed in memory device 130, command 155 causes memory device 130 to clear a decryption key for data stored in memory device 130.

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.

For example, based on authentication of the identity data 113, the session key 263 may be established and known between the secure server 140 and the memory device 130 without transferring the session key 263 via a connection between the secure 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 may be based on the session key 263.

Optionally, the security server 140 may cause the command 155 and the authentication code 153 to be transmitted to the memory device 130 based on instructions loaded from the memory device 130 and executed in the host system 120.

Fig. 13 illustrates a method of logging into an endpoint of a service subscribed to by an account, according to one embodiment. For example, the method of fig. 13 may be implemented in the computing system of fig. 1 based on the security features of the memory device 130 discussed above in connection with fig. 1-5 using the techniques of fig. 9 and 10.

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.

For example, the server system may include a secure 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.

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.

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

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

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

When endpoint 150 is transferred from the manufacturer to the dealer and end user or subscriber, data associating the public identity of endpoint 150 with the identity of the subscriber is stored in the server system. Ownership data may be stored in the server system without physically manipulating the endpoint 150 (e.g., without opening a package that encloses the endpoint 150 since the endpoint 150 was manufactured). For example, the public identification of endpoint 150 may include 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.

When a subscriber opens an account for a service provided to endpoint 150, the subscriber's identity may be associated with the account.

For example, client rights data 283 may include ownership data of endpoint 150 and/or subscriber data exposing a subscriber account.

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

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

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

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

In an alternative embodiment, the client entitlement data 283 stored in the secure server 140 indicates an association between the identity data 113 and the identity of the subscriber as the owner. Thus, during verification of the authenticity of endpoint 150 based on received identity data 113, the subscriber may be identified from client entitlement data 283. Another server (e.g., client server 141 or card server 223) stores subscriber data to identify accounts based on subscribers identified by secure server 140.

Using the method of fig. 13, services of account subscriptions may be provided/directed to an endpoint 150 without customizing the endpoint 150 itself for the subscriber and/or the subscriber's account. For example, a subscriber may simply open the package enclosing endpoint 150 during manufacture of endpoint 150 and use endpoint 150 to access services subscribed to by a subscriber account without having to insert a card (e.g., a SIM card) to identify the subscriber or account and/or without having to interact with an application or utility running in endpoint 150 to identify the subscriber or account.

For example, after endpoint 150 is manufactured, endpoint 150 is not customized for the subscriber nor for the account prior to the request received in block 341. Endpoint 150 is manufactured to be usable by any one of a plurality of subscribers. In response to the request received in block 341, endpoint 150 automatically links to a particular account of the subscriber obtaining the service.

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

For example, endpoint 150 is free of data stored into endpoint 150 to represent a subscriber, an account, or any combination thereof, at least prior to the request received in block 341.

For example, the endpoint 150 does not contain an indication of a subscriber, account, or any combination thereof, and does not have ownership data for the endpoint 150, at least prior to the request received in block 341, and the ownership data is stored in the server system and not in the endpoint 150.

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.

For example, secure server 140 may generate authentication code 153 for command 155 using encryption key 145. The server system may cause the memory device 130 to receive the command 155 and the verification code 153. Prior to executing command 155 in memory device 130, access controller 109 of memory device 130 is configured to verify authentication code 153 based on access control key 149. Optionally, access control key 149 and encryption key 145 may be based on session keys established in the manner discussed in fig. 9.

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

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

Because operations on the endpoint 150 are not required to direct services of the subscriber's account to the endpoint 150, the endpoint 150 may be configured as an IoT device with cellular connectivity capabilities without requiring a user interface for its customization to receive cellular connectivity services. For example, endpoint 150 may be configured without a slot for inserting a card to identify a subscriber. For example, endpoint 150 may be configured without a user interface for receiving input from an end user to identify a subscriber.

In some embodiments, endpoint 150 has a general purpose hardware configuration that may run different firmware to provide different functions. In addition, updated versions of firmware may be installed in endpoints 150 to correct defects or errors in endpoints 150 running previous versions of firmware to improve performance and/or provide new functionality. Optionally, firmware applications may run on the base version of firmware to add functionality, features, and/or services.

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 the endpoint 150, but perform different processes implemented using different firmware.

After the endpoint 150 is assembled by installing different firmware and shipped to an end user or subscriber, the endpoint 150 may be customized for different client servers 141, 143.

For example, an online firmware store may be configured on communication network 110 to allow an end user to purchase a version of firmware. Installing the selected version of firmware may or may not include installing a firmware application running 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 endpoint 150 running the previous firmware.

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

The functionality of endpoint 150 may be defined, at least in part, by its firmware. For example, endpoint 150 may provide one function to a user of endpoint 150 when endpoint 150 runs one version of firmware, and endpoint 150 may provide a different function to a user of endpoint 150 when endpoint 150 runs another version of firmware.

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, firmware provided in an online store may be programmed to enable a generic IoT device to cooperate with a third party server to provide a particular type of service. Optionally, a firmware application provided in the online store may run on a generic version of the firmware and use the basic services provided by the generic firmware to provide a specific type of service. The combination of the baseline version of firmware and the firmware application may be considered an enhanced version of firmware. When the baseline version of 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 depend on the device and use different hardware capabilities of different vendors.

The security server 140 may be coupled to an online firmware store to provide firmware updates to endpoints (e.g., 150) in response to verifying the authenticity of the endpoints.

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 may be determined during the verification process. After the subscription service of endpoint 150 is identified, the relevant firmware application may be downloaded from the online firmware store and installed into endpoint 150 through over-the-air (OTA) updates.

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 in generating updated secret key 137 for updated identity data 113 of memory device 130 and endpoint 150.

Later, when there is an update of a firmware application in the online firmware store, an out-of-date firmware application in endpoint 150 may be detected during verification of identity data 113, and security server 140 may initiate an over-the-air (OTA) update for endpoint 150 to reduce security risks.

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

For example, a user of endpoint 150 may access an online store to subscribe to services of service providers, alter subscribed services, and/or move subscriptions from one service provider to another. Subscriptions subscribed to by a user for endpoint 150 may be tracked as part of client rights data 283 associated with the identity of endpoint 150. When the security server 140 verifies the identity data 113 of the endpoint 150, the security server 140 may check whether the endpoint 150 requires a firmware update for subscribing to the service and/or replacing an outdated version of firmware. If so, the security server 140 may cause the firmware update to customize and/or update the endpoint 150 via the online store before the endpoint 150 receives the subscribed services from the service provider. Optionally, the security server 140 communicates with the endpoint 150 to direct the endpoint 150 to the current client server 141 of the service provider. Alternatively, the updated firmware causes endpoint 150 to connect to the service provider's current client server 141.

In general, the security server 140 may be connected to or include an online service store and/or an online firmware store. The server system may have a security server 140, an online service store, and/or an online firmware store. The server system may track accounts for subscribing to services of different service providers and track firmware customizations selected/purchased by users of the endpoints (e.g., 150).

The account of the user of endpoint 150 is tracked with the identity of the user that may be used by the service provider subscribed to endpoint 150 and is associated with the identity of the user that is the owner of endpoint 150 for automatic firmware update. By correlation, firmware and/or service selections made by a user in an online service store and/or online firmware store may be mapped to the user's endpoint 150. Alternatively, a user of endpoint 150 may use the public identification of endpoint 150 as part of identity data 113 of endpoint 150 to explicitly select firmware and/or services for endpoint 150.

In some embodiments, endpoint 150 initially connects to security server 140 for the service. The security server 140 may identify the current provider of subscription services registered in the online service store based on the client rights data 283. After verifying the authenticity of endpoint 150 and determining the service provider, security server 140 configures the firmware of endpoint 150 for the service provider (e.g., using an online firmware store) and directs endpoint 150 to the service provider's client server (e.g., 141,..or 143). Thus, endpoint 150 may seamlessly provide services subscribed from an online service store with minimal user effort.

FIG. 14 illustrates an endpoint customization technique using an online firmware store, according to one embodiment. For example, the techniques of fig. 14 may be implemented in the computing systems of fig. 1 and/or 6 with the security services and features discussed with reference to fig. 1-5. The technique of fig. 14 may be used in combination with the techniques of fig. 9 through 13.

In fig. 14, online firmware store 170 is configured to facilitate selection of firmware and/or firmware applications for endpoint (e.g., 150) customization and/or updating, and verification of the identity of endpoint (e.g., 150) by security server 140.

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

A manufacturer of endpoint 150 may install a baseline version of firmware 363, this firmware 363 programmed to allow endpoint 150 to generate and submit identity data 113 for verification by security server 140. The baseline version of firmware 363 is further configured to facilitate updating of firmware via the firmware store 170 and verification of the identity data 113 by the security server 140.

In general, firmware updates for endpoint 150 may be to replace the entire firmware 363 executing in host system 120, or to add and/or replace one or more firmware applications (e.g., application 367,..369).

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

In some embodiments, firmware 363 may be customized via one or more firmware applications (e.g., application 367,..369). For example, endpoint 150 running firmware 363 may further run an optional application (e.g., application 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 forth.

For example, when a firmware application (e.g., application 367) runs on firmware 363 in endpoint 150, endpoint 150 is customized to communicate with 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 differently to communicate with another client server 143 of a different service provider to implement and/or receive alternative or similar services from the different service provider.

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

For example, a firmware application (e.g., application 367) may be programmed to perform new computing functions that generate new types of results.

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 of endpoint 150, data storage facilities of client server 141 for data generated by endpoint 150, messaging facilities for notifications and/or alerts for one or more other devices associated with endpoint 150, connections via client server 141 and one or more other devices associated with endpoint 150, internet access of endpoint 150 via Wi-Fi access points, communication satellites, and/or communication connections or devices controlled by client server 141, and the like.

In general, different service providers may provide different versions of firmware and/or different firmware applications to customize endpoints (e.g., 150) in the same endpoint platform 361. The endpoints in platform 361 may be manufactured and/or assembled by the same manufacturer or by different manufacturers.

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

The use of firmware applications (e.g., applications 367,..369) may reduce the size of data to be downloaded from firmware store 170 to endpoint 150 when performing firmware updates. Alternatively, different sets of firmware functions may be implemented using different firmware (e.g., 363, 365) without the need for additional firmware applications. In general, firmware updates in endpoint 150 may involve replacing the entire existing firmware 363 or installing a firmware application (e.g., application 367).

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

In general, user computer 180 may be distinct and separate from endpoint 150. Thus, there is no need for hardware and/or software interfaces that are accessible to users of the endpoint 150 to customize the endpoint 150 for use with accounts and/or service providers. Optionally, the endpoint 150 of some embodiments and/or classes may include a user interface that allows it to function as a user computer 180 to subscribe 371 to firmware for the endpoint 150.

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), an alternate version of firmware, or a combination of an alternate version of firmware and a firmware application. The user's order may be identified as a service subscriber and/or endpoint 150 as a device to be customized.

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 device identity number 253, international mobile subscriber identity number 255, unique identification 111, and/or another identifier contained in data 127 of identity data 113.

For example, the identity of the user or subscriber may be identified via an account identifier and/or a piece of information identifying the individual, such as an email address, telephone number, name and address, and so forth.

The security server 140 may verify 373 identity data 113 submitted from the endpoint 150 and/or its memory device 130, as discussed above in connection with fig. 2,5, and 9.

In general, the identity data 113 may be submitted to the security server 140 via a client server (e.g., 141 or 143), via the firmware store 170, via another server or gateway, or without going through any of the client server 141, the..the 143, and the firmware store 170.

For example, endpoint 150 may be configured via existing firmware 363 to automatically access firmware store 170 and/or security server 140 for authentication, firmware update, and/or service customization. Thus, the identity data 113 may be submitted to the security server 140 via the firmware store 170 in some cases, and directly to the security server 140 in other cases.

For example, when a server (e.g., client server 141 or 143, firmware store 170, or another server) receives identity data 113 of request 171 from endpoint 150, the server (e.g., 141) provides identity data 113 to secure server 140 for verification in request 173. In response to such a request 173, the security server 140 may communicate with the firmware store 170 to identify 375 whether a firmware update exists for the endpoint 150. If so, the security server 140 may cause the firmware store 170 to update 377 the firmware of the 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, command 155 signed using encryption key 145 is executed in memory device 130 to cause the new version of firmware and/or firmware application (e.g., application 367) to be executed in memory device 130 and become part of the identity of memory device 130 and/or endpoint 150.

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 providing a new version of firmware 363 in firmware store 170 for accessing the same services of client server 141, security server 140 may initiate installation of the new version in response to successful verification of identity data 113. Optionally, the update 377 may be implemented via a firmware application (e.g., application 367) installed to run on existing firmware 363, or via installation of new firmware (e.g., 365).

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

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

In general, firmware updates may include installing a firmware application (e.g., application 367), replacing an existing firmware application with another firmware application, and/or installing new firmware 365.

After identifying the desirable firmware update, the firmware store 170 communicates with the endpoint 150 to update 377 the endpoint 150.

The access controller of memory device 130 is configured to require verification of the authority that requests memory device 130 to execute command 155 to change the firmware stored in memory device 130.

For example, after the data required for the firmware update is stored into a section of memory device 130, command 155 may be sent to host interface 147 to perform the operation of the firmware update in memory device 130. The rights to execute command 155 in memory device 130 may be represented by encryption key 145. Encryption key 145 may be previously configured or generated in response to verifying identity data 113 from memory device 130 of endpoint 150. For example, encryption key 145 may be session key 263 generated in a similar manner to FIG. 9 based on verifying the authenticity of endpoint 150, and security server 140 may use encryption key 145 to generate verification code 153 for the command for firmware store 170 to update endpoint 150. Alternatively, security server 140 may provide session key 263 and/or encryption key 145 to firmware store 170 to update 377 the firmware of endpoint 150.

After successful firmware update, the device information 121 for generating the secret key 137 is updated to reflect the installed firmware and/or firmware application. For example, the hash values 163 of the installed firmware and/or firmware applications may be stored as part of the device information 121 for verifying their integrity, as shown in fig. 4. The identity data 113 generated by the memory device 130 of the endpoint 150 is then based on the updated device information 121 and reflects the configuration of the endpoint 150 with updated firmware functions or configurations.

In some embodiments, firmware store 170 is part of a server system that implements security server 140. In another embodiment, firmware store 170 is hosted on a separate server computer.

In some embodiments, the update 377 of the firmware may be performed automatically based on services subscribed to for the endpoint 150, as discussed further below in connection with fig. 15.

FIG. 15 illustrates a technique for directing services to endpoints via an online service store, according to one embodiment. For example, the technique of fig. 15 may be used in combination with the technique of fig. 14.

In fig. 15, online service store 190 is configured to facilitate selection of one 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) may be implemented via one or more endpoint platforms (e.g., 361, 362).

For example, a user of endpoint 150 may access online service store 190 using computer 180 to subscribe 391 to services with service provider 381 using computer 180. The services provided by service provider 381 may be used with endpoints of multiple endpoint platforms (e.g., 361, 362). Endpoints (e.g., 150) in endpoint platforms (e.g., 361,., 362) run different firmware to obtain services of service provider 381. The service store 190 has subscription data 387 that identifies services and/or endpoints (e.g., 150) subscribed to by the subscriber.

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

For example, endpoint 150 may be expressly subscribed to with reference to the public identification of endpoint 150, the model and serial number of endpoint 150, mobile device identity number 253, international mobile subscriber identity number 255, unique identification 111, and/or another identifier contained in data 127 of identity data 113.

Alternatively or in combination, the service may be subscribed with reference to the identity of the user or subscriber, which may be identified by an account identifier and/or a piece of identifiable personal information, such as an email address, telephone number, name and address, etc.

As in fig. 14, 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 a computer 180 to subscribe 391 to services for endpoint 150.

When implicitly subscribing to a service for an endpoint 150, the identity of the subscriber may be used to determine the service of the endpoint of the subscriber based on a match of the identity of the subscriber for subscribing to the service with the identity of the owner of the endpoint 150.

For example, to subscribe to 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 services of service provider 381.

In response to the service being subscribed to or changed, or in response to the identity data 113 of the endpoint 150 being verified, the security server 140 and the service store 190 may communicate with each other to identify 393 the service subscribed to for the endpoint 150.

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.

In general, the service request 171 may be received initially in a client server (e.g., 141 or 143) or in the service store 190 or firmware store 170 or directly in the security server 140.

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

Based on the identified services, the security server 140 may communicate with the firmware store 170 to identify 375 firmware updates for the endpoint 150. For example, endpoint 150 may be updated via replacement firmware or installation of a firmware application (e.g., application 367) to customize endpoint 150 for subscribed services. Firmware updates may be performed and protected in the manner discussed above in connection with fig. 14.

For example, endpoint 150 may be manufactured using a generic version of firmware 363, which firmware 363 is unable to receive 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. Firmware applications (e.g., application 367) may be installed on generic firmware 363 to customize endpoint 150 for the services subscribed to endpoint 150. Once customized via a firmware application (e.g., application 367), endpoint 150 may receive services of service provider 381 from client server 141. For example, after installing a firmware application (e.g., application 367) to update 377 the firmware, endpoint 150 has knowledge about client server 141, communication capabilities to communicate with client server 141 according to the communication protocol used by client server 141, and processing routines for using services provided by client server 141.

For example, services subscribed to for operation of endpoint 150 may include calculations performed by client server 141 to process data of endpoint 150, storing in client server 141 data generated by endpoint 150, sending notifications and/or alerts to one or more other devices associated with endpoint 150, connecting endpoint 150 to a computer network or the internet via client server 141 and one or more other devices associated with endpoint 150, using a cellular base station, wi-Fi access point, communication satellite, and/or communication connection or device controlled by client server 141, and so forth.

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

In general, the service store 190 may be used by a user (or a representative of a user) to subscribe to services of the service provider 381 for the endpoint 150, alter the subscribed services, and move subscriptions from one service provider 381 to another. Firmware 363 of endpoint 150 is automatically updated to support the currently subscribed-to service without requiring the user of endpoint 150 to operate on endpoint 150 to customize endpoint 150 for the subscribed-to service.

FIG. 16 illustrates a firmware update method using a firmware store and a secure server, according to one embodiment. For example, the method of fig. 16 may be implemented using the technique of fig. 14.

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

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

For example, endpoint 150 may be in a state shipped from an endpoint (e.g., 150) manufacturer without customization for a particular server and/or service provider.

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 of memory device 130 and identity data 113. For example, the operations in block 403 may be performed in a manner similar to the operations performed in block 323 and/or block 343.

For example, the identity data 113 contains a verification code 133 of the message 131 presented in the identity data 113. The security server 140 may verify that the verification code 133 was generated using the secret key 137 of the memory device 130 and the message 131 without the endpoint rendering the 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.

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 memory device 130 and executed in endpoint 150 to generate the request received in block 401.

For example, before receiving the request in block 401, firmware store 170 may receive an order 391 for firmware of endpoint 150. An order 391 may be made to customize the functionality of endpoint 150 using user computer 180 without going through endpoint 150. Orders 391 received in firmware store 170 may be used to identify 375 updates 377.

For example, the order 391 of the endpoint 150 may be identified using the public identification of the endpoint 150. The identity data 113 may contain a public identification in the message 131 signed using the secret key 137 to generate the verification code 133 provided in the identity data 113. After verification message 131 has not changed, security server 140 may instruct online firmware store 170 and/or endpoint 150 to update 377 firmware 363 of endpoint 150.

At block 407, in response to determining that endpoint 150 is authentic, the server system generates an authentication code 153 for command 155 executable in memory device 130 to perform the update.

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

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

For example, the data downloaded to the memory device 130 may include a 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.

For example, the data downloaded to the memory device 130 may include a firmware application (e.g., application 367) that runs with the first firmware executed to generate the request after executing the command 155 for a firmware update. The combination of the firmware application (e.g., application 367) and the first firmware provides the second firmware of endpoint 150.

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

After executing command 155 for 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 secret key 137 that represents the identity of memory device 130 and endpoint 150. After executing the command 155 to update 377 the firmware, the device information 121 is updated to include the hash value 163 of the second firmware stored as content 161 in the memory unit 103. Subsequently, the memory device 130 is configured to generate the identity data 113 of the endpoint 150 using an encryption key that is generated based at least in part on the secret of the memory device (e.g., the unique device secret 101) and the second firmware stored in the memory device 130.

FIG. 17 illustrates an endpoint customization method using a service store and a security server according to one embodiment. For example, the method of fig. 17 may be implemented using the techniques of fig. 14 and 15.

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

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

At block 423, the security server 140 verifies the identity data 113 in response to the request received in block 421 and based on the information about the endpoint 150 stored in the security server 140. Such information includes the secret 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 endpoint 150. Verification may be performed in the manner discussed above in connection with fig. 2.

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 services subscribed to for the endpoint 150 in the online service store 190.

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

For example, prior to receiving the request in block 421, the online service store 190 may receive an order 391 for the services of the endpoint 150. Client server 141 may identify based on order 391.

For example, order 391 may be received in online service store 190 through user computer 180 and thus not through endpoint 150. Order 391 for endpoint 150 may be identified/placed using the common identification of endpoint 150. The identity data 113 may include public identification. Alternatively, order 391 may be associated with the identity of the user that is the owner of endpoint 150 in the client entitlement data 283 of the security server.

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

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 subscribed to in the online service store 190.

For example, to configure endpoint 150 for a service, the server system may update the firmware of endpoint 150. For example, firmware updates may be performed in the manner discussed above in connection with fig. 14-16.

For example, endpoint 150 cannot receive services from client server 141 before firmware update 377 and has no knowledge about client server 141. For example, an endpoint 150 initially configured by the manufacturer of the endpoint (e.g., 150) is programmed to access the service store 190, the firmware store 170, the security server 140, or another gatekeeper so that the endpoint 150 can be properly configured and/or updated for use without requiring the end user to operate the endpoint 150 to customize.

For example, after firmware update 377, the 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 contain an identification of the client server 141 for directing the endpoint to access the client server 141 to obtain the services subscribed to in the 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 based at least in part on the secret (e.g., unique device secret 101) and the second firmware stored in memory device 130.

Optionally, to configure the endpoint 150 for a service subscribed to in the service store 190, the server system identifies an account for subscribing to the service for the endpoint 150. The memory device 130 is configured to store an identifier of the account and to include the identifier in the updated identity data 113 as part of the message 131.

For example, to perform firmware update 377, the server system may generate verification code 153 for command 155 using encryption key 145 that represents the rights 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 the memory device 130 receives the command 155 and the verification code 153, the memory device 130 verifies the verification code 153 for the rights before executing the command 155.

The security server 140 may 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 may also be used to monitor the integrity of packets stored in the memory device 130 and/or the endpoint 150. For example, a package stored in endpoint 150 may be at least a portion of a boot loader, firmware, software, a module, an operating system or application, a set of files specifying resources, configuration parameters, and/or other data for a program or routine, and so forth. When a packet is found to be corrupted, modified, tampered with, or over-the-air (OTA) update may be initiated by the security server 140 to maintain the integrity of the endpoint 150.

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, as shown in fig. 4. When the current hash value calculated from 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 may detect modification or corruption of the content 161 and initiate a content repair.

For example, content 161 may comprise a core package of endpoint 150. Upon verifying 373 the identity of endpoint 150, the integrity of the core package may affect the operation of endpoint 150 in communicating with security server 140. Examples of core packages may include at least a portion of a boot loader, firmware, and/or operating system of endpoint 150. When the core package is modified, damaged, or tampered with, the security of the operations of endpoint 150 performed for authentication may not be trusted. When the integrity status 165 generated by the encryption engine 107 indicates a change in the core packet, the access controller 109 may prevent the host system 120 from accessing the content 161 until the core packet is repaired.

For example, memory device 130 may store reliable backup copies of the core package in separate sections, and when the hash value of the core package in content 161 stored in memory unit 103 is different than 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 sections. Optionally, execution of the alternate copy in endpoint 150 may be configured to begin a recovery process to obtain the latest version of the package from a reliable source (e.g., firmware store 170). Alternatively, the security server 140 may initiate the update (e.g., using the firmware store 170) after verifying the identity data 113 of the memory device 130 and/or endpoint 150 submitted via the replacement copy.

Some packets stored in memory unit 103 have no impact on the security of the initial operation of verifying 373 identity data 113 of endpoint 150 and subsequent operations of updating endpoint 150. Thus, it is not necessary to store a recovered copy of such packets in memory device 130. Repair and/or update of such packages may be performed via the secure server 140. For example, when the integrity state 165 indicates that the non-core packet has changed, the access controller 109 may prevent the host system 120 from accessing the corrupted or changed packet until the endpoint 150 communicates with the security server 140 to repair or recover the corrupted packet.

Optionally, the data 127 provided in the identity data 113 may include the current hash value of the packet in the content 161 stored in the memory unit 103. During operation to verify 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 changed, been corrupted, or is outdated, the security server 140 may initiate repair or restoration of the packet.

Further, 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 the host system 120 may generate the current hash value of the packet as a health indicator of the packet. The health indicator may be provided as part of the data 127 embedded in the identity data 113 of the endpoint 150 to allow the security server 140 to monitor the integrity of the package.

In general, the identity data 113 may include data indicating the health of packets in the endpoint 150. As part of the operation of verifying 373 the identity data 113 of the endpoint 150, the security server 140 may determine whether any packets are to be repaired and/or updated. The repair or update may be performed before the security server 140 confirms the authenticity of the endpoint 150.

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

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 a client server (e.g., 141,..143) in identity data 113 and/or request 173 to verify identity data 113.

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

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 unique identification 111 of endpoint 150, but also a context and/or aspect of the service, such as identification of client server 141, location of endpoint 150, date and time of request, class/type of service, parameters of the service, and so forth.

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

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

Optionally, the owner or user of endpoint 150 may access the portal of security server 140 to view the tracked activity. For example, based on the tracked activity, an owner or user may determine whether endpoint 150 is stolen or lost from one or more recent locations of endpoint 150.

Optionally, the parent may use the portal of the security server 140 to set parental control preferences to limit the activity of the endpoint 150, and the security server 140 may enforce the limit preferences in connection with authenticating the identity of the endpoint 150.

For example, the technique of fig. 18 may be used with the computing systems of fig. 1 and/or 6 having the security services and features discussed with respect to fig. 1-5. The technique of fig. 18 may be used in combination with the techniques of fig. 9 through 17.

In fig. 18, endpoint 150 stores packet 167 with hash value 169. The packet 167 may be stored in the memory device 130 with 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 packet 167 is stored in memory device 130, encryption engine 107 of memory device 130 may calculate hash value 169 of packet 167 independent of processing device 118 of host system 120 in endpoint 150. When the packet 167 is stored outside of the memory device 130, the hash value 169 may be obtained by the processing device 118 of the host system 120 executing a routine that is stored in the memory device 130 and that has verified that it has not changed (e.g., as in fig. 4).

In general, packet 167 can include instructions and/or data, e.g., can be the same resource for a set of endpoints (e.g., 150), can be different configuration parameters for different endpoints (e.g., 150).

Hash value 169 of packet 167 indicates the health of packet 167.

In fig. 18, the secret key 137 used to generate the authentication 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 packet 167 by the security server 140, a hash value 169 is provided as part of the message 131 in the identity data 113.

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 packet 167 in endpoint 150 has changed and/or whether packet 167 is outdated.

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 restoration of package 167 in endpoint 150. If the hash value 169 extracted from the identity data 113 is different from the hash value of the healthy and up-to-date copy, the security server 140 may initiate an update in a manner similar to the update 377 of the firmware 363 of the endpoint 150 discussed in connection with fig. 14-17.

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 are not applicable to other endpoints in platform 361, a healthy copy of package 167 may be uploaded to a server (e.g., secure server 140, firmware store 170, or another server) immediately upon successful configuration of package 167 in endpoint 150.

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

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

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

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

In fig. 18, the identity data 113 contains not only the current hash value 169 of the package 167, but also activity information 177 identifying some aspect of the context in which the 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, a routine).

For example, activity information 177 may include a current location of endpoint 150 in which identity data 113 was generated.

For example, the activity information 177 may contain a date and time of generation of the identity data 113.

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

For example, the activity information 177 may include one or more attributes of the requested service, such as a category of service, an identification of another party to whom the service relates, a quantity or amount to which the service relates, and so forth.

For example, when submitting identity data 113 for a communication connection, the attributes may include an identification of the connection type, an indication of the connection, and so forth.

For example, when submitting the identity data 113 for payment, the attributes may include identification of the purchase category, the payee, the payment amount, and the like.

The activity information 177 may be used by the security server 140 to detect fraudulent activity, unauthorized use of the endpoint, and to enforce activity restrictions (e.g., as specified in parental control preferences), and so forth.

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

In fig. 19, endpoint 150 stores a plurality of packages 441, 443. Some packets are stored in a memory device 130 having a security feature. Some packets may be stored outside of memory device 130.

Core package 441 stored in memory device 130 may be executed in processing device 118 of host system 120 connected to memory device 130 in endpoint 150. Package 441 controls the operation of endpoint 150 in submitting identity data 113 of endpoint 150 to security server 140 and for communicating with package store 191 to repair and/or update packages 441, 443. For example, package store 191 may contain firmware store 170 of fig. 14 and 15.

The security features of the memory device 130 ensure that the endpoint 150 runs a valid version of the packet 441 to avoid tampering and/or corruption in verifying 373 the identity of the endpoint 150 and repairing 385 the packet.

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 a backup version to at least protect the identity of authentication 373 endpoint 150 and the operation of the repair 385 and/or update 377 package.

After endpoint 150 generates identity data 113, endpoint 150 executing package 441 communicates identity data 113 to security server 140 for verification 373. For example, the identity data 113 may be generated using the technique of fig. 18.

The 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 the packages 443, 445 were corrupted based on comparing the current hash value of the health version of the respective package with the stored hash values.

Optionally, portions of message 131 may be provided using ciphertext generated by session key 263. For example, the encrypted portion of the message may include packet health information 447 and/or activity information 177. Session key 263 may be generated for sharing between memory device 130 and the secure server in the manner discussed with respect to fig. 9 and used to verify 373 the identity of endpoint 150.

In general, the identity data 113 may be transmitted from the endpoint 150 to the security server 140 directly via a communication connection or indirectly via an intermediate server (e.g., client server 141 in fig. 5, 9, or 10, firmware store 170 in fig. 14 or 15, service store 190 in fig. 15, or package store 191 in fig. 19).

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

For example, package 441 may be active in endpoint 150. But because a new version of package 441 has been published in package store 191, package 441 may be outdated. Thus, update package 441 may improve the security of the operation of endpoint 150 and the integrity of the system.

For example, the packet 443 or 445 may have changed in the endpoint 150 and thus be damaged. The health data 195 of the corresponding package 193 in the repository 191 may be compared to the package health information 447 provided in the identity data 113 to detect the change.

If a packet (e.g., 441, 443, i.e., 445) is found to be outdated or corrupted, the security server 140 may instruct the endpoint 150 and/or the packet store 191 to repair 385 or update 377 the packet.

Operations of the repair 385 or update 377 package may include the security server 140 generating the verification code 153 of the command 155 to write data into the memory device 130. When the packet contains sensitive information (e.g., configuration parameters customized for endpoint 150), the replacement packet may be provided to memory device 130 using ciphertext generated by session key 263 or another secret key.

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

For example, the secure operations of fig. 20 may be implemented using the security features of the memory devices discussed in connection with fig. 1-5 in connection with the techniques of fig. 9, 10, 14, 15, and/or 19 and in connection with the systems of fig. 1 and/or 6.

In fig. 20, the user computer 180 may be used to access the activity tracker 451 to set preferences 455 and/or to examine tracked activity records 453 of the endpoint 150 with unique identification 111.

As in fig. 14 and 15, 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 to examine activity records 453.

The activity tracker 451 is coupled to the security server 140 to store an activity record 453 of the activity of the endpoint 150, wherein the identity data 113 of the endpoint 150 is verified by the security server 140.

Preferences 455 may include security settings for the activity of 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 forth.

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

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 preference, and/or an application running in the user computer 180, a personal media player, a mobile phone, a smart phone, etc.

For example, the preferences 455 may include user-selected selections associated with predetermined conditions specified in the preferences 455. When the activity associated with the submission of the identity data 113 is eligible, the selected selection scheme causes the security server 140 and/or the client server 141 to generate a denial of the access response 172 to the corresponding access request 171. Alternatively or in combination, the selection scheme may trigger a security alert for contacts registered in preferences 455.

Endpoint 150 may transmit an access request 171 to client server 141 to request a service. For example, the service may provide cellular communication connections, internet connections, connections to user computers 180, online storage facilities, online computing resources, and the like to endpoints 150. For example, the service may include processing of payments, transactions, messages, and the like.

The identity data 113 provided in the access request 171 may include activity information 177, as shown in fig. 18. Alternatively or in combination, the client server 141 may provide similar or separate activity information in the authentication request 173 transmitted to the security server 140. For example, client server 141 may specify access attribute 449 in authentication request 173. The access attribute 449 identifies certain aspects of the current activity of the endpoint 150 in which the identity of the endpoint 150 is to be authenticated by the security server 140. Client server 141 transmits authentication request 173 to security server 140, which authenticates identity data 113 to determine the authenticity of the identity of endpoint 150.

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

Based on activity record 453, activity tracker 451 determines whether the current activity satisfies any of the conditions specified in preference 455. If a condition in preference 455 is met, activity tracker 451 may perform a security operation to implement the selection scheme selected for the condition.

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

For example, the security operations may include instructing the security server 140 to provide an authentication response 174 indicating security restrictions, security issues, unauthorized use of the endpoint 150, and so forth.

Optionally, activity tracker 451 may identify an activity pattern of endpoint 150 based on a record 453 of past activity.

For example, a pattern may include a geographic area or region of endpoint 150 in which endpoint 150 has been operating in the past. For example, the pattern may include a period of time during a day or week that endpoint 150 was not active in the past. For example, the schema may contain a range of access attributes 449 for past activities of the endpoint 150.

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

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

For example, the date and time and/or location specified in the activity information 177 may be compared to corresponding information in the access attribute 449 to detect a mismatch. A mismatch may be an indication that stolen identity data 113 is being used or that endpoint 150 is being tampered with or otherwise unsafe to operate.

FIG. 21 illustrates a method for updating or repairing packets stored in an endpoint, according to one embodiment. For example, the method of fig. 21 may be implemented using the techniques of fig. 18 and 19.

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

For example, the server system may include a security server 140 that stores secrets of a memory device (e.g., 130) and/or other servers, such as a package store 191, a firmware store 170, and/or another server.

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

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

At block 465, the security server 140 extracts health information 447 of the packets (e.g., 167, 441, 443, i.e., 445) stored in the endpoint 150 from the authenticated identity data 113.

For example, health information 447 may contain a current hash value 169 of packet 167 stored in endpoint 150. The security server 140 may compare the current hash value 169 extracted from the identity data 113 with the hash value of the healthy, most current version of the package 167 stored in the server system (e.g., repository 191, firmware store 170).

For example, the receipt of the identity data in block 461 may be the result of endpoint 150 executing packet 167 stored in endpoint 150. Package 167 may contain at least a portion of firmware 363 or the operating system of endpoint 150. Health information 447 may be used to determine if package 167 is outdated.

In another example, the receipt of the identity data in block 461 may be the result of endpoint 150 executing a first packet 441 stored in endpoint 150. The first package 441 may include at least a portion of the firmware 363 or the operating system of the endpoint 150. The health information 447 may be used to determine whether the second packet (e.g., 443 or 445) is outdated, corrupted, or changed.

When the second wrapper (e.g., 443 or 445) contains data customized for the endpoint 150, the server system may obtain a copy of the second wrapper (e.g., 443 or 445) when the second wrapper (e.g., 443 or 445) in the endpoint 150 is successfully configured. For example, the second packet (e.g., 443 or 445) may include one or more configuration parameters of endpoint 150. In response to successfully configuring the second packet (e.g., 443 or 445), the server system may receive the healthy version of the second packet (e.g., 443 or 445) from endpoint 150. Subsequently, if the health information 447 extracted at block 465 indicates that the second packet (e.g., 443 or 445) needs to be repaired, then the health version stored in the memory store 191 may be used.

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

The identity data 113 contains a first authentication code 133. The security server 140 verifies the identity data 113 by determining whether the first verification code 133 was generated from the secret of the message 131 and the memory device 130. For example, the secret may be the unique device secret 101 and/or the secret key 137 of the memory device 130. After memory device 130 is assembled into endpoint 150, the secrets of memory device 130 are not transferred out of memory device 130.

At block 467, based at least in part on the health information 447, the security server 140 determines that the packets stored in the endpoint 150 need to be updated or repaired.

At block 469, the security server 140 initiates operations to perform updates or repairs to packets stored in the endpoint 150.

For example, to replace or repair a packet stored in the memory device 130, the secure server 140 generates the second authentication code 153 of the command 155 using an encryption key that represents the authority to execute the command 155 in the memory device 130. For example, when executed in memory device 130, command 155 causes a packet (e.g., 441 or 443) in memory device 130 to be replaced.

In some implementations, to repair the packet 445 stored outside of the memory device 130, a replacement of the packet 445 is initially stored into the memory device 130. After the memory device verifies the integrity of the replacement, packet 445 may be replaced via execution of instructions in packet 441 loaded from memory device 130. Optionally, the second verification code 153 may be generated to write the replacement into the memory device 130 and/or allow repair or replacement of the package 445 to be performed.

FIG. 22 illustrates a method of performing security operations based on one or more activities of an endpoint, according to one embodiment. For example, the method of fig. 22 may be implemented using the techniques of fig. 18 and 20.

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

For example, the server system may include a security server 140 that stores secrets of a memory device (e.g., 130) and/or other servers, such as an activity tracker 451, a package store 191, a firmware store 170, and/or another server.

At block 483, the server system receives a validation request 173 containing identity data 113 generated by a memory device 130 configured in the endpoint 150.

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.

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.

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

For example, the condition may be specified in preferences 455 of endpoint 150.

At block 489, upon providing the validation response 174 in response to the validation request 173, the server system performs a security operation associated with the condition.

For example, the security operations may include transmitting alerts or notifications to contacts registered in the one or more references 455.

For example, the security operations may include identifying security risks or restrictions in the validation response 174. Optionally, in view of the secret key 137 of the memory device 130 and the message 131 provided in the identity data 113, the security server 140 may provide a verification response 174 that does not confirm the authenticity of the endpoint 150 even when the identity data 113 has a valid verification code 133. When the activity associated with the identity data 113 satisfies the condition, the validation response 174 may be configured to cause the client server to refuse the request 171 for service to the endpoint 150 identified by the identity data 113.

The condition 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.

For example, after the security server 140 determines that the verification code 133 in the identity data 113 is valid, the security server 140 may trust that the activity information 177 embedded in the identity data 113 has not changed after the memory device 130 generated the verification code 133. Thus, activity information 177 may be extracted from identity data 113 to evaluate the condition. Optionally, the activity information 177 may be provided in the message in the form of ciphertext to be decrypted using the session key 263 generated in the manner discussed in fig. 9 or another secret encryption key of the memory device 130.

Alternatively or in combination, the security server 140 may extract the access attribute 449 from the authentication request 173. For example, after client server 141 receives access request 171 to the 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. Further, in the context of requesting services of client server 141, client server 141 may add access attribute 449 to provide information about the activity of endpoint 150.

For example, the condition may include a mismatch of the activity information 177 and the access attribute 449, and the mismatch may trigger a rejection of the access request 171 and/or a rejection of the identity data 113 in the authentication response 174, even when the identity data 113 has a valid authentication code 133.

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.

Alternatively or in combination, the server system may infer preferences 455 from records 453 of past activities.

For example, the activity tracker 451 of the server system may store a plurality of records 453 of the activity of the endpoint 150. Based on the plurality of records 453, the activity tracker 451 may determine an activity mode of the endpoint 150. The pattern may include a geographic area, a time of day or week period, or a range of activity attributes, or any combination thereof. The condition of the safe operation of trigger block 489 may be satisfied by the activity of the off mode.

Optionally, activity tracker 451 may present the activity of endpoint 150 to an owner or authorized user of endpoint 150 based on record 453. For example, based on a check of past activity, an owner or authorized user may specify conditions under which parental controls, access restrictions, etc. are to be enforced.

The identity of the endpoint 150 authenticated by the security server 140 may be dynamically associated with the subscription account represented by the account identifier to receive services provided to the account by the client server 141. When the endpoint 150 is not using a service, the association between the identity of the endpoint 150 and the subscription account may be removed to allow another endpoint to use the subscription account. Thus, a set of endpoints (e.g., 150) may be configured to share a subscription account and use the subscription accounts one at a time.

For example, a set of endpoints may be configured to make cellular connections using the services of client server 141. Traditionally, a Subscriber Identification Module (SIM) card would be used to represent a subscriber/subscription account. The group of endpoints may use the subscription account represented by the SIM card by physically installing the SIM card in one endpoint at a time in the group. To enable another endpoint in the group to use the subscription account, the SIM card will physically move from one endpoint to another.

The system as discussed above in connection with fig. 6 allows for attachment to an endpoint (e.g., 150) using a virtual subscriber identity module (vSIM) through virtual card registration 237 and based on authentication performed using secure server 140 or endpoint authentication 239. The system of fig. 6 may be further configured to disassociate an endpoint (e.g., 150) from a card profile 219 representing a subscription account, such that virtual card registration 237 may be performed for use by another endpoint with the subscription account.

For example, a subscription service (e.g., a cellular connection) provided to a subscription account may be shared among a group of endpoints owned by an enterprise (or another entity). The endpoints (e.g., 150) in this group may not simultaneously need the services of the account. Thus, it may be advantageous to configure 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 services of the subscription account simultaneously.

For example, the server system may be configured to track the current usage status of endpoints in the community. The endpoint may be dynamically bound to the subscription account when the endpoint communicates with the client server to request a service. Subscription accounts may be released from an endpoint when the endpoint is not using a service. When the number of endpoints that are using the service provided to the subscription account is greater than the number of subscription accounts that can be shared, the active endpoints may use the service of the account at the same time. When a subscription account is currently bound to and being used by a portion of the community, a request for service from another endpoint may be denied until one of the subscription accounts is not used and thus becomes available for sharing.

For example, in response to an internet of things (IoT) device of an enterprise requesting a cellular connection, a virtual subscriber identification module (vSIM) may be bound to the IoT device. The cellular connection may be disconnected when the cellular connection is idle for a period of time longer than a threshold, and a virtual subscriber identification module (vSIM) may be released from the IoT device and available for binding with another IoT device of the enterprise. Thus, an enterprise may subscribe to a reduced number of vSIMs, and when these vSIMs are all in use, requests for cellular connections from another device may be in a hold state until one of the connections is broken and the vSIM is released for allocation to the holding device.

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

In fig. 23 and 24, the service store 190 has subscription data 387 that associates the endpoint group 501 with the subscriber group 503.

The endpoint group 501 has multiple unique identities 111, 112. Each of the unique identifications (e.g., 111) represents a memory device (e.g., 130) installed in a respective endpoint (e.g., 150) in a set of endpoints.

Subscriber group 503 has one or more subscriber identity numbers (e.g., 505). Each subscriber identity number (e.g., 505) in subscriber group 503 represents a subscriber to the services of client server 141. For example, each subscriber identity number (e.g., 505) may be used to identify a unique subscription account for use by one subscriber at a time.

For example, subscriber identity number 505 may be used to represent a unique subscriber in the same manner as Subscriber Identification Module (SIM) represents a subscriber in a cellular communication network.

When the SIM card is inserted in the cellular telephone, communication with the subscriber is connected to the cellular telephone and the cellular telephone has services in the subscriber's account. When the SIM card is inserted into the alternate cell phone, the communication with the subscriber is connected to the alternate cell phone that currently has the SIM card.

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 with unique identification 111. When the subscriber identity number 505 is associated with the alternative unique identification 112, the service provided to the subscriber account represented by the subscriber identity number 505 is provided to the alternative endpoint with the unique identification 112.

In fig. 23, 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.

For example, in response to the authentication request 173 from the client server 141 with the identity data 113, the security server 140 may determine whether the identity data 113 has a valid authentication code 133 for the memory device 130 with the unique identification 111. If the identity data 113 is valid, the security server 140 may determine whether the subscriber group 503 currently has a subscriber identity number 505 that is free for use by the memory device 130 and/or endpoint 150 having the unique identification 111. If so, the security server 140 may provide a verification response 174 confirming the authenticity of the identity data 113 and its association with the subscriber identity number 505. In response, client server 141 may provide services to endpoint 150 that are provided to an account identified by subscriber identity number 505.

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

The verification request 173 in fig. 23 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 (e.g., 505) available for use by the endpoint 150 having the unique identification 111.

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 identifying the authentication response 174 of the unique identification 111 and/or the subscriber identity number 505 of the 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 so that the subscriber identity number 505 is 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 the service 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 identification 111,..112 until another authentication response 174 is received from the secure server 140 associating the subscriber identity number 505 with one of the unique identifications 111,..112 in the endpoint group 501.

When endpoints with unique identities 111,..112 compete for use of subscriber identity numbers (e.g., 505) in subscriber group 503, service store 190 may control allocation of use of subscriber identity numbers (e.g., 505) in subscriber group 503.

For example, the service store 190 may track endpoints in the group 501 that reject access requests because no subscriber identity number 505 is available and prioritize subsequent allocations of available subscriber identity numbers 505 based on the tracked priorities.

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

In some implementations, endpoints in endpoint group 501 having unique identities 111,..112 may compete for opportunities to use subscriber identity numbers (e.g., 505) in subscriber group 503 based on one or more predefined rules. For example, after receiving a denial of a service request, an endpoint (e.g., 150) may wait for a random period of time for a subsequent request to be made. With randomness of the waiting period after the rejection, opportunities to gain service access using subscriber group 503 may be assigned to endpoints requiring service.

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

In some implementations, the system can track active activities of endpoints 150 using subscriber identity numbers 505. After the inactive period, the service store 190 may remove the assignment of the subscriber identity number 505 from the unique identification 111.

Fig. 23 shows a configuration in which the assignment of the subscriber identity number 505 to the unique identification 111 is controlled by the security server 140 in combination with the authentication request 173 and/or the authentication response 174. Alternatively and/or in combination, the client server 141 may connect to the service store 190 to implement the assignments and/or use the assignments to provide services, as shown in FIG. 24.

In fig. 24, a client server 141 is coupled to a service store 190 and an activity tracker 451. Based on verification response 174 indicating the authenticity of endpoint 150 with 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 the temporary assignment of subscriber identity number 505 to unique identification 111.

Subsequently, client server 141 may use activity tracker 451 to determine whether to remove the assignment of subscriber identity number 505 from unique identification 111.

For example, after a predetermined length of inactive time period in which endpoint 150 is not using the service 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 allocation of subscriber identity number 505 to unique identification 111.

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 identification 111.

In some implementations, the client server 141 can cause the service store 190 to terminate the assignment of the subscriber identity number 505 to the unique identification 111 some period of time after the assignment of the subscriber identity number 505 to the unique identification 111. The time period may be predetermined or determined based on an access request 171 received from endpoint 150.

FIG. 25 illustrates a method for facilitating subscription sharing among a set of endpoints, according to one embodiment. For example, the method of fig. 25 may be implemented in a system having the security features discussed in connection with fig. 1-19 using the techniques discussed above in connection with fig. 23 and 24.

At block 521, the server system stores data associating the endpoint group 501 with at least one subscriber identifier (e.g., identity number 505). The endpoint group 501 may have multiple endpoints (e.g., 150) identified by unique identifications 111,..112.

For example, the server system may include a security 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 store 191, a firmware store 170, and/or another server. The server system may further include a client server 141 and/or a card server 223 shown in fig. 6.

At block 523, the server system receives a validation request 173 containing identity data 113 generated by a memory device 130 configured in the endpoint 150. The identity data 113 uses its unique identification 111 in the endpoint group 501 to identify the endpoint 150.

At block 525, in response to the authentication 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.

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.

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

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

For example, the subscriber identifier (e.g., identity number 505) represents a unique subscriber to a service provided in a network (e.g., 225) having a plurality of endpoints (e.g., 150) including a plurality of endpoints in endpoint group 501 and other endpoints not in endpoint group 501.

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

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

For example, a serving 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 numbers 505). The identity data 113 generated by the memory device 130 does not contain a subscriber identifier. The identity data 113 and/or unique identification 111 of the 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 the endpoint 150 for a serving network (e.g., 225).

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

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

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

Alternatively, in response to a message or request from endpoint 150, configuring endpoint 150 from the serving network (e.g., 225) as a subscriber identifier (e.g., identity number 505) may be performed.

Alternatively, the length of the time period after the release of the subscriber identifier (e.g., identity number 505) from the binding to endpoint 150 may be a predetermined length from the time the subscriber identifier (e.g., identity number 505) is assigned to endpoint 150.

Alternatively, the length of the time period may be specified in the authentication request 173.

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

In general, endpoints 150 may be identified using different identifications of different services, in different networks, and/or in different contexts. Each identification of an endpoint 150 may be used to represent the endpoint 150 as a member, subscriber, account, authorized device, and/or entity of many of a group that is specific to a certain type of service, connection, communication, etc.

For example, endpoint 150 may be configured to communicate with different client servers 141, 143, respectively for its services. Endpoint 150 may utilize different client server 141,..143 identities using different subscriber identities. Each subscriber identification of endpoints 150 represents a unique subscriber and/or account identified by the respective client server (e.g., 141,..143) for its service to the subscriber group.

For example, endpoint 150 may be configured to communicate with client server 141 to obtain different types of services. Different identifications of endpoints 150 may be used to represent endpoints 150 as subscribers of different service types.

For example, endpoint 150 may be assigned an integrated circuit card identifier 251 to function as a smart card, a mobile device identity number 253 to function as a cellular communication device, a mobile subscriber identity number 255 to function as a subscriber to a cellular connection service, and so on.

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

For example, a third party may request that the security server 140 bind subscription services in an account to a public identity of the endpoint 150. Since the identification is known to the public, there is a potential risk of fraudulent use of public identification. The identity data 113 of the endpoint 150 may be configured to include public identification. Based on the Unique Device Secret (UDS) 101 of the memory device 130 configured in the endpoint 150, the security server 140 can verify that the identity data 113 received from the endpoint 150 is authentic, and thus, the endpoint 150 has an identity represented by the public identity contained in the identity data 113. Fraudulent use of public identification as an identity may be detected by authentication performed by the security server 140.

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

For example, in response to a request to bind a public identity to endpoint 150, security server 140 may verify that the public identity is not currently bound to another endpoint and may operate memory device 130 using an encryption key generation command that represents owner rights, storing the public identity in memory device 130 as part of device information 121 used to generate identity data 113 for memory device 130 and/or endpoint 150.

Alternatively, the security server 140 may store data in the application domain that associates the endpoint 150 with the public identity of the endpoint 150. In response to the authentication request 173 in the application domain, the security server 140 authenticates the identity data 113 provided in the endpoint 150 and looks up the public identity of the endpoint 150 in the application domain. Public identification may be provided in the validation response 174.

Public identification and secure, dynamic binding of endpoints 150 may be used to facilitate secure operations. For example, when endpoint 150 is lost/stolen, the owner of endpoint 150 may request that security server 140 bind the public identity of the lost/stolen endpoint 150 to the replacement endpoint. Once the security server 140 binds the public identity of the lost/stolen endpoint 150 to the replacement endpoint, the services subscribed to the lost/stolen endpoint 150 are transferred to the replacement endpoint. Optionally, the owner of the lost/stolen endpoint 150 may request that data be transferred from the lost/stolen endpoint 150 to the replacement device, and after the transfer, the owner may request that the lost/stolen endpoint 150 be disabled to minimize the loss/impact of the endpoint 150.

For example, the technique of FIG. 26 may be used in the systems of FIGS. 1 and/or 6 using the security features of the memory devices discussed in connection with FIGS. 1-5 and 9-10. For example, the technique of fig. 26 may be used with the services of the firmware store of fig. 14 and 15, the service store 190 of fig. 15, 23, and 24, and/or the activity tracker 451 of fig. 20.

In fig. 26, the secure server 140 stores the unique identification 111 of the memory device 130 and its unique device secret 101. In addition, the security server 140 stores device information 121 that characterizes hardware, software, and/or data configurations of the endpoint 150 in which the memory device 130 is installed. As in fig. 2, the secret key 137 is based on the unique device secret 101 and the device information 121. The secret key 137 is used by the memory device 130 to generate the verification code 133 of the identity data 113, and the security server 140 verifies that the verification code 133 was generated using the secret key 137, which indicates that the identity data 113 was generated by the memory device 130 with the unique device secret 101.

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

For example, the application domain may be configured for cellular connectivity, smart card processing, services of the client server 141, and so on. The identification 541 may be used to represent an 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.

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

After verification of the identity data 113, the security server 140 may add 541 the public identity to the device information 121 and cause 543 the memory device 130 in the endpoint 150 to update the device information 121. After updating 543, memory device 130 has a new secret key for it to generate new identity data 113 containing public identification 541. For example, message 131 in new identity data 113 may contain public identity 541 in addition to unique identity 111. The 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 that security server 140 verify new identity data 113. If the new identity data 113 has a valid verification code 133, it is generated by the endpoint 150 assigned the public identity 541.

The security server 140 may update 543 the device information 121 in a manner similar to the update 377 of the firmware of the endpoint 150 and/or the repair 385 of the packet installed in the endpoint 150. For example, the security server 140 may generate the verification code 153 of the command 155 to store the public identification 541 in the memory unit 103 of the memory device 130. An authentication code 153 is generated using an encryption key 145 that represents the owner rights to operate the memory device 130, including rights controlled by the access controller 109 of the memory device 130 to execute the command 155 in the memory device 130.

Optionally, the association of public identity 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 for generating verification code 133 signed using secret key 137. The verification of the verification code 133 indicates that the public identity 541 provided in the message 131 has not changed and that the verification code 133 is signed by the memory device 130 installed in the endpoint 150.

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

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

In one embodiment, endpoint 150 has packets stored in memory device 130. Endpoint 150 may communicate with server 140 to obtain update 543 when a packet is loaded from memory device 130 and executed in host system 120. 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 may not be through any intermediate server.

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

For example, a service provider may assign a subscriber identity number (e.g., 255) to a subscriber of a service provided by the provider. When an owner or user of endpoint 150 registers for a service of the provider, the service provider may request that subscriber identity number 255 be bound to endpoint 150 using computer 180.

FIG. 27 illustrates a method for managing identification of endpoints, according to one embodiment. For example, the method of fig. 27 may be implemented in a system having the security features discussed in connection with fig. 1-19 using the techniques discussed above in connection with fig. 26.

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

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

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

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

In one embodiment, the right to attach such second identification 541 to endpoint 150 is an entity associated with operating the computer and having ownership of memory device 130 (e.g., as a manufacturer, retailer, service provider, end user of endpoint 150).

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. The current identity data 113 includes the first identification 111 and may be verified by the server system as to whether the current identity data 113 from the memory device 130 is authentic.

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

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

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

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

Optionally, the second identification 541 does not alter the generation of the secret key 137. But the second identification 541 is stored into the access controlled area of the memory device 130 and is included in the message 131 presented in the identity data 113 (e.g., as part of data C127).

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

For example, the memory device stores an executable set of instructions in endpoint 150. The set of instructions may be part of content 161 or 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. Since the set of instructions is protected via the memory device 130, the server system may reliably communicate with the endpoint 150 executing the set of instructions to cause the memory device 130 to execute the command 155. The communication path between endpoint 150 and the server system may optionally be protected by client server 141 and/or optionally via session key 263 and symmetric encryption.

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

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

In some embodiments, message 131 presented in identity data 113 does not contain second identification 541.

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

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.

At block 569, the server system provides an authentication response 174 to the authentication request 173 in response to determining that the identity data 113 is valid. The validation response 174 is configured to indicate that the identity data 113 was generated by the endpoint 150 having the second identification 541.

For example, the server system may identify the second identification 541 in the validation response 174 by looking up the second identification 541 associated with the first identification in the 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 contained in the identity data 113.

FIG. 28 illustrates an example machine of computer system 600, 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., execute instructions to perform operations corresponding to the security features of security server 140 and/or memory device 130 described with reference to fig. 1-27). In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, and/or the Internet. The machine may operate as a server or client machine in a client-server network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or client machine in a cloud computing infrastructure or environment.

The machine may be a Personal Computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. In addition, while a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

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).

The processing device 602 represents one or more general-purpose processing devices, such as a microprocessor, 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 implementing other instruction sets, or a processor implementing 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. Computer system 600 may further include a network interface device 608 that communicates via a network 620.

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 thereof by the computer system 600, the main memory 604 and the processing device 602 also constituting 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.

In one embodiment, instructions 626 include instructions implementing functionality corresponding to security manager 160 (e.g., the operation of security server 140 and/or security features of memory device 130 described with reference to fig. 1-27). While the machine-readable storage medium 624 is shown in an example embodiment to be a single medium, the term "machine-readable storage medium" should be taken to include a single medium or multiple media storing one or more sets of instructions. The term "machine-readable storage medium" shall also be taken to include any medium that is capable of storing or encoding a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure. The term "machine-readable storage medium" shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media.

In general, endpoints 150, servers (e.g., security server 140, client servers 141 or 143, or card server 223) may be computing systems having host system 120 and a memory subsystem. The memory subsystem may 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 of these.

The memory subsystem may be a memory device, a memory module, or a mixture of memory devices and memory modules. 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 Inline Memory Modules (DIMMs), small outline DIMMs (SO-DIMMs), and various types of non-volatile dual inline memory modules (NVDIMMs).

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, an unmanned aerial vehicle, a train, an automobile, or other conveyance), an internet of things (IoT) enabled device, an embedded computer (e.g., an embedded computer included in a vehicle, an industrial appliance, or a networked business device), or such computing device that includes memory and a processing device.

The host system 120 of the computing system is coupled to one or more memory subsystems. As used herein, "coupled to" or "and" coupled with "generally refers to a connection between components, which may be an indirect communication connection or a direct communication connection (e.g., without intermediate components), whether wired or wireless, including electrical, optical, magnetic, etc. connections.

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., NVDIMM controller), and a storage protocol controller (e.g., PCIe controller, SATA controller). The host system 120 uses the memory subsystem, for example, to write data to and read data from the memory subsystem.

Host system 120 may be coupled to a memory subsystem via a physical host interface. Examples of physical host interfaces include, but are not limited to, serial Advanced Technology Attachment (SATA) interfaces, peripheral component interconnect express (PCIe) interfaces, universal Serial Bus (USB) interfaces, fibre channel, serial Attached SCSI (SAS) interfaces, double Data Rate (DDR) memory bus interfaces, small Computer System Interfaces (SCSI), dual Inline Memory Module (DIMM) interfaces (e.g., dual Data Rate (DDR) supporting DIMM socket interfaces), open NAND Flash Interfaces (ONFI), double Data Rate (DDR) interfaces, low Power Double Data Rate (LPDDR) interfaces, or any other interface. A physical host interface may be used to transfer data between host system 120 and the memory subsystem. The host system 120 may further utilize an NVM quick (NVMe) interface to access components (e.g., the memory device 130) when the memory subsystem is coupled with the host system 120 through a PCIe interface. The physical host interface may provide an interface for passing control, address, data, and other signals between the memory subsystem and the host system 120. In general, host system 120 may access one or more memory subsystems via the same communication connection, multiple separate communication connections, and/or a combination of communication connections.

The processing device 118 of the host system 120 may be, for example, a microprocessor, a Central Processing Unit (CPU), a processing core of a processor, an execution unit, or the like. In some cases, the controller 116 may be referred to as a memory controller, a memory management unit, and/or an initiator. In one example, the controller 116 controls communication over a bus coupled between the host system 120 and the memory subsystem. In general, the controller 116 may send commands or requests to the memory subsystem that desire access to the memory device 130. The controller 116 may further include interface circuitry for communicating with the memory subsystem. The interface circuitry may translate the response received from the memory subsystem into information for the host system 120.

The controller 116 of the host system 120 may 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 within the same package as the processing device 118. In other cases, the controller 116 is separate from the packaging of the processing device 118. The controller 116 and/or the processing device 118 may include hardware, such as one or more Integrated Circuits (ICs) and/or discrete components, a buffer memory, a cache memory, or a combination thereof. The controller 116 and/or the processing device 118 may 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.

The 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).

Some examples of non-volatile memory components include NAND (or NOT AND) (NAND) flash memory AND write-in-place memory, such as three-dimensional cross-point ("3D cross-point") memory. The non-volatile memory cross-point array may perform bit storage based on a change in bulk resistance in combination with the stackable cross-meshed data access array. In addition, in contrast to many flash-based memories, cross-point nonvolatile memories may perform in-situ write operations, where nonvolatile memory cells may be programmed if they have been previously erased. NAND flash memory includes, for example, two-dimensional NAND (2D NAND) and three-dimensional NAND (3D NAND).

Each of 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), tri-level cells (TLC), quad-level cells (QLC), and five-level cells (PLC), may store multiple bits per cell. In some embodiments, each of memory devices 130 may include one or more arrays, such as 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 the logical units of the memory device for storing data. In some types of memory (e.g., NAND), pages may be grouped to form blocks.

Although non-volatile memory devices are described, such as 3D cross point and NAND type memories (e.g., 2D NAND, 3D NAND), memory device 130 may be based on any other type of non-volatile memory, such as Read Only Memory (ROM), phase Change Memory (PCM), self-selected memory, other chalcogenide-based memory, ferroelectric transistor random access memory (FeTRAM), ferroelectric random access memory (FeRAM), magnetic Random Access Memory (MRAM), spin Transfer Torque (STT) -MRAM, conductive Bridging RAM (CBRAM), resistive Random Access Memory (RRAM), oxide-based RRAM (OxRAM), or non-NOR) flash memory, and Electrically Erasable Programmable Read Only Memory (EEPROM).

The memory subsystem controller may communicate with the memory device 130 to perform operations such as reading data, writing data, or erasing data at the memory device 130, and other such operations (e.g., in response to commands scheduled by the controller 116 on a command bus). The memory subsystem controller may include hardware such as one or more Integrated Circuits (ICs) and/or discrete components, buffer memory, or a combination thereof. The hardware may include digital circuitry with dedicated (e.g., hard-coded) logic to perform the operations described herein. The memory subsystem controller may 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.

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 embedded memory configured to store instructions for performing 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.

In some embodiments, the local memory may include memory registers that store memory pointers, extracted data, and the like. The local memory may also include Read Only Memory (ROM) for storing microcode. While some memory subsystems have a memory subsystem controller, other memory subsystems do not include a memory subsystem controller, but may rely on external control (e.g., provided by an external host or by a processor or controller separate from the memory subsystem).

In general, the memory subsystem controller may receive commands or operations from the host system 120 and may translate 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 translation 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 translate commands received from the host system into command instructions to access the memory device 130 and translate responses associated with the memory device 130 into information for the host system 120.

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 and column decoders) that may receive addresses from the memory subsystem controller and decode the addresses to access the memory device 130.

In some embodiments, memory device 130 includes a local media controller for performing operations on one or more memory units 103 of memory device 130 in conjunction with a memory subsystem controller of a memory subsystem. The local media controller may be used to implement the encryption engine 107 and/or the access controller 109. An external controller (e.g., a memory subsystem controller or a controller 116 of the host system 120) may manage the memory device 130 externally (e.g., perform media management operations on the memory device 130). In some embodiments, memory device 130 is a managed memory device that is the original 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 (MNAAND) device.

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 security manager 160. For example, the processing device 118 (e.g., a processor) of the memory subsystem controller or host system 120 may be configured to execute instructions stored in the memory device 130 for performing the operations of the security manager 160 described herein. In some embodiments, security manager 160 is implemented in an integrated circuit chip disposed in a memory subsystem. In other embodiments, the security manager 160 may be part of the firmware of the memory subsystem, the operating system of the host system 120, a device driver, or an application, or any combination thereof.

Some portions of the detailed descriptions that follow 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 means used by those skilled in the data processing arts to convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though 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, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

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 action 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 memories or registers or other such information storage systems.

The present disclosure also relates to apparatus for performing the operations herein. Such a device may be specially constructed for the required purposes, 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 in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random Access Memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.

The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the method. The structure for a variety of these systems will be presented from the following description. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the disclosure as described herein.

The present disclosure may be provided as a computer program product or software which may include a machine-readable medium having stored thereon instructions which may 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 read only memory ("ROM"), random access memory ("RAM"), magnetic disk storage media, optical storage media, flash memory components, and the like.

In this specification, for the sake of simplicity of description, various functions and operations are described as being performed by or caused by computer instructions. However, those skilled in the art will recognize that such expressions are meant to be representative of the execution of computer instructions by one or more controllers or processors, e.g., microprocessors. Alternatively or in combination, the functions and operations may be implemented using dedicated circuitry, with or without software instructions, such as with Application Specific Integrated Circuits (ASICs) or Field Programmable Gate Arrays (FPGAs). Embodiments may be implemented using hardwired circuitry without software instructions or in combination with software instructions. Thus, the techniques are not limited to any specific combination of hardware circuitry and software nor to any particular source for the instructions executed by the data processing system.

In the foregoing specification, embodiments of the disclosure have been described with reference to specific example embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the embodiments of the disclosure as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Claims

1. A method for secure operation, comprising:

storing, in a server system, data representing one or more preferences of an endpoint;

receiving in the server system from a client server a verification request containing identity data generated by a memory device configured in the endpoint;

verifying, by the server system, the identity data based at least in part on a secret of the memory device and an integrity of a package including at least a portion of content stored in the memory device, and

In response to determining that the identity data is valid,

Determining that an activity associated with the identity data satisfies a condition specified for the endpoint, and

A secure operation associated with the condition is performed while providing an authentication response in response to the authentication request.

2. The method of claim 1, wherein the security operation includes transmitting an alert or notification to contacts registered in the one or more preferences.

3. The method of claim 1, wherein the security operation includes identifying a security risk or restriction in the authentication response.

4. The method as recited in claim 1, further comprising:

In response to determining that the identity data is valid, information about the activity is extracted from the identity data, wherein the condition is determined to be satisfied based at least in part on the information about the activity extracted from the identity data.

5. The method of claim 4, wherein extracting the information about the activity includes decrypting a portion of a message provided in the identity data.

6. The method of claim 5, 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.

7. The method as recited in claim 1, further comprising:

storing, in the server system, a plurality of records of activity of the endpoint;

determining a mode of the activity of the endpoint based on the plurality of records, and

Based on the pattern, the condition is identified.

8. The method of claim 7, wherein the pattern includes a geographic area, a time of day or week, a range of activity attributes, or any combination thereof.

9. The method as recited in claim 8, further comprising:

Communicating with a user computer through the server system to receive the data representing the one or more preferences of the endpoint, and

Based on the record, the activity of the endpoint is presented by the server system.

10. The method of claim 1, wherein the authentication request is received from a client server, and the method further comprises:

one or more attributes identified by the client server for the activity are extracted from the validation request, wherein the condition is determined to be satisfied based at least in part on the one or more attributes.

11. The method as recited in claim 10, further comprising:

in response to determining that the identity data is valid, information about the activity is extracted from a message in the identity data, wherein the condition is determined to be satisfied based on a mismatch between the information about the activity and the one or more attributes.

12. The method of claim 11, wherein verifying the identity data includes determining whether a verification code provided in the identity data was generated from the message and the secret of the memory device.

13. The method of claim 12, wherein the memory device does not communicate the secret out of the memory device after fabrication of the memory device is completed in a secure facility.

14. The method as recited in claim 13, further comprising:

registering the secret during manufacture of the memory device in the security facility, and

An encryption key is generated that verifies the identity data based at least in part on the secret.

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 a boot time of the endpoint.

16. A computing system, comprising:

a memory storing an encryption key of the memory device, and

At least one processor configured via a set of instructions to:

Receiving an authentication request from a client server containing identity data generated by a memory device configured in the endpoint, and

In response to the request for verification,

Determining that the identity data is valid based at least in part on a secret of the memory device and an integrity of a packet including at least a portion of content stored in the memory device;

determining that the activity identified via the validation request satisfies a condition specified for the endpoint, and

17. The computing system of claim 16, wherein the computing system is configured to store data representing one or more preferences received from a user computer of the endpoint, the data representing the one or more preferences specifying the condition, and determine that the activity satisfies the condition based on first data embedded in the identity data by the memory device and second data provided in the authentication request by a client server, and wherein the client server is configured to receive an access request from the endpoint, submit the authentication request to the computing system, and provide a service related to the activity.

18. The computing system of claim 17, wherein the memory device has logic circuitry that implements an encryption engine and is configured to use the encryption engine to:

Generating an encryption key representative of an 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 rights 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:

In response to the request for verification,

20. The non-transitory computer storage medium of claim 19, wherein the method further comprises:

Receiving data representing one or more preferences of the endpoint from a user computer to specify the condition;

Extracting first data about said activity from said identity data, said first data being embedded in said identity data by said memory means, and

Extracting second data about the activity from the authentication request, the second data being provided in the authentication request by a client server, wherein the client server is configured to receive an access request from the endpoint and submit the authentication request to the server system, and wherein it is determined whether the condition is met based on the first data about the activity or the second data about the activity or any combination thereof.