CN115037495A - Tracking activity of an endpoint having a secure memory device during authentication for secure operations - Google Patents

Abstract

The present disclosure relates to tracking activity of endpoints with secure memory devices during authentication for secure operations. The security server is used to implement security operations based on activity data of the endpoint during authentication of the endpoint. For example, the server system stores data representing the endpoint's preferences. After receiving an authentication request containing identity data generated by a memory device configured in the endpoint, the server system may authenticate the identity data based at least in part on the 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 authentication request satisfies the conditions specified for the endpoint. If satisfied, the server system may perform a security operation associated with the condition upon providing an authentication response in response to the authentication request.

Description

Tracking activity of endpoints with secure memory devices during authentication for use in Safe operation

Related applications

This application claims the benefit of the filing date of Provisional U.S. Patent Application No. 63/105,820, filed October 26, 2020, and entitled "Virtual Subscriber Identification Module and Virtual Smart Card," wherein This application also requires Article 3, titled "Track Activities of Endpoints having Secure Memory Devices for Security Operations during Identity Validation", filed on March 3, 2021 The benefit of the filing date of provisional US Patent Application No. 63/156,238, the entire disclosure of which is hereby incorporated by reference.

This application is related to US Patent Application No. 17/005,565, filed on August 28, 2020, and entitled "Secure Memory System Programming for Host Device Verification," which claims The benefit of the filing date of: Provisional U.S. Patent Application No. 63/059,617, filed July 31, 2020; U.S. Patent Application No. 17/080,684 (Endpoint Authentication based on Boot-Time Binding of Multiple Components)"; filed April 4, 2019, titled "Using Device Identity for Generating Device Identity to Utilize Remote Server Authentication Onboarding Software on Secure Devices to Generate Device Identities for Authentication with Remote Servers" and US Patent Application Serial No. 16/374,905 published on October 8, 2020 as US Patent Application Publication No. 2020/0322134; and in 2020 U.S. Patent Application No. 17/014,203, filed September 8, 2010 and entitled "Customer-Specific Activation of Functionality in a Semiconductor Device," the entire disclosure of which is hereby Incorporated herein by reference.

technical field

At least some embodiments disclosed herein relate to authentication in general, and more particularly, but not limited to, authentication of communication endpoints with secure memory devices in a network.

Background technique

The memory subsystem may include one or more memory devices that store data. The memory devices may be, for example, non-volatile memory devices and volatile memory devices. 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 Synthesis Engine (DICE) and Robust Internet of Things (RIoT) have been developed for data computing based on cryptographic computing for computing device identification and authentication.

SUMMARY OF THE INVENTION

In one aspect, the present disclosure relates to a method comprising: storing, in a server system, data representing one or more preferences of an endpoint; receiving, in the server system, data containing data generated by a memory device configured in the endpoint. a verification request for identity data; verifying the identity data by the server system 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 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 performing a security operation associated with the condition upon providing an authentication response in response to the authentication request.

In another aspect, the present disclosure relates to a computing system comprising: a memory that stores an encryption key for a memory device; and at least one processor configured via a set of instructions to: receive a memory containing a memory configured in an endpoint a verification request for identity data generated by a device; and in response to the verification request, based at least in part on a secret of the memory device, determining that the identity data is valid; determining that the activity identified via the verification request satisfies a specification specified for the endpoint condition; and when an authentication response is provided in response to the authentication request, a security operation associated with the condition is performed.

In yet another aspect, the present disclosure relates to a non-transitory computer storage medium storing instructions that, when executed by a server system, cause the server system to perform a method, the method comprising: receiving a computer storage medium containing information configured in an endpoint by a verification request for identity data generated by a memory device; and in response to the verification request, based at least in part on a secret of the memory device, determining that the identity data is valid; determining that the activity identified via the verification request satisfies the endpoint a specified condition; and upon providing an authentication response in response to the authentication request, perform a security operation associated with the condition.

Description of drawings

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

1 illustrates an example computing system in accordance with some embodiments of the present disclosure.

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

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

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

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

6 illustrates a system and method for configuring and authenticating endpoints for card-based services, according to one embodiment.

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

Figure 8 illustrates a card profile of a virtual subscriber identity module (SIM) according to one embodiment.

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

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

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

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

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

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

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

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

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

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

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

20 illustrates a system for implementing security operations based on tracking endpoint activity, according to one embodiment.

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

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

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

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

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

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

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

Detailed ways

At least some aspects of the present disclosure relate to secure servers and memory devices with secure features. The security server is configured to provide online security services in a computer network (eg, the Internet) based on the security features of the memory device. The host system of the memory device may use the memory and/or storage functions of the memory device to store instructions and/or data for processing and to store processing results.

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 can provide data for storage in the memory subsystem, and can request data for retrieval from the memory subsystem.

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

Another portion of the data stored in the memory device may provide operands or inputs to the instructions as they are 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 the input stored in the memory device and/or other inputs.

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.

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

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

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

SIM cards are commonly used to represent subscriber identity for cellular services in telecommunication networks. When the SIM card is inserted into the cellular telephone, the cellular telephone can access cellular services provided to the subscriber's account; and when the SIM card is inserted into the alternative cellular telephone, the subscriber can use the alternative cellular telephone to access cellular services associated with the account.

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

In general, security servers may be deployed on the Internet to provide security-related services to third-party computers and servers based on security features built into memory devices. The security features are built and packaged into the memory device. The security features and security services can be used without trusting the security implementation of the computing device on which the memory device is installed. Thus, the security implementation can focus 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 can be improved without much effort from the designer and/or manufacturer of the computing device.

Security servers may provide services to verify the identity and/or authenticity of devices, detect counterfeit and/or tampered devices, track and manage device ownership, facilitate transfer of device ownership/control, facilitate computing device access to third-party servers and/or Or the configuration of services that serve the network, etc.

The security features of the memory device may be implemented within an integrated circuit (IC) package of the memory device during manufacture 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 can be non-volatile so that data can be retained in the non-volatile memory cells even if the memory device is powered off for an extended period of time (eg, days, months, or even years) . The nonvolatile memory of the memory device may be used to store instructions and data for operation of the memory unit's host system.

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

The existence of the unique device secret in the memory device can be verified by the secure server through cryptographic computations, such as generation of encryption keys, generation of message hash values using encryption functions, and generation of message ciphertext encrypted by messages using encryption keys.

Encryption computations that encrypt a message using an encryption key involve computation of the ciphertext used to represent the message. The message can be efficiently recovered from the ciphertext using the corresponding encryption key by performing predefined decryption computations. It is generally not feasible to recover a message from a ciphertext without having the corresponding encryption key for decryption. The difficulty level of recovering a message without knowledge of the corresponding encryption key used for decryption represents the security level of the encryption computation. The level of security generally depends on the encryption key length used for encryption and the algorithm used for encryption.

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

A cryptographic computation that hashes a message maps the message to a hash value that represents the message. However, a certain amount of information is lost in the hash calculation, making the message unrecoverable from the hash value. Many messages can map 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, especially when the modified version is similar to the original message.

Encryption computation for 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 having the same set of data is low. The probability level represents the strength of the encryption computation used for key generation.

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

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

The logic circuit (or local controller) of the memory device may implement the encryption engine, the identity engine and the access controller. The cryptographic engine of the memory device is configured to perform cryptographic computations (eg, hashing, encryption/decryption, key generation) within the memory device to support operations of the identity engine and the access controller. Implementation of a cryptographic engine in a memory device obviates the need to rely on an external processor to perform secure computations of the memory device, and thus improves security by preventing the transfer of secrets out of the memory device and preventing tampering and theft of cryptographic computations . Optionally, at least a portion of the cryptographic computations involved in the security features of the memory device may be implemented via storing instructions in the memory device for execution by the memory device's host system, while in the logic circuitry (or local controller) of the memory device. There is a certain level of trade-off between security level and complexity.

The encryption engine of the memory device is operable 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 a ciphertext of the message using the encryption key, and/ Or use the encryption key to recover the message from the ciphertext.

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 the memory device to execute commands to read, write, delete, modify, etc., on various portions of the non-volatile memory of the memory device. Rights can be represented by corresponding encryption keys. After receiving the entitlement command in the memory device for execution, the access controller may use the encryption engine to perform computations in determining whether the command is from a sender with an encryption key representing the entitlement. After the calculation indicates that the sender has the encryption key and therefore has the authority, the access controller allows the command to be executed in the memory device. Otherwise, the access controller may deny, 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 theft of counterfeit and/or insecure forms of the memory device device.

Generally speaking, verifying that 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, digital signature, hash-based message authentication code (HMAC), encrypted message authentication code (CMAC), and the like. CAPTCHA is generated using an encryption key and a message as input to cryptographic operations such as hashing, encryption, and/or other computations, such that generation of CAPTCHA without the encryption key and generation of CAPTCHA from a modified version of the message is generally is not feasible. Therefore, when the receiver confirms that the received verification code is valid for the received message and the encryption key, the receiver can conclude that the sender has the corresponding encryption key, and the received message is the same as the one used to generate the received encryption key. The encryption key for the message is the same.

In some embodiments, the recipient performs verification of the message verification code using the same encryption key that was used by the sender to generate the verification code. For example, the recipient generates a verification code for 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 verification code is valid for the received message; and the sender can be considered to have the encryption key. Otherwise, the received verification code is invalid for the received message; the received message has changed since the verification code was generated, or the received verification code was generated using a different encryption key, or both.

In some embodiments, the recipient performs verification of the message authentication code using the public encryption key in the key pair; and the sender uses the private encryption key in the key pair to generate the authentication code. For example, the verification code may be generated by applying a hash function to the message to generate a hash value of the message. A ciphertext of a hash value obtained by hash value encryption performed using an encryption key can be used as a verification code. The recipient of the message and the verification code performs the verification using the corresponding decryption key, which is the same as the encryption key when using symmetric encryption and the other key in the key pair when using asymmetric encryption. After recovering the hash value from the ciphertext using the decryption key, the recovered hash value can be compared to the hash value of the received message; if there is a match, then the received verification code is valid for the received message; otherwise , the received verification code is invalid for the received message. Alternatively, the recipient may use the encryption key to perform authentication without performing decryption. The recipient can use the encryption key to generate a verification code for the message to compare with the received verification code.

In some embodiments, the message and encryption key are combined to generate a hash value as an authentication code, as in the technique of hash-based message authentication code (HMAC). For example, an encryption key can be used to generate two keys. After combining one of the two keys with the message to generate a key-modified message, a cryptographic hash function can be applied to the key-modified message to generate a hash value that is further combined with the other A key is combined to generate another message. After applying a 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 for the received message to compare with the received hash-based message authentication code. If there is a match, validation succeeds; otherwise, validation fails.

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

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

The memory device may be configured to store an associated encryption key for verifying a verification code signed using an encryption key configured to represent authority to request the memory device to execute a 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, and/or read data from sections of the memory device that are not readable by other users of the memory device.

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

When the memory device receives a command that requires access rights to execute, the access controller can retrieve the corresponding encryption key to verify the verification code or digital signature of the message containing the command. If the verification of the verification code received for the received command is successful, the received command is considered to be from a sender with an encryption key representing authority to execute the command in the memory device. In response, the access controller allows execution of the command in the memory device. Otherwise, the access controller blocks execution of the command.

The memory device may be manufactured to be originally owned by the secure server. The secure server may then provide and/or transfer some or all of the rights to one or more owners and users in the process from the memory device assembled to the computing device to the computing device having the memory device used by the end user. Access controllers prevent tampering, theft, and unauthorized access, while providing flexibility to support different modes of transfer of rights for different owners and users, such as manufacturers of memory-installed component computing devices, installed component computing Computing device manufacturers, retailers, business users, end users and alternative end users of devices, etc.

The identity engine of the memory device is configured to generate data indicative of the identity of the memory device and/or the identity of the computing device on which the memory device is installed. To generate the identity data, the identity engine uses the encryption engine to generate secret encryption keys from unique device secrets and other data stored in and/or collected by the memory device (eg, during the startup process of the computing device). The presence of the secret encryption key in the memory device may be considered evidence that the memory device possesses the unique device secret and other data used to generate the secret encryption key. The existence of the secret encryption key in the memory device can be verified by the secure server via a verification code or digital signature signed with 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 is securely shared without exposure. The secure server is then configured to derive the same secret encryption key (and/or the corresponding public key when using asymmetric encryption) independently of the memory device, without requiring the memory device to secretly transmit its unique device outside the memory device. Thus, the security server can verify that the memory device has a unique device secret by verifying that the memory device has the secret encryption key; and the secret encryption key that is the identity of the memory device can be integrated into a component, device, system and in the manufacturer, Changes in the processing of transfers among retailers, distributors, companies and/or end users. Without changing the unique device secret, the memory device entity represented by the secret encryption key can be updated to indicate that the memory device is assembled into a component, device, system, customized and/or personalized and/or owned by a different entity or user and/or operations.

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

For example, the identity data presented by the memory device for verification may include a message showing the public identification of the memory device. Common identification can be used to distinguish memory devices from other memory devices. Identity data may contain verification codes or digital signatures of messages in the identity data signed using a secret encryption key. Identity data includes a copy of the message and a verification code or digital signature. Once the verification code and message data are verified by the security server, the security server can conclude that the public identification provided in the identity data is authentic and that the identity data came from a memory device with a secret encryption key.

The memory device's secret encryption key may be generated using not only the memory device's unique device secret, but also additional data representing some aspect of the memory device and/or the computing device on which the memory device is installed. The additional data may represent software, firmware, bootloaders, application programs, trace data stored in a memory device, identifiers of computing device components in the computing device at the most recent boot time of the computing device. If the additional data has been altered, the identity engine generates an altered secret encryption key. Therefore, the verification code generated using the changed 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 composition of the memory device and the computing device on which the memory device is installed.

Verification of the identity of the memory device and/or its host system can detect counterfeit, tampered, and stolen/lost devices. Based on a request from the owner, the security server may configure the stolen/lost device to operate in one of several degraded modes, such as unbootable, unreadable, encrypt/erase data in non-volatile memory, memory device's Self-destruction of memory/storage functions, etc.

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

The secure server may store an encryption key representing the owner's rights of the memory device. Using the encryption key, the secure server can generate commands that transfer ownership of the memory device and configure and/or transfer selected rights such that selected commands are executed in the memory device. After reporting a lost/stolen computing device, the secure server can detect the use of its memory device during memory device authentication, as well as requests for services by third-party servers.

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 the secure server for verification. If the identity data is verified by the secure server, the third-party server may provide the service to the computing device; otherwise, the service request may be denied, discarded, or ignored.

When requested by an authorized party, the secure server may sign the command or generate a verification code for the command to grant or revoke access to the non-volatile memory of the memory device. The command, which can be signed by an authorized party, is forwarded to the memory device for execution. The signed command contains a message with the command and a verification code for the message signed/generated using an encryption key representing the authority 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 the computing device with main memory/storage capacity. For example, instructions and associated data to be executed in a computing device may be stored in a memory device and protected from corruption, 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 for use by the computing device is at least verified in the memory device and/or or the process of verifying the identity of the computing device.

The security service provided by the security server de-secures the operation and computing device from the third-party server. Services using memory devices and secure servers can prevent unauthorized access without significant effort by the computing device manufacturer and the operator of the third-party server. Thus, third-party servers can operate using their core capabilities to provide their respective services without compromising security.

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

A 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. The security features of the memory device configured in the computing device can be used to generate the device identity. When the computing device connects to the third-party server to obtain the service, the third-party server requests the security server to verify the identity of the device. Based on the ownership of the computing device and the ownership of the account, the computing device can be dynamically linked to the account, enabling the computing device to use the account to access services provided by third parties without 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 through the secure server's ownership management service. Once the owner/subscriber is identified, the subscriber identification can be built into the device identity of the computing device, or associated with the device identity in the secure server's database. Subsequently, when verifying the identity of the device, the services in the subscriber's account can be provided to the computing device by the third party without requiring the subscriber to explicitly direct/request the service to the computing device.

Optionally, the computing device can establish a separate certificate with the third-party server so that each time the computing device connects to the third-party server to obtain a service, the third-party server does not need to contact the security server.

1 illustrates an example computing system in accordance with some embodiments of the present disclosure.

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

The secure memory device 130 may store the unique device secret 101 for its authentication. In one example, the unique device secret 101 is injected into the memory device 130 in the secure 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 secure facility may be part of a manufacturing facility for the memory device (eg, 130). The unique device secret 101 in the memory device 130 is not accessible via any interface of the memory device 130 (eg, the host interface 147 ) after the memory device 130 is made and/or left secure. Thus, after fabrication of the memory device 130 , the unique device secret 101 as in the memory device 130 is sealed in the integrated circuit package of the memory device 130 . A copy of the unique device secret 101 is protected against theft and unauthorized access within the secure server 140 using strong security measures (eg, using a hardware security module (HSM)).

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

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

For example, encryption key 105 may contain two pairs of asymmetric encryption keys. The first pair of asymmetric keys are called device identification keys; and the second pair of asymmetric keys are called alias keys. 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 can be used for more transactions/communications; and the alias key can be replaced more frequently than the device identification key for increased security, since the alias key is used more frequently and therefore is risky. For example, the private device identification key may be generated at boot time and used to sign a certificate, such as an alias public key certificate; the private device identification key is then immediately deleted 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 can 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 evidence that the memory device 130 has the unique device secret 101 and stores an untampered version of the non-secret data.

Using the encryption engine 107 , the memory device 130 can prove that the memory device 130 has the secret encryption key 105 without transferring the secret encryption key 105 and/or the unique device secret 101 outside the memory device 130 . For example, memory device 130 may digitally sign a certificate or message using secret encryption key 105 to provide a verification code and secret encryption key 105 for the message. When the security server 140 validates the verification code successfully, the security server 140 can conclude that the memory device 130 has the secret encryption key 105 and therefore the identity represented by the unique device secret 101 .

Memory device 130 includes a host interface 147 that may 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 to read data from the memory unit 103, write data into the memory unit 103, erase data from a portion of the memory unit 103, modify a portion of the memory unit 103 data, activate security features of memory device 130, configure parameters related to security features in memory device 130, and the like. At least some of the commands require permissions represented by encryption keys 106 stored in secure server 140 . Having the encryption key 106 available to sign the command is considered to indicate authority 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 an encryption key 106 representing the authority associated with the command. If the command is received with a valid verification code, the access controller 109 allows the memory device 130 to execute the command; otherwise, the command may be rejected, ignored, or discarded.

When the memory device 130 is manufactured, one or more associated encryption keys 105 are stored in the memory device 130 to provide the security server 140 with owner rights. Using owner rights, secure server 140 may sign commands for execution in memory device 130 to activate or deactivate security features, trigger replacement of a secret encryption key that is the identity of memory device 130, replace for access controller 109 An encryption key for verifying authority to execute one or more commands in memory device 130 for one or more regions of memory unit 103, and so on.

Optionally, after authenticating the identity of the authorized requestor, the security server 140 may sign the command using an encryption key to generate a verification code or digital signature for the command, which the requestor may send to the host interface 147 of the memory device 130 The command with the verification code enables the command to be executed within the memory device 130 .

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

Typically, memory device 130 is connected to host system 120 to form endpoint 150 in communication network 110, such as the Internet. Generally speaking, 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 functions 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.

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

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 services to authenticate the identity of memory device 130, security server 140 may also provide security services to manage operating memory device 130, configure or change security features or settings of memory device 130, detect lost/stolen devices, deactivate lost/stolen devices Permissions for stolen devices, etc.

Memory device 130 and/or endpoint 150 may have a non-secret unique identification 111 . Unique identification 111 may be used to uniquely identify memory device 130 and/or endpoint 150 within a group of memory devices and/or endpoints.

For example, the unique identification 111 of the memory device 130 may include the manufacturer part number (MPN) of the memory device 130 and/or the serial number of the memory device 130 . For example, the unique identification 111 of the memory device 130 may comprise a public key of a pair of asymmetric encryption keys secretly generated based at least in part on the unique device.

To authenticate the memory device 130 and/or the endpoint 150 as having the identity represented by the unique identification 111, the security server 140 verifies the data containing the unique identification 111 (and other data 127) via the verification code of the message signed using the memory device's secret encryption key 105. information. The secret encryption key 105 in the memory device 130 is generated using the unique device secret 101 in the memory device; and the corresponding encryption key 106 used to verify the verification code signed using the secret encryption key 105 of the memory device 130 is in the secure server 140 Generated from the corresponding unique device secret 101 .

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

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

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

Figure 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 , the encryption engine 107 of the memory device 130 (eg, as in FIG. 1 ) is used to generate at least a secret key 137 using its unique device secret 101 and device information 121 .

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

Alternatively, when using symmetric encryption, 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 Device Identity Synthesis Engine (DICE) and Robust Internet of Things (RIoT) methods, the first pair of asymmetric keys is referred to as device identification keys; and the second pair of asymmetric keys is referred to as alias keys . 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 where the generation or use of the private device identification key is at least partially occurs in the host system 120. Alias keys can be used to authenticate other transactions and/or communications. For example, a private device identification key can be generated at boot time and used to sign a certificate, such as an alias public key certificate, and then deleted. After verifying or confirming the identity of the memory device 130 and the authenticity of the public alias key using a certificate signed using the private device identification key as the secret key 137, the private alias key can be used as the memory device 130 in subsequent operations the secret key 137 until the endpoint 150 reboots.

For example, the data 123 of the device information 121 stored in the memory unit 103 may comprise a set of instructions (eg, software, firmware, operating system, application).

For example, data 123 may include a cryptographic hash value of the set of instructions. For example, a known hash value for the set of instructions may be stored in memory unit 103; and the current hash value for the set of instructions may be calculated for comparison to 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 for computing 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 computation of secret key 137 . If the instructions have changed (eg, due to data corruption and/or tampering or theft), verification of the secret key 137 by the security server 140 will fail.

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

Optionally, data 123 may include trace data stored into memory unit 103 during the process of building and/or customizing endpoint 150 that includes memory device 130 . For example, when memory device 130 is assembled into a component device (eg, memory subsystem), a piece of tracking data representing the manufacturer of the component device, the model number of the component device, and/or the serial number of the component device is stored in memory unit 103 as Part of Device Information 121. Subsequently, when the component device is assembled into the endpoint 150, a piece of trace data is added to the memory cell as part of the device information 121. Additional tracking data may be added to memory unit 103 as part of device information 121 to reflect the history of memory device 130 used to personalize the identity of memory device 130 .

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

For example, endpoint 150 may have host system 120 and memory device 130 . Some components in host system 120 may be removed or replaced. Upon startup of endpoint 150, a portion of the instructions stored in memory unit 103 are executed to collect data 125 about components present in host system 120 at startup time. Thus, device information 121 may represent a particular configuration of the software/data and hardware combination 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 specific configuration.

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

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

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

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 so that the information cannot be accessed by third parties.

The message 131 may be a certificate presenting the memory device 130 and/or the unique identification 111 of the endpoint 150 . Message 131 may further present other data 127 , such as counter values maintained in memory device 130 , cryptographic nonces, and/or other information regarding verification of identity data 113 . Memory device 130 may monotonically increase the counter value to invalidate identity data with lower counter values to prevent replay attacks.

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

In some embodiments, the secret key 137 is the private alias key of a pair of asymmetric keys. Data 127 includes a certificate presenting the corresponding public alias key of the pair of asymmetric keys. The certificate presenting the public alias key is signed using the device identification key of memory device 130 . The public alias key can be used to authenticate the verification code 133 of the message 131 and the private alias key used as the secret key 137 . Once the security server 140 verifies the certificate presenting the public alias key, signed using the device identification key of the memory device 130 and provided as part of the data 127, the security server 140 can use the public alias key to verify the use of the private alias key Verification code 133 signed as secret key 137 . In this embodiment, security server 140 can use the public alias key provided in message 131 to verify verification code 133 without having to regenerate the pair of alias keys; and memory device 130 can use data not yet known to security server 140 Generate an alias key pair 135.

The certificate presenting the public alias key can be generated and verified in the manner in 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, memory device 130 initially provides security server 140 with a certificate with a public alias key. The memory device 130 may then use the private alias key as the secret key 137 and either the public alias key is not included in the message 131 , or the certificate for the public alias key is not included in the message 131 .

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

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

To improve security, memory device 130 does not use processing power outside of memory device 130 to generate copies of secret key 137 and does not transmit secret key 137 outside of memory device 130 . The generation and use of the secret key 137 is performed using logic circuitry of the encryption engine 107 sealed within the memory device 130 .

Alternatively, portions of the operations to generate and use 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 communicated across the host interface 147 in clear text; and the instructions may be configured to clear the secret key 137 from the host system 120 after generation and/or after use.

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 startup (eg, by executing a boot loader stored in memory unit 103). Data 127 may include count values maintained in memory device 130 . When the operation of generating the identity data 113 is performed, the count value is incremented. Thus, a certain version of identity data 113 having a certain count value invalidates a previous version of identity data 113 having a count value lower than said count value.

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

3, when controller 116 of host system 120 sends command 155 to host interface 147 of memory device 130, access controller 109 determines whether the sender of command 155 has authority to request memory device 130 to execute command 155.

The encryption key 145 is configured to represent authority. The sender of the command 155 may generate the verification code 153 from the encryption key 145 and the message 151 containing the command 155 .

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

The access controller 109 uses the corresponding access control key 149 to verify the verification code 153 of the command 155 submitted to the host interface 147 . The access controller 109 uses the encryption engine 107 to generate a verification result 159 of the received message 151 and 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 the 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 permissions for executing different commands and/or for executing commands that act on different sections of memory unit 103 .

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

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

Optionally, encryption key 145 is generated during verification of identity data 113 generated using secret key 137; and a known secret (eg, secret key 137) between memory device 130 and secure server 140 allows the session The key is generated as an encryption key 145 to represent the authority to execute selected commands in the memory device 130 during a time-limited communication session. Optionally, the period of time the device is powered on can be used as a session delimiter, so that a new count value is generated during the next power cycle, enabling new session keys to be generated.

The encryption key 145 may be configured to be valid for a short time after the identity data 113 is authenticated and the session key is established. 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 a verification code 153 and provide the verification code 153 to the entity. The entity may then send the message 151 and the verification code 153 to the host interface 147 . Once the access controller 109 of the memory device 130 determines that the verification code 153 is valid using the encryption engine 107 and the access control key 149, the verification result 159 permits the memory device 130 to execute the received command 155; otherwise, the access controller 109 may deny or ignore 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 the encryption key 145 representing the authority to execute the command 155 in the memory device 130 .

The message 151 may contain data 157 representing the restrictions on the request to execute the command 155 .

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

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

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

For example, data 157 may include an identification of the memory region in which execution of command 155 is permitted.

For example, data 157 may include the types of operations that allow command 155 to be executed in memory device 130 .

4 illustrates a technique for verifying the integrity of data stored in a memory device, according to one embodiment. For example, the techniques of FIG. 4 may be used with the memory device 130 of FIG. 1 and used in conjunction with the techniques of FIGS. 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 status 165 of the content 161, the encryption engine 107 applies a cryptographic hash function to the content 161 to generate a current hash value for the content 161; and the encryption engine 107 compares the current hash value to the stored hash value 163 to determine Are they the same. If the same, then 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 used to generate the 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 . Access controller 109 provides and/or enforces various levels of permissions to access content 161 and hash value 163 .

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

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

Unique device secret 101 may be protected in memory device 130 with the highest level of security. For example, the unique device secret 101 is not available via commands 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 a manufacturing operation of the memory device 130 is completed. Change. Preferably, the unique device secret 101 is only accessible by the encryption engine 107 during the generation of the secret key (eg, 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 starts up.

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

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

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 FIGS. 2 , 3 and/or 4 .

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

To request a service from client server 141 , host system 120 (eg, executing instructions retrieved from memory device 130 ) requests identity data 113 of memory device 130 . For example, 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 be serviced, client server 141 extracts identity data 113 from request 171 and generates a request 173 for security server 140 to provide security services based on identity data 113 .

Security server 140 may perform verification of identity data 113 , determine the authenticity of memory device 130 and/or endpoint 150 , and provide the result to 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 came 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, altered, or tampered with, or from a lost or Stolen device.

In some implementations, the request 173 may identify the command 155 to be executed in the memory device 130 . After verifying the identity data 113 and verifying the client server 141 and/or endpoint 150 permission to request the command 155 to execute within the memory device 130 , the security server 140 may use the encryption key 145 to generate a verification code 153 for the command 155 and in response 174 The verification code 153 is provided to the client server 141. Using security services, client server 141 may be relieved from the security burden associated with the management of rights and encryption keys 145 representing rights.

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

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

For example, upon execution of command 155 in memory device 130 , access controller 109 may be configured to disable a bootloader 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 cell 103 .

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

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

For example, command 155 may cause memory device 130 to perform self-destruction, 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 memory device 130 providing identity data 113 . In some implementations, client server 141 may provide a connection that allows secure server 140 to send commands 155 to memory device 130 for execution.

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

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, identification of one or more applications running on the endpoint 150 to establish a secure connection to a service or network (eg, client server 141 or 143) Platform source code, and a unique identifier for the network interface 114 or communication device. For example, the unique identifier may be the 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 the International Mobile Equipment Identity (IMEI) number of the endpoint 150 configured to access cellular service. For example, when the 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 strong identities can be used in conjunction with cloud-based Subscriber Identity Module (SIM) functions in login, network access and registration for cloud services (eg, cellular subscription services).

The security features of the secure server 140 and memory device (eg, 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 (eg, 130). Additional network security protection of endpoints may be achieved by controlling access to content 161 stored in a memory device (eg, 130). Access control may be implemented through secure hardware manufacturing operations and password-based permission controls, as discussed above in connection with FIGS. 1-5 . A platform equipped with such a memory device (eg, 130) can achieve a sufficient level of network security protection to support cloud-based virtual SIM solutions and no longer require a physical SIM card on endpoint 150 to access cellular connections.

The secure memory device technology platform may include a combination of secure memory devices (eg, 130 ) and software that meets DICE RIoT requirements for generating identity data 113 for endpoints (eg, 150 ) initiated using the secure memory device. Such identity data 113 for endpoint 150 is generated based on the identity of the secure memory device 130 used to initiate endpoint 150 and other factors. Such identity data 113 may be passed on to client server 141 during login (eg, registering for a service). Client server 141 may communicate with security server 140 to confirm the identity of endpoint 150 . When the identity data 113 is verified, the client server 141 can trust the endpoint 150 to be authentic and register the service with the endpoint 150 accordingly.

For example, such a service could be a cellular connection that is usually registered to a physical SIM card. Identity data 113 authenticated by the secure memory device technology platform and protected by secure login may provide identification of endpoints (eg, 150 ) in a manner that is as secure or more secure as identification of endpoints using a physical SIM card. The cloud-based virtual SIM can be bound to identity data 113 that the secure memory device technology platform verifies during the service subscription life cycle.

Typically, service networks (eg, payment card networks, cellular communication networks) can identify subscribers via smart cards. Traditional smart cards are configured as integrated circuit chips embedded in plastic cards. An integrated circuit chip in the smart card stores data identifying the customer's account and, optionally, data related to services provided to the account by the service network. The integrated circuit chip can be read by means of metal contacts arranged 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 used to access cellular communication network services. When the SIM card is attached to the mobile phone, the cellular communication network provides services to the mobile phone according to the account identified by the SIM card. When the SIM card is attached to the replacement mobile phone, the replacement mobile phone can access the services configured for the account.

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

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

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

6 illustrates a system and method for configuring and authenticating endpoints for card-based services, according to one embodiment.

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

In FIG. 6, memory device 130 may be implemented using integrated circuit memory device 130 having the security features of FIGS. 1-5. Access controller 109 of 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 memory device 130 .

For example, the memory device 130 is initially manufactured with an access control key 213 , allowing the secure server 140 to have full access to memory areas in the memory device 130 . The memory device 130 is further fabricated to contain at least a portion of the device identity data 211 that uniquely identifies the memory device 130 within a group of memory devices.

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

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

Device identity data 211 may be a root secret that is not disclosed, changed, and provided outside of 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 of the memory device 130 (eg, the host interface 147 ). Memory device 130 may be considered a secure memory device because memory device 130 enforces a set of data access policies to prevent leakage of secrets and tampering of data stored in access protected areas of memory device 130 . Security server 140 stores information that can emulate computations performed by memory device 130 to generate a derived secret independently of memory device 130 . Thus, secure server 140 can regenerate the derived secret for memory device 130 without requiring memory device 130 to transmit the derived secret via its communication interface (eg, host interface 147).

For example, the root secret of memory device 130 may be implemented via a Physical Unclonable Function (PUF). The root secret of memory device 130 may be retrieved from memory device 130 and stored in secure server 140 for memory registration 231 during memory device 130 manufacturing. The root secret may be used to generate derived secrets from the device identity data 211 . For example, a PUF can be used to derive a Diffie-Hellman key pair; and a Diffie-Hellman key pair can be used to create a Unique Device Secret (UDS) that can be securely shared between a device and a secure server 101.

For example, device identity data 211 may be generated using the techniques of FIG. 2 .

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

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

The derived secret in the device identity data 211 may be generated and/or replaced after the memory device 130 leaves the manufacturing facility. Access control keys 213 may be used to control the performance of operations that generate and/or replace derived secrets to prevent tampering. For example, the derived secret may include encryption keys and/or certificates generated according to 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 manufacture of memory device 130, the root secret of memory device 130 is known between memory device 130 and secure server 140 during memory registration 231 in the secure environment. Subsequently, the additional information used to generate the derived secret can 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.

Access control keys 213 are configured to prevent unauthorized access and/or manipulation of secrets in device identity data 211 . For example, once the access control key 213 is configured in the memory device 130, the secret is limited for use by the encryption engine 107 (eg, to regenerate a derived secret and/or generate a digital signature). For example, commands/requests received in the host interface 147 of the memory device 130 need to be digitally signed in a manner that can be verified using the access control key 213, as shown in FIG. 3 . If the digital signature applied on the command/request is invalid according to the access control key 213, the command/request may be rejected and/or ignored.

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

Additionally, 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 restricted to accessing different areas of the memory device for certain operations (eg, writing, erasing, reading). Owners and other authorized users may have different scopes and/or permissions to operate memory device 130 .

Security server 140 may be configured as the initial owner of memory device 130 . For example, the public key of secure server 140 may be initially stored in memory device 130 as owner access control key 213 to provide owner rights for commands signed using secure server 140's private key. 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 owner rights to the client.

Optionally, certain security features of memory device 130 may be customer activated. Some aspects of memory device 130 related to activation of security functions can be found in US Patent Application No. 17/014,203, filed September 8, 2020, and entitled "Customer-Specific Activation of Functions in Semiconductor Devices," the application's The entire disclosure is hereby incorporated herein 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 modules 217 and trace data 215 may be stored into memory device 130.

For example, soft module 217 may include a boot loader for endpoint 150 , the firmware of memory device 130 and/or a memory subsystem containing memory device 130 , or an operating system or software application for endpoint 150 . Soft modules 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 memory subsystem.

During endpoint construction 233 , endpoint registration 235 may be performed to store tracking data 215 into secure 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, trace data 215 may include a hash value of soft module 217 computed using a cryptographic hash function. For example, tracking data 215 may contain secrets assigned to endpoints 150 .

The counterfeit of endpoint 150 does not have tracking data 215, and it cannot pass endpoint authentication 239 that relies on tracking data 215. Therefore, the security of the system is improved. Additional details and examples of techniques related to tracking data 215 can be found in US Patent Application Serial No. 17/005,565, filed August 28, 2020, and entitled "Secure Memory System Programming for Host Device Authentication," the application's The entire disclosure is hereby incorporated herein by reference.

Endpoint identity data 188 may be generated using the techniques of FIG. 2 to represent the configuration of endpoint 150 at its startup time. For example, endpoint identity data 188 may include generated based on a combination of a portion of device identity data 211 , tracking data 215 , and identifying data of other components (eg, network interface 114 , processing device 118 , controller 116 ) that were present when endpoint 150 was activated certificate (eg, message 131).

The device identity data 211 and/or the endpoint identity data 188 may include one or more certificates generated using the Device Identity Composition Engine (DICE) according to standards developed by the Trusted Computing Group (TCG) that combine hardware secrets and source code A trusted identity is formed. Additional details and examples of techniques used to generate device identities can be found in the submission on April 4, 2019 entitled "Logon Software on Secure Devices for Generating Device Identity to Utilize Remote Server Authentication" and filed on October 8, 2020 US Patent Application No. 16/374,905, published as US Patent Application Publication No. 2020/0322134, the entire disclosure of which is hereby incorporated by reference herein.

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

For example, endpoint 150 may connect to card server 223 to request the 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. Card server 223 forwards endpoint identity data 188 to security server 140 for authentication 239 of 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 is 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 allocate 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 a protected soft module 217 in the memory device 130 and/or via a security manager so that the card profile 219 stored in the memory device 130 cannot be tampered with. Optionally, secure server 140 may generate a verification code for command 155 to write card profile 219 in the secure section of memory device 130 . The write permission 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 .

Additionally, the memory device 130 may verify the integrity of the card profile and/or 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 function 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 considered a virtual smart card.

In some embodiments, the soft module 217 is configured to use the cryptographic functions and/or processing capabilities of the logic circuitry of the integrated circuit memory device 130 to implement cryptographic operations involved in the use of the card profile 219 . For example, the card profile 219 may 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, the card profile 219 may be as shown in FIGS. 7 and 8 .

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

In FIG. 7 , the card profile 219 may contain card data 241 and a soft card module 243 . Optionally, soft card module 243 may be installed as part of soft module 217 stored in memory device 130 .

Card data 241 may include identification of smart cards (eg, virtual cards), accounts, and/or subscribers. For example, 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 (eg, balances, transaction records, messages, etc.). In some implementations, card data 241 may comprise the same set of data stored in a physical smart card (eg, an integrated circuit chip embedded in a plastic card configured according to the Universal Integrated Circuit Card (UICC) standard).

Soft card module 243 may contain instructions to operate on card data 241 through encryption engine 107 of memory device 130 . For example, the computing functions of an integrated circuit chip for a particular type of smart card may be implemented by executing the soft card module 243 via the secure memory device 130 . The soft card module 243 allows the endpoint 150 to emulate the computing operations of a physical smart card.

Figure 8 illustrates a card profile of a virtual subscriber identity module (SIM) according to one embodiment.

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 assigned to the international mobile subscriber identity number 255 257, and service data 247 relating to the mobile/cellular communication service of the International Mobile Subscriber Identity number 255.

In conventional mobile phones using conventional SIM cards, an integrated circuit card identifier (ICCI) 251 is used to identify a SIM card in a group of SIM cards. The mobile equipment identity number 253 (eg, in the form of an International Mobile Equipment Identity (IMEI) number or IMEI software version (IMEISV)) is used to identify a mobile phone within a group of mobile phones. International Mobile Subscriber Identity (IMSI) numbers are used to identify subscribers/customers/accounts among groups. Such numbers 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 can 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 equipment identity number 253 corresponds to and/or represents endpoint identity data 188 of endpoint 150; and, International Mobile Subscriber The identity number 255 represents a subscriber/customer/account in the mobile/cellular communication network.

For example, the authentication key 257 is the secret assigned to the International Mobile Subscriber Identity number 255. When an endpoint 150 requests a connection in a mobile/cellular communication network using the International Mobile Subscriber Identity Number 255, the mobile/cellular network operator can look up the authentication key 257 from the database and challenge the endpoint 150 to prove that it possesses the authentication key 257 . The security challenge may include digitally signing a message containing a random number (RAND) using the authentication key 257 . The reply to the security challenge may contain part of the digital signature for verification by the mobile/cellular network operator. The operator independently signs the message using the corresponding authentication key 257 associated with the International Mobile Subscriber Identity Number 255 in the database. If the reply matches the one calculated by the mobile/cellular network operator, then the digital signature is verified; and therefore, the endpoint 150 is considered to have the authentication key 257 assigned to the International Mobile Subscriber Identity Number 255, and is eligible to receive a communication with the International Mobile Subscriber Service associated with identity number 255. Additionally, a symmetric encryption key can be derived from the digital signature for use in securing communications between endpoint 150 and the mobile/cellular communications network in subsequent communications sessions.

For example, when the card profile 245 is installed in the endpoint 150, the endpoint 150 can communicate with the mobile/cellular network operator to request connections and respond to security challenges using the same protocols used by mobile phones with physical SIM cards. Therefore, the mobile/cellular network does not have to distinguish between endpoints 150 with card profiles 245 as virtual SIM cards and other mobile phones with physical SIM cards.

Optionally, the card profile 245 may include an authentication module 259 configured to be executed by the encryption engine of the secure memory device 130 and/or the processing device 118 of the endpoint 150 to perform encryption computations during use of the card profile 245, eg, for The communication session generates a reply to the security challenge and/or a symmetric encryption key.

In FIG. 6, after virtual card registration 237, endpoint 150 may use card profile 219 to receive services from card-based service network 225 to identify subscribers/customers/accounts. For example, a card-based service network 225 that is initially configured to provide services to conventional smart cards can seamlessly be further deployed to have virtual smart cards implemented by storing the card profile (eg, 219 ) in a secure memory device (eg, 130 ). endpoint (eg, 150) to provide the service.

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

For example, endpoint 150 may function as a smart card reader. Endpoint 150 may include metal contacts for connection to a card reader. For example, endpoint 150 may include a transceiver comparable to a reader of a wireless smart card. Alternatively, additional card readers may be configured in the card-based service network 225 to read virtual cards from endpoints 150 using alternate communication connections. Examples of alternative connections may include Near Field Communication (NFC) connections, Bluetooth connections, Wi-Fi connections, Universal Serial Bus (USB) connections, and the like.

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

Optionally, card profile 219 may be stored in card server 223 in association with endpoint identity data 188 . Endpoint 150 may use endpoint identity data 188 to access services 227 in card-based service network 225 . In response, the card-based service network 225 may communicate with the card server 223 to identify the card profile 219 based on the endpoint identity data 188 . Additionally, 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 the time of virtual card registration, and has the information provided by the tracking data 215, soft modules 217 and components The combination of 187 represents the same configuration. When endpoint 150 is tampered with and/or modified, the change may be detected in status check 229 and/or endpoint authentication 239; in response, card-based service network 225 may deny the request to access service 227.

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

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 the network operator of the card-based service network 225 .

For example, the system of Figure 6 can be used to simplify, secure, and accelerate large-scale global deployment of Internet of Things (IoT) devices and a rich ecosystem of IoT services. For example, a virtual subscriber identity module (SIM) card may be used by IoT devices (eg, endpoint 150) to connect to the Internet through a mobile/cellular communication network.

Security server 140 may serve as a memory-based security-as-a-service platform for endpoints such as IoT edge devices (eg, 150). Card servers can be used to provide cellular connectivity solutions for such endpoints. The combination shown in Figure 6 can create a common end-to-end solution for zero-touch onboarding of cellular-connected IoT devices to cloud services.

The complexity of enterprise IoT implementations creates challenges for large-scale global deployment of IoT devices. Challenges include implementation difficulties in cellular connectivity and network security. Compared to wireless local area networks (e.g., Wi-Fi), cellular connectivity offers significant advantages for IoT deployments, such as longer range, better outdoor performance, stronger security, and existing global infrastructure. Physical SIM card requirements and contracts with mobile/cellular network operators have slowed the use of cellular connectivity by IoT devices. The solution shown in Figure 6 addresses such challenges.

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

The solution shown in Figure 6 is especially beneficial for the industrial, infrastructure, automotive, aviation, transportation and logistics sectors, which require borderless long-distance connectivity for portable devices in even the most remote locations, free from borders and Limitations of close-proximity Wi-Fi networks.

A system like the one shown in Figure 6 can greatly simplify flexible global connectivity and provide rich possibilities for innovation in the IoT market.

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

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

Secure server 140 and/or 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 into endpoint 150, their functionality customized in a manner similar to the functional offerings of different types of smart cards and/or SIM cards discussed above. This customization allows businesses to access vendor-agnostic IoT services to leverage and experiment with intelligent features and data insights in new ways.

With sophisticated bad behavior and hacking on devices ranging from IoT fish tanks to baby monitors, the threat landscape has become increasingly dangerous, and cybersecurity has been a weak link in IoT adoption. Security server 140 may provide security-as-a-service supported by security features implemented in memory devices (eg, 130 ) that control access and device identity data 211 . Through its silicon root of trust, secure memory device 130 provides a unique level of protection for the lowest layers of IoT software - starting from the boot process, with strong cryptographic identity and security features native to memory device 130 .

For example, security-as-a-service implemented via a combination of security server 140 and security features embedded in a secure memory device (eg, 130 ) may include verifying that the memory device (eg, 130 ) has the The root secret recorded by the memory registry 231 verifies the authenticity of the memory device (eg, 130) that claims to have a public identification number.

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

For example, security as a service may optionally further include identifying a service provider with endpoint 150 of memory device 130 based on the identity of the owner/manufacturer of memory device 130 prior to distribution of endpoint 150 to end users/customers. Based on the service provider, the security server 140 may download soft modules 217 related to 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 can select a service provider; and the security server 140 and/or the card server 223 can push the soft module 217 to the memory device 130 . Additionally, in response to endpoint authentication 239, the security server 140 may automatically push software updates to the memory device. Thus, security vulnerabilities of on-site endpoints (eg, 150 ) can be automatically reduced and/or minimized without additional effort by individual OEMs of the endpoints (eg, 150 ).

For example, security as a service may optionally further include tracking of lost/stolen devices. In response to endpoint authentication 239 for endpoint 150 registered in security server 140 as lost or stolen, security server 140 may request access controller 109 of memory device 130 to disable access to and/or erasure from specific memory regions. remove data. In some cases, access controller 109 may disable normal operation of endpoint 150 by restricting access to resources such as bootloaders, operating systems, applications, and the like. In some cases, access controller 109 may perform operations that irreversibly destroy the memory functions of memory device 130 .

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

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

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

Endpoint identity data 188 may include a public identity of endpoint 150, such as an International Mobile Equipment Identity (IMEI) number (eg, Mobile Equipment Identity Number 253). Subscriptions by the public identity of endpoint 150 to services (eg, cellular connectivity) of card-based service network 225 may be pre-registered with the card server ( 223 ) without endpoint 150 being used. For example, the IMEI number may be associated with the International Mobile Subscriber Identity number 255 in the card server 223 database.

When endpoint 150 attempts to connect to card-based service network 225, the public identity (eg, IMEI number) of endpoint 150 is authenticated in endpoint authentication 239 using endpoint identity data 188. In response, the subscription registered to the International Mobile Subscriber Identity Number 255 is identified and used to generate the card profile 219 to bind the card profile 219 to the endpoint 150 . The binding may be in the form of storing the card profile 219 into the secure memory device 130 in the endpoint 150 . Alternatively, the binding may be in the form of an association of the card profile 219 with the endpoint identity data 188 in the database of the card server 223 .

In some cases, a group of endpoints (eg, owned by enterprise clients) may share a reduced number of virtual SIM cards for cellular connectivity. For example, an enterprise client's IoT device may not need a simultaneous cellular connection. When an enterprise client's endpoint 150 requires a cellular connection, an available card profile 219 representing a virtual SIM card is dynamically "installed" for the endpoint 150 after endpoint authentication 239 during a communication session in time for cellular service. When the communication session ends, the virtual SIM card can be used by another endpoint of the enterprise client. A physical SIM card can be moved from one mobile phone to another to allow different mobile phones to access cellular services registered to the same SIM card. However, physically moving the SIM card from one mobile phone to another is inefficient and not feasible for mass deployment. Instant installation of a virtual SIM card can overcome the limitations of a physical SIM card and provide improved security via endpoint authentication 239 prior to installing the virtual SIM card.

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

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

When such a secure memory device 130 is used with security-as-a-service provided by the security server 140 , an original equipment manufacturer (OEM) of the endpoint (eg, 150 ) can integrate the secure memory device 130 into the endpoint (eg, 150 ) by to provide security without performing its own separate security operations, such as secure key injection, designing and implementing secure elements, hardware components, or dedicated system-on-chip (SoC) features. Thus, secure server 140 and secure memory device (eg, 130 ) can provide plug-and-play security for OEMs of IoT devices (eg, endpoint 150 ).

The services of secure server 140 may be used to authenticate, activate, and manage secure memory devices (eg, 130 ) at the edge after deployment. This capability extends from the manufacturing supply chain to field installation and management for platform hardening and device protection throughout the lifecycle.

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 can be established to protect communications between secure server 140 and memory device 130 without trusting client server 141 to handle security to protect memory device 130 secrets. Optionally, session key 263 may be used by access controller 109 to implement permissions to request selected commands 155 to be executed in memory device 130 .

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

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

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

The verification code 133 is generated for the message provided in the response 273 using the secret key 137 of the memory device 130 . As discussed above, 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 (eg, re-use the response 273 and/or attempt to recover the key 137 ), a verification is generated for the message 131 containing the unique identification 111 , the counter value 265 and the cryptographic nonce 267 Code 133. 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. Therefore, a response containing a counter value 265 that is lower than the previously seen counter value may be considered invalid. The cryptographic random number 267 is used once in the generation of the response 273 and discarded by the memory device 130 . Response 273 need not explicitly contain cryptographic random number 267 in response 273 when cryptographic random number 267 has been previously provided to or generated by secure server 140 .

Client server 141 forwards response 273 to secure server 140 to request authentication of memory device 130 . Using the unique identification 111 provided in the response 273 , the security server 140 can 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 the corresponding public key when asymmetric encryption is used.

Based on verification by the verification code 133, the security server 140 provides the client server 141 with an authenticity indicator 275. Authenticity indicator 275 indicates whether memory device 130 is authentic. For example, the security server 140 may generate and provide a certificate signed by the security server 140 to extend the certificate chain of the memory device 130 back to the authenticator (eg, the security server). Optionally, secure server 140 may allow download of a certificate signing request (CSR) that allows requesters to use a certificate authority (CA) of their choice (instead of secure server 140).

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

Session key 263 may be generated based at least in part on a secret known between secure server 140 and memory device 130 but 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 . Additionally, session key 263 may be based at least in part on counter value 265 and/or cryptographic nonce 267 . Optionally, session key 263 may be based at least in part on verification code 133 . For example, the verification code 133 and the secret key 137 may be combined to generate the session key 263 .

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

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 FIGS. 3 and 10 .

For example, security server 140 may provide command 155 to client server 141 in response to request 281 from client server 141 after client server 141's request for permission to execute command 155 in memory device 130 is verified using client rights data 283 The verification code is 153.

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

After client server 141 sends request 281 to identify command 155 and memory device 130, if client server 141 is determined to have authority to control or operate memory device 130 using command 155, security server 140 may generate verification code 153 for 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 the identity data of the memory device 130 and/or the authenticity indicator 275 provided by the security server 140 .

As discussed above, verification code 153 may be implemented using techniques such as hash digests, digital signatures, and/or hash-based message authentication codes. Verification of 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 authority to execute the command 155 in the memory device 130 . For example, when encryption via asymmetric encryption is not used, encryption key 277 may be access control key 149; alternatively, when asymmetric encryption is used, access control key 149 is the public key of the key pair, while Encryption key 277 is the private key of the key pair.

In one embodiment, the access control key 149 and encryption key 277 are preconfigured for the permissions of the command 155 . In another embodiment, the access control key 149 and encryption key 277 are based on the 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 the key of a pair of asymmetric keys that can be used to implement encryption key 277 and access control key 149 involving encryption performed using asymmetric encryption.

When the verification code 153 is based on the session key 263, the verification code 153 expires when the session key 263 expires, which prevents the verification code 153 from being reused outside the session in which the session key 263 is valid.

The message 151 provided in the request 285 may contain the command 155 and the cryptographic random number 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 to transmit the identity data of the memory device 130 .

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

After client server 141 sends request 285 with verification code 153 obtained from secure server 140 , memory device 130 uses access control key 149 to verify verification code 153 of message 151 contained in request 285 . If verification code 153 is valid, access controller 109 allows memory device 130 to execute command 155 ; otherwise, access controller 109 may prevent command 155 from being executed in 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 manufacture of the computing device to which the memory device 130 was installed but not available at the time of its manufacture. For example, the new access control key 149 may be configured to provide the client server 141 with a set of permissions.

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

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

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

Figure 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 FIGS. 1-5 using the techniques of FIGS. 9 and 10 .

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

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

For example, a logic circuit or controller may contain a cryptographic engine configured to perform cryptographic computations without using a processor outside of the integrated circuit package.

At block 303, 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 an integrated circuit package.

At block 305 , the logic circuit 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, boot instructions 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 obtained by applying a cryptographic hash function to the boot instructions stored in the second memory area of the memory device 130 . Thus, device identity data 211 may lock not only the hardware of memory device 130, but also boot instructions (and/or other data, such as 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 emulate 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 representing 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 components of endpoint 150 located outside of the integrated circuit package of memory device 130 . identification data.

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

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

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

For example, when endpoint 150 requests a cellular connection to International Mobile Subscriber Identity Number 255, the mobile/cellular network operator may raise a security challenge to authenticate endpoint 150. In response, the card profile 219 may be used to generate a response to the security challenge by signing the message with the nonce using the authentication key 257 to prove that the endpoint possesses the authentication key 257 . For example, the authentication key 257 can be used to sign a message with a random number. The response to the security challenge may contain part of the digital signature used for authentication; another part of the digital signature may be used as a symmetric encryption key used to encrypt the communication session associated with the cellular connection.

12 illustrates a method for providing security services 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 using the techniques of FIGS. 9 and 10 based on the security features of memory device 130 discussed above in connection with FIGS. 1-5.

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

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

For example, the secret may be the only device secret 101 that is not transferred outside of the memory device 130 after manufacture of the memory device 130 is completed in a 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 secure facility, the secret is registered with the secure server 140 to generate an encryption key 106 that authenticates the identity data 113 based at least in part on the secret. The encryption key 106 used to verify the identity data 113 may be further generated based on data 125 received from the host system 120 during the boot time of the host system 120 of the memory device 130 . After fabrication of memory device 130 is complete in a secure facility, memory device 130 may be assembled into endpoint 150 of host system 120 having host interface 147 connected to 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 authority to execute command 155 in memory device 130 based on client authority data 283 stored in secure server 140, verification code 153 may be generated for client server 141, and based on the authority, in response Verification code 153 is provided in 174.

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

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

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

At block 329 , the client server 141 transmits the command 155 and the verification code 153 to the 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 the memory device 130, the command 155 causes the access control key 149 used by the access controller 109 to verify the verification code (eg, 153) generated using the encryption key 145 to change, the encryption key representing the Permission to execute one or more commands in memory device 130 .

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

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

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 the 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 verification of identity data 113, session key 263 may be established and known between secure server 140 and memory device 130 without the need to transmit session key 263 via the connection between secure server 140 and memory device 130. The access control key 149 used by the access controller 109 to authenticate the verification code 153 of the command 155 may be based on the session key 263 .

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

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 using the techniques of FIGS. 9 and 10 based on the security features of memory device 130 discussed above in connection with FIGS. 1-5.

At block 341 , the server system receives a request (eg, 171 and/or 173 ) associated with the service from endpoint 150 . The service is provided via a computer network (eg, 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 the security server 140 and/or the card server 223 . Optionally, the server system may further include a client server 141 in communication with the security server 140 .

For example, the services may be cellular connectivity services, payment card services, video surveillance services, cloud-based storage or computing services, and the like.

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

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

For example, during manufacture of endpoint 150 in the facility of the manufacturer of the endpoint (eg, 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. Test endpoint 150. In endpoint registration 235, the memory device 130 is configured to generate a key 137 that not only represents the memory device 130 with the unique device secret 101, but also represents the endpoint 150 with the memory device 130, which at boot time has Data 123 in memory unit 103 and data 125 from host system 120 .

When the endpoint 150 is transferred from the manufacturer to the distributor and the end user or subscriber, the data that associates the public identity of the endpoint 150 with the identity of the subscriber is stored in the server system. Ownership data can be stored in the server system without physically manipulating the endpoint 150 (eg, without opening the package that has encapsulated the endpoint 150 since the endpoint 150 was manufactured). For example, the public identification of the endpoint 150 may include a unique identification 111 of the endpoint 150 and/or data 127 identifying the make, model and serial number of the endpoint 150 known to the manufacturer of the 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 for endpoint 150 and/or subscriber data exposing subscriber accounts.

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 the subscriber identity associated with the identity data 113 in the ownership data with the subscriber identity associated with the account in the subscriber data.

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

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

In an alternative embodiment, the client rights data 283 stored in the secure server 140 indicates the 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 rights data 283. Another server (eg, client server 141 or card server 223 ) stores subscriber data to identify accounts based on the subscriber identified by security server 140 .

Using the method of FIG. 13, services subscribed to by an account can be provided/directed to endpoint 150 without having to customize endpoint 150 itself for the subscriber and/or the subscriber's account. For example, a subscriber may simply open the package enclosing the endpoint 150 during manufacture of the endpoint 150 and use the endpoint 150 to access services subscribed to by the subscriber's account without inserting a card (eg, a SIM card) to identify the subscriber or account and/or without having to communicate with the Applications or utilities running in endpoint 150 interact to identify subscribers or accounts.

For example, after the endpoint 150 is manufactured and prior to the request received in block 341, the endpoint 150 has no customization for the subscriber, nor customization for the account. Endpoint 150 is made available for use by any of a number of subscribers. In response to the request received in block 341, the endpoint 150 is automatically linked to the particular account of the subscriber obtaining the service.

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

For example, at least until the request received in block 341, endpoint 150 does not contain data stored into endpoint 150 to represent a subscriber, an account, or any combination thereof.

For example, at least prior to the request received in block 341, endpoint 150 contains no indication of a subscriber, account, or any combination thereof, and does not have ownership data for endpoint 150; and the ownership data is stored in the server system and not in 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 endpoint's 150 identity data with the subscriber account.

For example, the security server 140 may use the encryption key 145 to generate the verification code 153 for the command 155 . The server system may cause the memory device 130 to receive the command 155 and the verification code 153 . Before executing the command 155 in the memory device 130 , the access controller 109 of the memory device 130 is configured to verify the verification code 153 based on the access control key 149 . Optionally, 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 the account. For example, the additional data may be part of the device information 121 used to generate the secret key 137 when the updated identity data 113 is generated. For example, the additional data is included in the data 127 of the message 131 in the updated identity data 113 generated by the memory device 130 after the execution of the command. For example, the additional data may include a card profile 219 identifying the subscriber's account.

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

Because no operations on endpoint 150 are required to direct the services of the subscriber's account to endpoint 150, endpoint 150 can be configured as a cellular-connected capable IoT device without the need for a user for which it is customized to receive cellular-connected services interface. 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 hardware configuration that can run different firmware to provide different functionality. Additionally, 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, a firmware application may run on the base version of the firmware to add functionality, features and/or services.

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

After the endpoint 150 is assembled and shipped to end users or subscribers by installing different firmware, the endpoint 150 can be customized for different client servers 141 , . . . , 143 .

For example, an online firmware store may be configured on the communication network 110 to allow end users to purchase a certain version of firmware. Installing a selected version of firmware may or may not include installing a firmware application running with a baseline version of firmware. After the selected version of the firmware is installed, the endpoint 150 is customized to differ in at least one respect from the endpoint 150 running the previous firmware.

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

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

For example, different third-party service providers can provide software/firmware solutions for IoT devices based on a common common hardware platform. For example, firmware provided in an online store can be programmed to enable generic IoT devices to cooperate with third-party servers to provide specific types of services. Optionally, a firmware application provided in an online store can 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 the firmware and the firmware application can be considered an enhanced version of the firmware. While baseline versions of firmware for different endpoint hardware platforms provide standardized services, firmware applications can be device-agnostic and support a class of IoT devices from different vendors. Alternatively, firmware applications may be device-dependent and use different hardware capabilities from different vendors.

Security server 140 may be coupled to an online firmware store to provide firmware updates to endpoints (eg, 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 for endpoint 150 is identified, the relevant firmware application can be downloaded from an online firmware store and installed into endpoint 150 via an over-the-air (OTA) update.

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

Subsequently, when there is an update to the firmware application in the online firmware store, an outdated 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 Risk.

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

For example, a user of endpoint 150 may access an online store to subscribe to a service provider's services, change subscribed services, and/or move subscriptions from one service provider to another. Subscriptions subscribed 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 needs a firmware update for subscription services and/or to replace outdated versions of firmware. If so, the security server 140 may customize and/or update the endpoint 150 via the online store with a firmware update before the endpoint 150 receives the subscribed service from the service provider. Optionally, the security server 140 communicates with the endpoint 150 to direct the endpoint 150 to the service provider's current client server 141 . Instead, the updated firmware enables endpoint 150 to connect to the service provider's current client server 141 .

In general, secure server 140 may be connected to or include an online service store and/or an online firmware store. The server system may have a secure server 140, an online service store, and/or an online firmware store. The server system may track accounts used to subscribe to services of different service providers and track firmware customizations selected/purchased by users of endpoints (eg, 150).

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

In some embodiments, endpoint 150 initially connects to secure server 140 for 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 the endpoint 150 and determining the service provider, the security server 140 configures the firmware of the endpoint 150 for the service provider (eg, using an online firmware store) and directs the endpoint 150 to the service provider's client server (eg, using an online firmware store) , 141, ..., or 143). Thus, endpoint 150 can seamlessly provide services ordered from an online service store with minimal user effort.

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 system of FIG. 1 and/or FIG. 6 having the security services and features discussed with reference to FIGS. 1-5. The technique of FIG. 14 may be used in combination with the techniques of FIGS. 9-13.

In Figure 14, the online firmware store 170 is configured to facilitate selection of firmware and/or firmware applications for endpoint (eg, 150) customization and/or updating, as well as secure server 140 identification of the endpoint (eg, 150) verify.

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 .

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

In general, a firmware update of 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 (eg, applications 367, . . . , 369).

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

In some embodiments, firmware 363 may be customized via one or more firmware applications (eg, applications 367, . . . , 369). For example, endpoint 150 running firmware 363 may further run optional applications (eg, applications 367, . . . , or 369) to provide new functionality not present in firmware 363, disable existing functionality in firmware 363, change Or customize existing functionality in firmware 363, etc.

For example, when a firmware application (eg, application 367 ) runs on firmware 363 in endpoint 150, endpoint 150 is customized for communicating with the service provider's client server 141 to implement services or functions and/or provide services from merchants to receive services. When another firmware application (eg, application 369) runs on firmware 363 in endpoint 150, endpoint 150 is customized differently to communicate with another client server 143 of a different service provider to implement alternative or similar services or functions and/or receive alternative or similar services from said different service providers.

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

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

For example, a firmware application (eg, application 367 ) can be programmed to communicate with client server 141 to obtain services provided via client server 141 . Examples of client server 141 services include computing resources for client server 141 to process endpoint 150 data, client server 141 data storage facilities for data generated by endpoint 150, Messaging facilities for notifications and/or alerts of one or more other devices, connections via client server 141 and one or more other devices associated with endpoint 150, endpoint 150 via Wi-Fi access points, communication satellites and/or Or a communication connection controlled by the client server 141 or internet access of the device, and so on.

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

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

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

Optionally, firmware store 170 is configured to allow a user of endpoint 150 to use computer 180 to select and/or order 371 firmware for customizing endpoint 150 . In some cases, the purchase of a selected version of firmware (eg, 363 ) and/or firmware application (eg, 367 ) represents a purchase of a service from a service provider and/or client server (eg, 141 ) ask. In response, firmware store 170 and/or security server 140 may store data indicative of 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 a hardware and/or software interface accessible by a user of endpoint 150 to customize endpoint 150 for use with accounts and/or service providers. Optionally, some embodiments and/or classes of endpoint 150 may include a user interface that allows it to function as a user computer 180 to order 371 firmware for endpoint 150.

For example, the owner or user of endpoint 150 may use user computer 180 to access online firmware store 170 in order to access the online firmware store 170 by selecting a firmware application (eg, application 367 ), an alternate version of firmware, or a combination of alternate versions of firmware and firmware applications. Order 371 firmware for endpoint 150. The user's order may be identified as a service subscriber and/or the endpoint 150 may be identified as a device to be ordered.

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

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

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

In general, identity data 113 may be via a client server (eg, 141 or 143 ), via firmware store 170 , via another server or gateway, or without going through any of client servers 141 , . . . , 143 and firmware store 170 A case is submitted to the secure server 140.

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

For example, when a server (eg, client server 141 or 143 , firmware store 170 , or another server) receives identity data 113 for request 171 from endpoint 150 , the server (eg, 141 ) provides the identity to security server 140 in request 173 Data 113 for verification. 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 (eg, application 367 ) in memory device 130 , command 155 signed with encryption key 145 is executed in memory device 130 such that The new version of firmware and/or firmware application (eg, application 367 ) executes in memory device 130 and becomes part of the identity of memory device 130 and/or endpoint 150 .

For example, firmware 363 may be initially installed in endpoint 150 (eg, by the manufacturer of endpoint 150 ) to provide services via client server 141 . After a new version of firmware 363 is provided in firmware store 170 for accessing the same 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, update 377 may be implemented via installing a firmware application (eg, application 367 ) running on existing firmware 363 , or via installing new firmware (eg, 365 ).

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

In some cases, endpoint 150 accesses secure server 140 first. 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 firmware updates for the endpoint 150 .

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

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

The access controller of the memory device 130 is configured to require authentication to request the memory device 130 to execute a command 155 to change the firmware stored in the memory device 130 .

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

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

In some embodiments, firmware store 170 is part of a server system that implements secure server 140 . In another embodiment, the 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 the services subscribed for the endpoint 150, as discussed further below in connection with FIG. 15 .

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 Figure 15, the online service store 190 is configured to facilitate the selection of a service for the endpoint 150 from a plurality of services provided by one or more service providers (eg, 381). The services of a service provider (eg, 381 ) may be implemented via one or more endpoint platforms (eg, 361 , . . . , 362 ).

For example, a user of endpoint 150 may use computer 180 to access online service store 190 in order to use computer 180 to order 391 services from service provider 381 . Services provided by service provider 381 may be used with endpoints of multiple endpoint platforms (eg, 361, . . . , 362). The endpoints (eg, 150 ) in the endpoint platforms (eg, 361 , . . . , 362 ) run different firmware to obtain the services of the service provider 381 . The service store 190 has subscription data 387 identifying the services and/or endpoints (eg, 150) subscribed 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 endpoints to receive services subscribed to for the endpoints accordingly.

For example, reference may be made to the public identification of the endpoint 150, the model and serial number of the endpoint 150, the mobile equipment identity number 253, the international mobile subscriber identity number 255, the unique identification 111 and/or another identification contained in the data 127 of the identity data 113 sign to explicitly order services for endpoint 150.

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

As in FIG. 14 , user computer 180 is generally distinct and separate from endpoint 150 . In some cases, endpoint 150 may contain a user interface that allows it to function as computer 180 for ordering 391 services for endpoint 150.

When implicitly ordering services for endpoint 150, the identity of the subscriber may be used to determine the service of the subscriber's endpoint based on a match of the identity of the subscriber for ordering the service with the identity of the owner of endpoint 150.

For example, to order 391 services from service provider 381, a user of endpoint 150 (or a user's representative) may visit service store 190 to establish an account for subscribing to service provider 381's services.

In response to a service being ordered or changed, or in response to the endpoint 150's identity data 113 being verified, the security server 140 and the service store 190 may communicate with each other to identify 393 the service to which the endpoint 150 is subscribed.

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, service request 171 may be initially received in client server (eg, 141 or 143 ) or in service store 190 or firmware store 170 or directly in secure server 140 .

After the security server 140 verifies 373 the identity and authenticity of the endpoint 150, the security server 140 may recognize 393 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 subscribed service.

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 replacing firmware or installing a firmware application (eg, application 367 ) to customize endpoint 150 for subscribed services. Firmware updates may be performed and secured in the manner discussed above in connection with FIG. 14 .

For example, endpoint 150 may be manufactured using a generic version of firmware 363 that cannot receive services from service provider 381, is unaware of client server 141 for services provided by service provider 381, and/or is not implemented for interfacing with clients The communication protocol by which the server 141 communicates. Firmware applications (eg, application 367 ) may be installed and run on generic firmware 363 to customize endpoint 150 for services subscribed to endpoint 150 . Once customized via a firmware application (eg, application 367 ), endpoint 150 may receive service provider 381 services from client server 141 . For example, after installing a firmware application (e.g., application 367) to update 377 firmware, endpoint 150 has knowledge about client server 141, the communication capability to communicate with client server 141 according to the communication protocol used by client server 141, and processing routines for using the services provided by the client server 141 .

For example, a service subscribed for operation of endpoint 150 may include computations performed by client server 141 to process data for endpoint 150, storing data generated by endpoint 150 in client server 141, sending data to an endpoint associated with endpoint 150 or Multiple other devices send notifications and/or alerts via client server 141 in connection with one or more other devices associated with endpoint 150, using cellular base stations, Wi-Fi access points, communication satellites, and/or by client servers A communication connection or device controlled by 141 connects endpoint 150 to a computer network or the Internet, and so on.

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

In general, the service store 190 is available to the user (or the user's representative) for subscribing to the services of the service provider 381 for the endpoint 150, changing subscribed services, and moving subscriptions from one service provider 381 to another. The firmware 363 of the endpoint 150 is automatically updated to support the currently subscribed service without requiring the user of the endpoint 150 to operate the endpoint 150 to customize the endpoint 150 for the subscribed service.

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 endpoint 150 with identity data 113 generated by memory device 130 configured in endpoint 150 .

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

For example, endpoint 150 may be in a state of being shipped from the endpoint (eg, 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 memory device 130 secret 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 the verification code 133 for the message 131 presented in the identity data 113 . The security server 140 can 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 presenting the secret key 137 . The secret key 137 is generated using the unique device secret 101 of the memory device 130 and the device information 121 representing the software and hardware configuration of the endpoint 150 .

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

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

For example, the public identification of endpoint 150 may be used to identify order 391 of endpoint 150 . The identity data 113 may contain the 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 verifying that the message 131 has not changed, the security server 140 may instruct the online firmware store 170 and/or the endpoint 150 to update 377 the firmware 363 of the endpoint 150.

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

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

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

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

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

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

The second firmware may become part of the identity of memory device 130 and endpoint 150 after executing command 155 to perform a firmware update. For example, based on the device information 121 , the memory device 130 is configured to generate a secret key 137 representing the identity of the memory device 130 and the endpoint 150 . After executing the command 155 to update 377 the firmware, the device information 121 is updated to contain the hash value 163 of the second firmware stored in the memory unit 103 as the content 161 . The memory device 130 is then configured to generate the identity data 113 for the endpoint 150 using an encryption key based at least in part on the memory device's secret (eg, the unique device secret 101 ) and a second stored in the memory device 130 generated by the firmware.

Figure 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 FIGS. 14 and 15 .

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

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

At block 423 , the security server 140 responds to the request received in block 421 and verifies the identity data 113 based on the information stored in the security server 140 about the endpoint 150 . Such information includes memory device 130 secrets, such as unique device secret 101 . Such information may further include device information 121 representing the software/hardware configuration of endpoint 150 . Validation 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 at block 421 is valid, at block 425 the server system identifies the service ordered in the online service store 190 for the endpoint 150 .

At block 427, the 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 be identified based on order 391 .

For example, order 391 may be received in online service store 190 by user computer 180 and thus not through endpoint 150 . The order 391 of the endpoint 150 may be identified/placed using the public identification of the endpoint 150. Identity data 113 may contain public identification. Alternatively, the order 391 may be associated with the identity of the user who is the owner of the endpoint 150 in the client rights data 283 of the secure 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 ordered in the online service store 190 .

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

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

For example, following 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 the endpoint 150 is running 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 the identification of the client server 141 for directing endpoints to access the client server 141 for services ordered in the online service store 190 . In a certain embodiment, the second firmware is a combination of the first firmware and an added firmware application. Following firmware update 377, memory device 130 is configured to generate updated identity data 113 for endpoint 150 using secret key 137 based at least in part on a secret (eg, unique device secret 101) and stored in the memory device The second firmware in 130 is generated.

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

For example, to perform the firmware update 377 , the server system may generate the verification code 153 for the command 155 using the encryption key 145 representing the authority to execute the command 155 in the 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 against the authority before executing the command 155 .

Security server 140 may not only be used to authenticate the identity of endpoint 150 based on the security features of memory device 130 configured in endpoint 150 , but may also be used to monitor the integrity of packets stored in memory device 130 and/or endpoint 150 . For example, a package stored in endpoint 150 may be a bootloader, firmware, software, module, at least a portion of an operating system or application, a set of files specifying resources, configuration parameters, and/or other data for a program or routine, and many more. Security server 140 may initiate over-the-air (OTA) updates to maintain endpoint 150 integrity when packets are found to be corrupted, modified, tampered, or outdated.

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. 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 the content repair.

For example, content 161 may contain the core package of endpoint 150 . In verifying 373 the identity of the endpoint 150, the integrity of the core package may affect the operation of the endpoint 150 when communicating with the security server 140. An example of a core package may include at least a portion of the endpoint 150 bootloader, firmware, and/or operating system. When the core package is modified, corrupted or tampered with, the security of the operations performed by the endpoint 150 for authentication may not be trusted. When the integrity status 165 generated by the encryption engine 107 indicates that the core package has changed, the access controller 109 may prevent the host system 120 from accessing the content 161 until the core package is repaired.

For example, the memory device 130 may store a reliable backup copy of the core package in a separate segment; and when the hash value of the core package in the content 161 stored in the memory unit 103 is different from the corresponding hash value of the stored device information 121 At 163, the memory device 130 may replace the core package stored in the memory unit 103 with the copy stored in the separate segment. Optionally, execution of the replacement copy in endpoint 150 may be configured to initiate a recovery process to obtain the latest version of the package from a trusted source (eg, firmware store 170). Alternatively, the security server 140 may initiate the update (eg, using the firmware store 170 ) after validating the identity data 113 of the memory device 130 and/or the endpoint 150 submitted via the replacement copy.

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

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

Additionally, some packets of endpoint 150 may be stored in another device that does not have the security features of memory device 130 . Execution of the core package in host system 120 may generate the current hash value of the package as a health indicator for the package. 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 packets.

In general, identity data 113 may include data indicative of the health of packets in 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 packages 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 .

Furthermore, in response to verifying 373 the identity data 113 of the endpoint 150 to access the services of the client server (eg, 141, . . . , 143), the security server 140 may be configured to track and/or monitor the activity of the endpoint 150 while accessing the service to enforce further security operations.

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

For example, the information about the tracked activity may include location information of endpoint 150 and/or the type of service that endpoint 150 is requesting 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 the unique identification 111 of endpoint 150, but also the context and/or aspect of the service, eg, client server 141, location of endpoint 150, date and time of the request, class/type of service, parameters of the service, etc.

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

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 associate the location with request 173 Provided to secure server 140 to authenticate identity data 113 .

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

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

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

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

In FIG. 18, endpoint 150 stores packet 167 with hash value 169. Package 167 may be stored in memory device 130 with the security features discussed above, or in another memory device of endpoint 150 that may or may not have the security features of memory device 130 . When the packet 167 is stored in the memory device 130 , the encryption engine 107 of the memory device 130 may calculate the hash value 169 of the packet 167 independently of the processing device 118 of the host system 120 in the endpoint 150 . When packet 167 is stored outside of memory device 130, hash value 169 may be retrieved by processing device 118 of host system 120 executing a routine stored in memory device 130 that has verified that it has not changed (eg, as in FIG. 4 ). get.

In general, packets 167 may contain instructions and/or data, such as the same resources for a set of endpoints (eg, 150) and different configuration parameters for different endpoints (eg, 150).

The hash value 169 of the packet 167 indicates the health of the packet 167 .

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

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

For example, a healthy and up-to-date copy of package 167 may be stored in a server (eg, secure server 140 , firmware store 170 , or another server) to facilitate repair or recovery 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 377 of the firmware 363 of the endpoint 150 discussed in connection with FIGS. 14-17 in a manner similar to that renew.

Package 167 may be individualized for endpoint 150 . For example, when package 167 contains configuration parameters that are specific to endpoint 150 in platform 361 but not applicable to other endpoints in platform 361, a healthy copy of package 167 can be uploaded to the server as soon as package 167 in endpoint 150 is successfully configured ( For example, security server 140, firmware store 170, or another server).

In some embodiments, memory device 130 and/or endpoint 150 may be configured to store hash values of healthy individualized copies of packages 167 . For example, a healthy hash value may be stored as part of the device information 121 used to create the secret key 137 . The message 131 in the identity data 113 may contain an indication of whether the current packet 167 is healthy, but not the current hash value 169 of the packet 167 .

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

For example, upon successful configuration of the personalization package 167 in the endpoint 150 , the endpoint 150 and/or memory device 130 may calculate a hash value of a healthy copy of the personalization package 167 and encrypt the personalization package 167 using the public key 139 . The endpoint 150 may submit the hash value and encrypted packet 167 for storage in the 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 packet. Optionally, encryption engine 107 may generate a separate key pair to protect individualized package 167 .

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

In Figure 18, the identity data 113 contains not only the current hash value 169 of the packet 167, but also activity information 177 that identifies 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 (eg, 167 or another package, such as firmware, applications, routines).

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

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

For example, the activity information 177 may include the 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 contain one or more attributes of the requested service, such as the category of the service, the identification of another party involved in the service, the quantity or volume involved in the service, and the like.

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

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

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

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

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

In FIG. 19, endpoint 150 stores a plurality of packets 441, 443, . . . , 445. Some packets are stored in the memory device 130 with security features. Some packets may be stored outside of the memory device 130 .

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

The security features of the memory device 130 ensure that the endpoint 150 runs a valid version of the package 441 against tampering and/or corruption during operations to verify 373 the identity of the endpoint 150 and repair 385 the package.

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

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

Identity data 113 may include package health information 447, such as current hash values for packages 441, 443, . An indication of whether any of 443, . . , 445 is damaged.

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 . The session key 263 may be generated to be shared between the memory device 130 and the secure server and used to authenticate 373 the identity of the endpoint 150 in the manner discussed with respect to FIG. 9 .

In general, identity data 113 may be directly via a communication connection or indirectly via an intermediary server (eg, client server 141 in Figures 5, 9 or 10, firmware store 170 in Figure 14 or 15, service store in Figure 15 190 or the package repository 191 of FIG. 19) is transmitted from the endpoint 150 to the security server 140.

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 , . . . , 445 based on the package health information 447 provided in the identity data 113 .

For example, packet 441 may be available in endpoint 150. However, because a new version of package 441 has been published in package repository 191, package 441 may be out of date. Thus, the update package 441 may improve the security of the operation of the endpoint 150 and the integrity of the system.

For example, packets 443 or 445 may have changed in endpoint 150, and thus be corrupted. 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 package (eg, 441, 443, ..., 445) is found to be outdated or corrupt, the security server 140 may instruct the endpoint 150 and/or the package repository 191 to repair 385 or update 377 the package.

The operation of repairing 385 or updating 377 the package may include the secure server 140 generating the verification code 153 of the command 155 to write the data to the memory device 130 . When the package contains sensitive information (eg, configuration parameters customized for endpoint 150), the replacement package may be provided to memory device 130 using ciphertext generated by session key 263 or another secret key.

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

20 illustrates a system for implementing security operations based on tracking endpoint activity, according to one embodiment.

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

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

As in Figures 14 and 15, user computer 180 is generally distinct and separate from endpoint 150. In some cases, endpoint 150 may include a user interface that allows it to function as computer 180 to set preferences 455 and/or review activity records 453 .

The activity tracker 451 is coupled with the security server 140 to store activity records 453 regarding 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 contain security settings for endpoint 150 activities. For example, security settings may be used to implement parental controls, detect fraudulent use of endpoint 150, track the location of endpoint 150, and the like.

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

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

For example, preferences 455 may contain user-selected options associated with predetermined conditions specified in preferences 455 . The selected option 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 when the activity associated with the submission of the identity data 113 is eligible. Alternatively or in combination, the selection scheme may trigger a security alert for contacts registered in preferences 455 .

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

The identity data 113 provided in the access request 171 may contain 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 some aspect 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 a verification request 173 to security server 140, which verifies identity data 113 to determine the authenticity of endpoint 150's identity.

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

Based on activity log 453 , activity tracker 451 determines whether the current activity satisfies any of the conditions specified in preferences 455 . If the conditions in the preferences 455 are met, the activity tracker 451 may perform secure operations to implement the selection scheme selected for the conditions.

For example, security operations may include notifications to registered owners or users of endpoint 150 .

For example, the security operation 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 the like.

Optionally, activity tracker 451 may identify activity patterns of endpoint 150 from records 453 of past activity.

For example, a schema may include a geographic area or zone of endpoint 150 in which endpoint 150 has operated in the past. For example, a pattern may include a day or time period of the week in which the endpoint 150 has had no activity in the past. For example, a pattern may contain a range of access attributes 449 for the endpoint's 150 past activity.

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

Optionally, security server 140 may examine activity information 177 provided in 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 with corresponding information in the access attribute 449 to detect a mismatch. A mismatch may be an indication that stolen identity data 113 was used or that endpoint 150 was tampered with or operated insecurely.

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

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

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

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

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

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

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

For example, the receipt of identity data in block 461 may be the result of endpoint 150 executing package 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 out of date.

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

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

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

The identity data 113 includes the first verification code 133 . The security server 140 verifies the identity data 113 by determining whether the first verification code 133 is generated from the message 131 and the secret of 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 the memory device 130 is assembled into the endpoint 150 , the secrets of the memory device 130 are not transferred outside the memory device 130 .

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

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

For example, in order to replace or repair a package stored in memory device 130 , secure server 140 generates a second verification code 153 for command 155 using an encryption key representing authority to execute command 155 in memory device 130 . For example, when executed in memory device 130, command 155 causes a packet (eg, 441 or 443) in memory device 130 to be replaced.

In some embodiments, in order to repair a package 445 stored outside of the memory device 130 , the replacement of the package 445 is initially stored in the memory device 130 . After the memory device verifies the integrity of the replacement, package 445 may be replaced via execution of the instructions in package 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 the repair or replacement of the package 445 to be performed.

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 FIGS. 18 and 20 .

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

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

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

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 conditions may be specified in the preferences 455 of the endpoint 150.

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

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

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

Conditions may be evaluated for the 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 security server 140 determines that verification code 133 in identity data 113 is valid, security server 140 may trust that activity information 177 embedded in identity data 113 has not changed since memory device 130 generated verification code 133 . Accordingly, activity information 177 can be extracted from identity data 113 to evaluate conditions. Optionally, activity information 177 may be provided in the message in ciphertext to be decrypted using session key 263 generated in the manner discussed in FIG. 9 or another secret encryption key of 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 a service provided by client server 141 , client server 141 may generate an authentication request 173 to security server 140 . Authentication request 173 is generated to include identity data 113 from access request 171 . Additionally, in the context of requesting the services of client server 141 , client server 141 may add access attributes 449 to provide information about the activity of endpoint 150 .

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

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

For example, the activity tracker 451 of the server system may store a number of records 453 of the activity of the endpoint 150 . Based on the plurality of records 453, the activity tracker 451 can determine the activity pattern of the endpoint 150. Patterns can include geographic areas, time periods of the day or week, or ranges of activity attributes, or any combination thereof. The conditions that trigger the safe operation of block 489 may be satisfied by deviating mode activities.

Optionally, activity tracker 451 may present endpoint 150 activity to an owner or authorized user of endpoint 150 based on record 453 . For example, based on a review of past activity, the owner or authorized user may specify conditions for implementing parental controls, access restrictions, and the like.

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 by the client server 141 to the account. When endpoint 150 is not using the service, the association between the identity of endpoint 150 and the subscription account may be removed to allow another endpoint to use the subscription account. Thus, a set of endpoints (eg, 150) may be configured to share subscription accounts and use subscription accounts one at a time.

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

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

For example, a subscription service (eg, a cellular connection) provided to a subscription account may be shared among a group of endpoints owned by an enterprise (or another entity). Endpoints in this group (eg, 150) may not require the account's services at the same time. Therefore, it may be advantageous to configure endpoints in this group to share one or more subscription accounts. When more than one subscription account is configured to be shared by a group of endpoints (eg, Internet of Things (IoT) devices), a small portion of the group may use the services of the subscription account concurrently.

For example, the server system may be configured to track the current usage status of endpoints in the population. Endpoints can be dynamically bound to subscription accounts when they communicate with client servers to request services. When the endpoint is not using the service, the subscription account can be released from the endpoint. When the number of endpoints that are using a service provided to a subscription account is greater than the number of subscription accounts that can be shared, an active endpoint can use the account's service concurrently. When a subscription account is currently bound to and is being used by a part of the community, requests for services from another endpoint may be denied until one of the subscription accounts is not in use and thus becomes available for sharing.

For example, in response to an enterprise's Internet of Things (IoT) device requesting a cellular connection, a virtual subscriber identity module (vSIM) can be bound to the IoT device. When the cellular connection has been idle for a period of time longer than a threshold, the cellular connection can be disconnected; and the virtual subscriber identity module (vSIM) can be released from the IoT device and can be used to bind with another IoT device of the enterprise. Thus, an enterprise can subscribe to a reduced number of vSIMs; and when these vSIMs are all in use, a request for a cellular connection from another device can be put on hold until one of the connections is disconnected and the vSIM is released for allocation to hold until the device.

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

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

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

The endpoint group 501 has a plurality of unique identities 111 , . . . , 112 . Each of the unique identifications (eg, 111) represents a memory device (eg, 130) installed in a corresponding endpoint (eg, 150) of a set of endpoints.

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

For example, the subscriber identity number 505 may be used to represent a unique subscriber in the same way that a subscriber identity module (SIM) represents a subscriber in a cellular communication network.

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

Similarly, when the subscriber identification number 505 is associated with the unique identification 111 , the service provided to the subscriber account represented by the subscriber identification number 505 is provided to the endpoint 150 having the 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 identification 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 verification 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 verification 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 available for use by the memory device 130 and/or endpoint 150 with 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 service to endpoint 150 to the account identified by subscriber identity number 505 .

In some embodiments, if no subscriber identity number 505 is currently available in the subscriber group 503 for the endpoint 150, then the authentication response 174 does not identify the subscriber identity number for the identity data 113, which can cause the client server 141 to reject data from the endpoint 150 service requests.

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

In some embodiments, the system is configured to associate the unique identification 111 with the subscriber identification number 505 within a predetermined period of time after the verification response 174 identifying the subscriber identification number 505 of the unique identification 111 and/or the identity data 113 . After the predetermined period of time, the service store 190 removes the assignment of the subscriber identification number 505 to the unique identification 111 so that the subscriber identification number 505 is available for another endpoint in the endpoint group 501 with a different unique identification (eg, 112) . After the predetermined period of time, the client server 141 does not provide services to the account represented by the subscriber identity number 505 to the endpoints (eg, 150 ) in the endpoint group 501 having unique identifications 111 , . . . , 112 Either, until another verification response 174 is received from the security server 140 that associates the subscriber identity number 505 with one of the unique identities 111 , . . . , 112 in the endpoint group 501 .

Service store 190 can control the use of subscriber identity numbers (eg, 505) in subscriber group 503 when endpoints with unique identities 111, . . . , 112 compete to use subscriber identity numbers (eg, 505) in subscriber group 503 distribute.

For example, service store 190 can track endpoints in group 501 that deny access requests because there are no available subscriber identity numbers 505, and prioritize subsequent assignments 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; The endpoint with the earliest request that was rejected may have the highest priority to gain the opportunity to use the subscriber identity number 505 .

In some embodiments, endpoints in endpoint group 501 with unique identities 111, . . . , 112 may compete for the opportunity to use a subscriber identity number (eg, 505) in subscriber group 503 based on one or more predefined rules . For example, after receiving a denial of a service request, an endpoint (eg, 150) may wait a random period of time for subsequent requests. By the randomness of the waiting period after denial, the opportunity to gain access to the service using the subscriber group 503 can be allocated to endpoints requiring service.

In some embodiments, the endpoint 150 temporarily assigned the subscriber identity number 505 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 the communication using the service provided to subscriber identity number 505, endpoint 150 may return subscriber identity number 505 to the pool of subscriber identity numbers in group 503, which may be assigned to group 501 Another endpoint with unique identification 112 and/or used by the other endpoint.

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

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 conjunction 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 distribution and/or use the distribution to provide services, as shown in FIG. 24 .

In FIG. 24, client server 141 is coupled to service store 190 and activity tracker 451. Based on the verification response 174 indicating the authenticity of the endpoint 150 with the unique identification 111 and the availability of the subscriber identification number 505 for the endpoint group 501 , the client server 141 may cause the service store 190 to store the information indicating the subscriber identification number 505 to the unique identification 111 . Temporarily allocated data.

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

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

For example, after 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 embodiments, the client server 141 may cause the service store 190 to terminate the assignment of the subscriber identification number 505 to the unique identification 111 some time period after the assignment of the subscriber identification number 505 to the unique identification 111 . The time period may be predetermined, or determined from the access request 171 received from the endpoint 150 .

Figure 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 FIGS. 1-19 using the techniques discussed above in connection with FIGS. 23 and 24 .

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

For example, the server system may include a secure server 140 that stores secrets for memory devices (eg, 130 ) and/or other servers, such as service store 190, activity tracker 451, package repository 191, firmware store 170, and/or or another server. The server system may further include the client server 141 and/or the card server 223 shown in FIG. 6 .

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

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

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 (eg, identity number 505 ) is not currently assigned to any endpoint in endpoint group 501 .

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

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

For example, a service network (eg, 225) may be configured to provide services to endpoints, such as a cellular communication connection, an Internet connection, a connection to a user's computer, online storage facilities, online computing resources, payments, transactions or messages, or any combination thereof.

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

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

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

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

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

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

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

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

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

In general, endpoints 150 may be identified using different identities 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 number of members, subscribers, accounts, authorized devices and/or entities in a group specific to a certain type of service, connection, communication, or the like.

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

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

For example, an endpoint 150 may be assigned an integrated circuit card identifier 251 for use as a smart card, a mobile device identity number 253 for use as a cellular communication device, a mobile subscriber identity number 255 for use as a subscriber for cellular connectivity services, and the like.

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 the security server 140 to bind subscription services in the account to the public identity of the endpoint 150 . Since identifications are publicly known, there is a potential risk of fraudulent use of public identifications. Identity data 113 of endpoint 150 may be configured to contain a 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; Identify the identity of the representation. The fraudulent use of a public identification as an identity can be detected through verification performed by the secure server 140 .

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

For example, in response to a request to bind the public identity to the endpoint 150, the security server 140 may verify that the public identity is not currently bound to another endpoint, and may operate the memory device 130 using an encryption key generation command representing owner rights, The public identification is stored 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 associating the endpoint 150 with the public identity of the endpoint 150 in the application domain. In response to the verification request 173 in the application domain, the security server 140 verifies the identity data 113 provided in the endpoint 150 and looks up the public identity of the endpoint 150 in the application domain. The public identification may be provided in the verification response 174 .

Secure, dynamic binding of public identities to endpoints 150 can be used to facilitate secure operations. For example, when endpoint 150 is lost/stolen, the owner of endpoint 150 may request security server 140 to bind the public identification of lost/stolen endpoint 150 to a replacement endpoint. Once the security server 140 has bound the public identification of the lost/stolen endpoint 150 to the replacement endpoint, 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 a replacement device; and after the transfer, the owner may request to deactivate the lost/stolen endpoint 150 to minimize the endpoint 150 loss/impact.

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

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

In Figure 26, the secure server 140 stores the unique identification 111 of the memory device 130 and its unique device secret 101. Additionally, the security server 140 stores device information 121 that characterizes the hardware, software and/or data configuration of the endpoint 150 on 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 for 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 with the unique device secret 101 generated by device 130.

In FIG. 26 , the security server 140 may bind the unique identification 111 to the public identification 541 of the endpoint 150 . For example, after the public identification 541 is assigned to the 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 the endpoint 150 .

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

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

After verification of the identity data 113 , the security server 140 may add the public identification 541 to the device information 121 and cause the memory device 130 in the endpoint 150 to update 543 the device information 121 . After the update 543 , the memory device 130 has a new secret key for it to generate the new identity data 113 containing the public identification 541 . For example, message 131 in new identity data 113 may contain public identification 541 in addition to unique identification 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 security server 140 to 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 an update 377 of the firmware of the endpoint 150 and/or a fix 385 of a package 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 . Verification code 153 is generated using encryption key 145 representing owner rights to operate memory device 130 , including rights controlled by access controller 109 of memory device 130 to execute commands 155 in memory device 130 .

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

Optionally, update 543 is skipped; and memory device 130 and/or endpoint 150 do not store public identification 541. The secure server 140 stores data that associates the unique identification 111 with the public identification 541 . After the security server 140 validates the identity data 113 provided in the validation request, the security server 140 may look up the public identification 541 associated with the application domain for the unique identification 111 identified in the message 131 of the identity data 113, and in the validation response The public identification 541 is provided in , in a manner similar to the way the subscriber identity number 505 is presented in the authentication 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 identification 541 with the endpoint 150 having the unique identification 111 . After portal 545 verifies that computer 180 is operated by an authorized owner or user of endpoint 150 , portal 545 may communicate with security server 140 to update device information 121 that uniquely identifies 111 .

In one embodiment, endpoint 150 has packets stored in memory device 130 . When the package is loaded from memory device 130 and executed in host system 120 , endpoint 150 may communicate with server 140 to obtain updates 543 . Communication between endpoint 150 and server 140 may be through a client server (eg, 141), firmware store 170, service store 190, activity tracker 451, or another server (eg, portal 545), or not through any intermediary server.

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

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

Figure 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 FIGS. 1-19 using the techniques discussed above in connection with FIG. 26 .

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

For example, the server system may include the security server 140 . Optionally, the server system may further include a portal 545, a firmware store 170, a service store 190, an activity tracker 451, a package repository 191 and/or another server. In some embodiments, the server system may further include the client server 141 and/or the 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 (eg, 547 or 549).

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

In one embodiment, such a second identification 541 is attached to the endpoint 150's authority to operate the computer and has ownership of the memory device 130 (eg, as a manufacturer, retailer, service provider, end user of endpoint 150) associated entity.

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 contains the first identification 111 and can 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 the 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 endpoint 150 to update data stored in memory device 130 and/or store second identification 541 in memory device 130 .

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

Optionally, the second identification 541 does not alter the generation of the secret key 137 . However, 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 (eg, as part of the data C 127).

For example, in response to the request to bind the second identification 541 to the endpoint 150 , the server system may generate a verification code 153 for the command 155 and cause the memory device 130 to execute the command 155 according to the verification code 153 . After receiving command 155 and verification code 153 for command 155 , access controller 109 of memory device 130 is configured to use an encryption key (eg, access control key 149 ) that represents authority to execute command 155 in memory device 130 to Verification code 153 of command 155 is verified. Memory device 130 is configured to execute command 155 in response to determining that verification code 153 of command 155 is valid; executing command 155 in memory device 130 may store second identification 541 in memory device 130 for subsequent generation of 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, a memory device stores a set of instructions executable in endpoint 150 . The set of instructions may be part of the content 161 or a package 441 of the endpoint's firmware or operating system. The memory device 130 is configured to verify the integrity of the set of instructions before allowing the endpoint 150 to load the set of instructions for execution. Because the set of instructions is protected via the memory device 130 , the server system can 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 the endpoint 150 and the server system may optionally be protected by the client server 141 and/or optionally via the session key 263 and symmetric encryption.

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

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

In some embodiments, the message 131 presented in the identity data 113 does not contain the 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 (eg, 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 authentication 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 verification 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 .

28 illustrates an example machine of a computer system 600 within which a set of instructions may be executed to cause the machine to perform any one or more of the methods discussed herein. In some embodiments, computer system 600 may correspond to a host system that includes, is coupled to, or uses a memory subsystem, or may be used to perform operations of security manager 160 (eg, execute instructions to perform instructions corresponding to those described with reference to FIGS. 1-27 ). operation of the security features of the security server 140 and/or the memory device 130). In alternative embodiments, the machines may be connected (eg, networked) to other machines in a LAN, intranet, 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 in a cloud computing infrastructure or environment or Client machine operation.

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

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

Processing device 602 represents one or more general-purpose processing devices, such as microprocessors, central processing units, and 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 that implements a combination of instruction sets. Processing device 602 may also be one or more special purpose processing devices, such as application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, and 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 network interface device 608 in communication via network 620 .

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

In one embodiment, the instructions 626 include instructions that implement functionality corresponding to the security manager 160 (eg, the operation of the security features of the security server 140 and/or memory device 130 described with reference to FIGS. 1-27 ). Although machine-readable storage medium 624 is shown as a single medium in example embodiments, the term "machine-readable storage medium" should be considered to encompass a single medium or multiple media that store one or more sets of instructions. The term "machine-readable storage medium" shall also be considered to include any medium capable of storing or encoding a set of instructions for execution by a machine and causing the machine to perform any one or more of the methods of the present disclosure. The term "machine-readable storage medium" shall therefore be considered to include, but not be limited to, solid-state memory, optical media, and magnetic media.

In general, endpoint 150, a server (eg, security server 140, client server 141 or 143, or card server 223) may be a computing system having a 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 (eg, memory device 130), or a combination of these.

The memory subsystem may be a storage device, a memory module, or a mixture of storage devices and memory modules. Examples of storage devices include solid state drives (SSD), 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, a computing system may be a computing device, such as a desktop computer, laptop computer, web server, mobile device, vehicle (eg, airplane, drone, train, car, or other vehicle), with Internet of Things (IoT) Functional devices, embedded computers (eg, embedded computers contained in vehicles, industrial equipment, or networked business devices), or such computing devices that include memory and processing means.

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

Host system 120 may include a processor chipset (eg, processing device 118) and a software stack executed by the processor chipset. A processor chipset may include one or more cores, one or more caches, a memory controller (eg, controller 116 ) (eg, NVDIMM controller), and a storage protocol controller (eg, PCIe controller, SATA controller) device). 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 the memory subsystem via a physical host interface. Examples of physical host interfaces include, but are not limited to, Serial Advanced Technology Attachment (SATA) interface, Peripheral Component Interconnect Express (PCIe) interface, Universal Serial Bus (USB) interface, Fibre Channel, Serial Attached SCSI (SAS) interface , double data rate (DDR) memory bus interface, small computer system interface (SCSI), dual inline memory module (DIMM) interface (eg, double data rate (DDR) capable DIMM socket), open NAND Flash Interface (ONFI), Double Data Rate (DDR) interface, Low Power Double Data Rate (LPDDR) interface, or any other interface. A physical host interface may be used to transfer data between the host system 120 and the memory subsystem. Host system 120 may further utilize an NVM Express (NVMe) interface to access components (eg, memory device 130 ) when the memory subsystem is coupled to 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 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, controller 116 may be referred to as a memory controller, a memory management unit, and/or an initiator. In one example, controller 116 controls communications over a bus coupled between host system 120 and the memory subsystem. In general, the controller 116 may send a command or request to the memory subsystem desiring to access the memory device 130 . Controller 116 may further include interface circuitry for communicating with the memory subsystem. The interface circuitry may translate the responses 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 and other such operations. In some cases, the controller 116 is integrated within the same package of the processing device 118 . In other cases, the controller 116 is separate from the packaging of the processing device 118 . Controller 116 and/or processing device 118 may include hardware such as one or more integrated circuits (ICs) and/or discrete components, buffer memory, cache memory, or combinations thereof. Controller 116 and/or processing device 118 may be a microcontroller, special purpose logic circuitry (eg, field programmable gate array (FPGA), application specific integrated circuit (ASIC), etc.), or another suitable processor.

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) type flash memory and write-in-place memory, such as three-dimensional crosspoint ("3D crosspoint") memory. Non-volatile memory crosspoint arrays can perform bit storage based on changes in bulk resistance in conjunction with stackable cross-grid data access arrays. In addition, in contrast to many flash-based memories, cross-point non-volatile memory can perform in-situ write operations, where non-volatile memory cells can be programmed while they have previously been erased. The NAND-type flash memory includes, for example, two-dimensional NAND (2DNAND) 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), can store one bit per cell. Other types of memory cells, such as multi-level cell (MLC), three-level cell (TLC), quad-level cell (QLC), and five-level cell (PLC), can store multiple bits per cell. In some embodiments, each of the memory devices 130 may include one or more arrays of, for example, SLC, MLC, TLC, QLC, PLC, or any combination thereof. In some embodiments, a particular memory device may include an SLC portion, an MLC portion, a TLC portion, a QLC portion, and/or a PLC portion of memory cells. The memory cells of memory device 130 may be grouped into pages, which may refer to logical units of the memory device used to store data. In some types of memory (eg, NAND), pages may be grouped to form blocks.

Although non-volatile memory devices such as 3D cross-point and NAND-type memories (eg, 2DNAND, 3D NAND) are described, memory device 130 may be based on any other type of non-volatile memory, such as read only memory (ROM). ), phase change memory (PCM), optional memory, other chalcogenide based memories, ferroelectric transistor random access memory (FeTRAM), ferroelectric random access memory (FeRAM), magnetic random access memory (MRAM), Spin Transfer Torque (STT) - MRAM, Conductive Bridge RAM (CBRAM), Resistive Random Access Memory (RRAM), Oxide-Based RRAM (OxRAM), or Non-(NOR) Flash, 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 (eg, in response to an operation performed by the controller 116 on the command bus). scheduled command). 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. Hardware may include digital circuitry with dedicated (eg, hard-coded) logic to perform the operations described herein. The memory subsystem controller may be a microcontroller, special purpose logic circuitry (eg, field programmable gate array (FPGA), application specific integrated circuit (ASIC), etc.), or another suitable processor.

The memory subsystem controller may include a processing device (eg, a processor) configured to execute instructions stored in local memory. In the example shown, the local memory of the memory subsystem controller includes embedded memory configured to store instructions for performing various processes, operations, logic flows and routines that control the operation of the memory subsystem, including handling Communication between the memory subsystem and host system 120 .

In some embodiments, the local memory may include memory registers that store memory pointers, fetched data, and the like. 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 contain a memory subsystem controller, but may rely on external control (eg, by an external host or by a processor or control separate from the memory subsystem) provided by the device).

In general, a memory subsystem controller may receive commands or operations from host system 120 and may convert the commands or operations into instructions or appropriate commands to effect desired accesses to 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 logical addresses associated with memory device 130 (eg, Address translation between logical block addresses (LBAs, namespaces) and physical addresses (eg, physical block addresses). The memory subsystem controller may further include host interface circuitry for communicating with host system 120 via a physical host interface. Host interface circuitry may translate commands received from the host system into command instructions to access memory device 130 and translate responses associated with memory device 130 into information for 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 (eg, DRAM) and address circuitry (eg, a row decoder) that may receive and decode addresses from the memory subsystem controller to access memory device 130 and column decoders).

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

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 the local media controller in the memory subsystem may include at least a portion of the security manager 160 . In other embodiments, or in combination, controller 116 in host system 120 may include at least a portion of security manager 160 . For example, the memory subsystem controller, controller 116 and/or security server 140 may contain logic circuitry and/or execute instructions when implementing security manager 160 . For example, a memory subsystem controller or processing device 118 (eg, a processor) of host system 120 may be configured to execute instructions stored in memory device 130 for performing the operations of security manager 160 described herein. In some embodiments, the security manager 160 is implemented in an integrated circuit chip disposed in the memory subsystem. In other embodiments, the security manager 160 may be part of the firmware of the memory subsystem, the operating system of the host system 120, a device driver or application, or any combination thereof.

Some portions of the previous detailed description have been presented with respect to algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the most efficient means used by those skilled in the data processing arts to convey the substance of their work to others skilled in the art. Here and generally, an algorithm is conceived as a self-consistent sequence of operations that produce 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 computer systems that manipulate and transform data represented as physical (electronic) quantities within the registers and memory of a computer system into other data similarly represented as physical quantities within the computer system memory or registers or other such information storage systems or similar actions and processes of electronic computing devices.

The present disclosure also relates to apparatus for performing the operations herein. This apparatus 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 computer programs may be stored in computer-readable storage media such as, but not limited to, any type of disk, including floppy disks, optical disks, CD-ROMs and magneto-optical disks, read only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic or optical cards, or any type of medium suitable for storing electronic instructions, are respectively coupled to the computer system bus.

The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the described methods. Structures for a variety of these systems will be presented from the description below. Furthermore, the present disclosure is not described with reference to any particular programming language. It should be appreciated that a variety of programming languages may be used to implement the teachings of the present 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 that may be used to program a computer system (or other electronic device) to perform processes in accordance with the present disclosure. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (eg, a computer). In some embodiments, machine-readable (eg, computer-readable) media include machine (eg, computer-readable) storage media such as read-only memory ("ROM"), random-access memory ("RAM"), magnetic disks Storage media, optical storage media, flash memory components, etc.

In this specification, various functions and operations are described as being performed by or caused by computer instructions for simplicity of description. Those skilled in the art will recognize, however, that such expressions are intended to be that the functions originate from the execution of computer instructions by one or more controllers or processors (eg, microprocessors). Alternatively or in combination, the functions and operations may be implemented using special purpose circuitry, with or without software instructions, eg, using application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). Embodiments may be implemented using hardwired circuitry without software instructions or in conjunction with software instructions. Thus, the techniques are not limited to any specific combination of hardware circuitry and software, nor to any specific source of instructions executed by a data processing system.

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

Claims (20)

1. A method, comprising:

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

receiving, in the server system, an authentication 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 the secret of the memory device and at least a portion of the 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

upon providing an authentication response in response to the authentication request, performing a security operation associated with the condition.

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

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

4. The method of claim 1, further comprising:

extracting information about the activity from the identity data in response to determining that the identity data is valid, 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 comprises decrypting a portion of a message provided in the identity data.

6. The method of claim 5, further comprising:

establishing a session key based on the verification of the identity data, wherein the decryption of the portion of the message provided in the identity data is performed using the session key.

7. The method of claim 1, further comprising:

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

determining a pattern 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 period of a day or week, a range of activity attributes, or any combination thereof.

9. The method of claim 8, further comprising:

communicating, by the server system, with a user computer to receive the data representing the one or more preferences of the endpoint; and

presenting, by the server system, the activity of the endpoint based on the record.

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

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

11. The method of claim 10, further comprising:

in response to determining that the identity data is valid, extracting information about the activity 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 comprises 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 transfer the secret out of the memory device after fabrication of the memory device is completed in a secure facility.

14. The method of claim 13, further comprising:

registering the secret during manufacture of the memory device in the secure facility; and

generating an encryption key to verify 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 a memory device; and

at least one processor configured, via a set of instructions, to:

receiving an authentication request containing identity data generated by a memory device configured in an endpoint; and is

In response to the request for authentication,

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 is

Upon providing an authentication response in response to the authentication request, performing a security operation associated with the condition.

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 specifies the condition; and determining 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 implementing a cryptographic engine and is configured to use the cryptographic engine to:

Generating an encryption key representing 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 the 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, the method comprising:

receiving an authentication request containing identity data generated by a memory device configured in an endpoint; and

in response to the request for authentication,

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 is

Upon providing an authentication response in response to the authentication request, performing a security operation associated with the condition.

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 the activity from the identity data, the first data being embedded in the identity data by the memory device; and

extracting second data about the activity from the validation request, the second data provided by a client server in the validation request, wherein the client server is configured to receive an access request from the endpoint and submit the validation request to the computing system, and wherein determining whether the condition is satisfied is based on the first data about the activity or the second data about the activity, or any combination thereof.

Images