DE102022104834A1 - ONBOARDING CLOUD SERVICES WITHOUT PRIOR CUSTOMIZATION OF DEVICES - Google Patents

Abstract

A server system for integrating a terminal with a host system connected to a host interface of a storage device for a cloud service without first adapting the terminal to identify an account for access to the cloud service. For example, upon receiving a request related to the service including identity data generated by the storage device, the server system determines the authenticity of the storage device and the terminal based on a secret code of the storage device and the identity data. In response to the request, the server system further identifies, based on the identification information, one of a plurality of participants based on the terminal's proprietary information. As a result of identifying the subscriber based on the identity data, the server system determines an account of the subscriber to provide the service to the terminal based on the account.

Description

RELATED APPLICATIONS

The present application claims the benefit of the filing date of Vorl. US Pat. Note Ser. No. 63/105,820, filed October 26, 2020, entitled "Virtual Subscriber Identification Module and Virtual Smart Card," the present application also having the benefit of the filing date of Prov. US Pat. Note Ser. Serial No. 63/156,226, filed March 3, 2021, entitled "Cloud-Service On-Boarding without Prior Customization of Endpoints", the entire disclosure of which is incorporated herein by reference Registrations is incorporated herein.

The present application is related to US Pat. Note Ser. No. 17/005,565 , filed August 28, 2020, entitled "Secure Memory System Programming for Host Device Verification," which takes advantage of the filing date of Prel. US Pat. Note Ser. No. 63/059,617 , filed 07/31/2020, U.S. Pat. Note Ser. No. 17/080,684 , filed October 26, 2020, entitled "Endpoint Authentication based on Boot-Time Binding of Multiple Components", U.S. Pat. Note Ser. No. 16/374,905, filed April 4, 2019, entitled Onboarding Software on Secure Devices to Generate Device Identities for Authentication with Remote Servers ,” and published as US Pat. Note Pub. No. 2020/0322134 on October 8, 2020, and U.S. Pat. Note Ser. No. 17/014,203 , filed September 8, 2020, entitled Customer-Specific Activation of Functionality in a Semiconductor Device, the entire disclosure of which is hereby incorporated by reference.

TECHNICAL AREA

At least some of the embodiments disclosed herein relate to authentication in general, and particularly but not limited to authentication of a communication endpoint having a secure storage device on a network.

BACKGROUND

A storage subsystem may include one or more storage devices that store data. The storage devices may be, for example, non-volatile storage devices and volatile storage devices. In general, a host system may use a storage subsystem to store data on the storage devices and retrieve data from the storage devices.

Device Identity Composition Engine (DICE) and Robust Internet-of-Things (RIoT) standards have been developed for computing data to identify and authenticate identities of computing devices based on cryptographic computations.

character list

• 1 veranschaulicht ein beispielhaftes Computersystem gemäß einigen Ausführungsformen der vorliegenden Offenbarung.
• 2 veranschaulicht die Erzeugung von Identitätsdaten in einer Speichervorrichtung mit integrierter Schaltung gemäß einer Ausführungsform.
• 3 veranschaulicht eine Technik zum Steuern der Ausführung eines Befehls in einer Speichervorrichtung gemäß einer Ausführungsform.
• 4 veranschaulicht eine Technik zum Überprüfen einer Integrität von in einem Speicher gespeicherten Daten gemäß einer Ausführungsform.
• 5 veranschaulicht Sicherheitsdienste eines Sicherheitsservers, die einem Client-Server basierend auf Sicherheitsmerkmalen bereitgestellt werden, die in einer Speichervorrichtung gemäß einer Ausführungsform implementiert sind.
• 6 zeigt ein System und Verfahren zum Konfigurieren und Authentifizieren eines Endgeräts für einen kartenbasierten Dienst gemäß einer Ausführungsform.
• 7 veranschaulicht ein Kartenprofil einer virtuellen Smartcard gemäß einer Ausführungsform.
• 8 veranschaulicht ein Kartenprofil eines virtuellen Teilnehmeridentifikationsmoduls (Subscriber Identification Module - SIM) gemäß einer Ausführungsform.
• 9 veranschaulicht eine Technik zum Authentifizieren einer Speichervorrichtung gemäß einer Ausführungsform.
• 10 veranschaulicht eine Technik zum Erzeugen eines Befehls zum Steuern von Sicherheitsoperationen einer Speichervorrichtung gemäß einer Ausführungsform.
• 11 zeigt ein Verfahren für eine virtuelle Smartcard gemäß einer Ausführungsform.
• 12 zeigt ein Verfahren für Sicherheitsdienste, die basierend auf Sicherheitsmerkmalen einer Speichervorrichtung gemäß einer Ausführungsform bereitgestellt werden.
• 13 zeigt ein Verfahren zum Onboarding eines Endgeräts für einen Dienst, der gemäß einer Ausführungsform für ein Konto abonniert wurde.
• 14 zeigt eine Technik zur Anpassung von Endgeräten unter Verwendung eines Online-Firmwarespeichers gemäß einer Ausführungsform.
• 15 zeigt eine Technik zur Weiterleitung von Diensten an ein Endgerät über einen Online-Servicespeicher gemäß einer Ausführungsform.
• 16 zeigt ein Verfahren zum Aktualisieren von Firmware unter Verwendung eines Firmware-Speichers und eines Sicherheitsservers gemäß einer Ausführungsform.
• 17 zeigt ein Verfahren zur Anpassung von Endgeräten unter Verwendung eines Servicespeichers und eines Sicherheitsservers gemäß einer Ausführungsform.
• 18 veranschaulicht die Erzeugung von Identitätsdaten zur Erleichterung der Überwachung der Integrität und/oder der Aktivitäten eines Endgeräts gemäß einer Ausführungsform.
• 19 veranschaulicht eine Technik zum Aufrechterhalten der Integrität von Paketen, die auf einem Endgerät gespeichert sind, gemäß einer Ausführungsform.
• 20 zeigt ein System, das Sicherheitsoperationen basierend auf der Verfolgung von Aktivitäten eines Endgeräts gemäß einer Ausführungsform implementiert.
• 21 zeigt ein Verfahren zum Aktualisieren oder Reparieren eines in einem Endgerät gespeicherten Pakets gemäß einer Ausführungsform.
• 22 zeigt ein Verfahren zum Durchführen einer Sicherheitsoperation basierend auf einer oder mehreren Aktivitäten eines Endgeräts gemäß einer Ausführungsform.
• 23 und 24 veranschaulichen Systeme, die konfiguriert sind, die gemeinsame Nutzung von Abonnements durch eine Gruppe von Endgeräten gemäß einer Ausführungsform zu implementieren.
• 25 zeigt ein Verfahren zum Erleichtern der gemeinsamen Nutzung von Abonnements in einer Gruppe von Endgeräten gemäß einer Ausführungsform.
• 26 zeigt Techniken zum Verwalten einer Identifizierung eines Endgeräts gemäß einer Ausführungsform.
• 27 zeigt ein Verfahren zum Verwalten einer Identifizierung eines Endgeräts gemäß einer Ausführungsform.
• 28 ist ein Blockdiagramm eines beispielhaften Computersystems, in dem Ausführungsformen der vorliegenden Offenbarung betrieben werden können.

The embodiments are illustrated by way of non-limiting example in the figures of the accompanying drawings, in which similar references indicate similar elements.

• 1 1 illustrates an exemplary computer system, in accordance with some embodiments of the present disclosure.
• 2 12 illustrates generation of identity data in an integrated circuit memory device according to one embodiment.
• 3 FIG. 11 illustrates a technique for controlling execution of an instruction in a memory device, according to one embodiment.
• 4 12 illustrates a technique for verifying an integrity of data stored in memory, according to one embodiment.
• 5 illustrates security services of a security server provided to a client-server based on security features implemented in a storage device according to an embodiment.
• 6 shows a system and method for configuring and authenticating a terminal device for a card-based service according to an embodiment.
• 7 illustrates a card profile of a virtual smart card according to one embodiment.
• 8th illustrates a card profile of a virtual subscriber identification module (sub scriber Identification Module - SIM) according to one embodiment.
• 9 12 illustrates a technique for authenticating a storage device according to one embodiment.
• 10 11 illustrates a technique for generating a command to control security operations of a memory device, according to one embodiment.
• 11 Figure 12 shows a method for a virtual smart card according to one embodiment.
• 12 12 shows a method for security services provided based on security features of a storage device according to an embodiment.
• 13 FIG. 12 shows a method for onboarding a terminal device to a service that has been subscribed to an account according to an embodiment.
• 14 FIG. 12 shows a technique for adapting terminals using online firmware storage according to an embodiment.
• 15 12 shows a technique for routing services to a terminal via an online service store, according to an embodiment.
• 16 FIG. 12 shows a method for updating firmware using firmware storage and a security server according to one embodiment.
• 17 FIG. 12 shows a method for adapting terminals using a service store and a security server according to an embodiment.
• 18 illustrates the generation of identity data to facilitate monitoring of the integrity and/or activities of a terminal according to one embodiment.
• 19 FIG. 11 illustrates a technique for maintaining the integrity of packets stored on a terminal, according to one embodiment.
• 20 12 shows a system that implements security operations based on tracking activities of a terminal according to an embodiment.
• 21 FIG. 12 shows a method for updating or repairing a package stored in a terminal according to an embodiment.
• 22 FIG. 12 shows a method for performing a security operation based on one or more activities of a terminal according to an embodiment.
• 23 and 24 12 illustrate systems configured to implement subscription sharing among a group of terminals, according to one embodiment.
• 25 FIG. 12 shows a method for facilitating the sharing of subscriptions in a group of terminals according to an embodiment.
• 26 FIG. 12 shows techniques for managing an identification of a terminal according to an embodiment.
• 27 FIG. 12 shows a method for managing an identification of a terminal according to an embodiment.
• 28 1 is a block diagram of an exemplary computer system in which embodiments of the present disclosure may operate.

DETAILED DESCRIPTION

At least some aspects of the present disclosure are directed to a security server and storage devices having security features. The security server is configured to provide online security services on a computer network (e.g. Internet) based on the security features of the storage device. Host systems of the storage devices may use the storage functions of the storage devices to store instructions and/or data for processing and to store processing results.

In general, a memory subsystem may include a memory device and/or a memory module. A host system may use a storage subsystem that includes one or more components, such as storage devices, that store data. The host system can provide data to be stored in the storage subsystem and can request data to be retrieved from the storage subsystem.

For example, some data stored in memory may consist of instructions, such as instructions programmed for software, firmware, a boot loader, an operating system, a routine, a device driver, an application package, and so on. The instructions may be stored for a computing device implemented using a host system to which the storage device is connected.

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

Another portion of the data stored in memory may include results produced from executions of the instructions using the inputs stored in memory and/or other inputs.

Examples of such a computing device include a personal computer, mobile computer, tablet computer, personal media player, smartphone, smart TV, smart speaker, smart device, Internet of Things (IoT) device, etc .

The security features implemented in a storage device can be used to secure communication between the storage device and the security server over a computer network. The communication path between the storage device and the security server may not be secure. The communication between the security server and the storage device enables verification of the identity of the storage device and/or control of access to the storage device in order to prevent and detect counterfeiting, tampering, hacking and/or insecure operations.

The combination of the security features of the storage device and the security services of the security server allows various parties involved in the use of the storage device and/or the computing device with the storage device to have confidence in the authenticity of the computing device and/or the storage device and confidence in the integrity the data stored in the storage device, such as the instructions to be executed in the computing device and the inputs to the instructions.

For example, the security server and storage device may be combined to implement a subscriber identity module (SIM) exchange.

A SIM card is commonly used to represent the identity of a subscriber to a cellular service in a telecommunications network. When a SIM card is inserted into a mobile phone, the mobile phone can access the mobile service provided for a subscriber's account; and when the SIM card is inserted into an alternative mobile phone, the subscriber can access the cellular service associated with the account using the alternative mobile phone.

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

In general, the security server on the Internet can be configured to provide security-related services to third party computers and servers based on the security features built into the storage devices. The security features are embedded and packaged in the storage devices. The security features and the security services can be used without trusting the security implementations of computing devices on which the storage devices are installed. Thus, security implementations can be centralized in the development of the security features in the storage devices and the security server. By simply using the memory devices that have the security features, the security of the computing devices that use the memory devices can be improved without great effort for the developers and/or manufacturers of the computing devices.

The security server may provide services for verifying the identity and/or authenticity of devices, detecting counterfeit and/or tampered devices, tracking and managing ownership of devices, facilitating transfer of ownership/control of devices, facilitating configuration of Provide computing devices for accessing services from third party servers and/or networks, etc.

Security features of a memory device may be implemented in an integrated circuit (IC) package of the memory device during manufacture of the memory device. The memory device may include logic circuitry (or controller) and memory cells formed on one or more integrated circuit chips. At least some of the memory cells of the storage device may be non-volatile, such that data may be retained in the non-volatile memory cells even if the storage device is used for an extended period of time (e.g., days, months, or even years) is not powered. The non-volatile memory of the storage device can be used to store instructions and data for the operations of a host system of the storage cell.

The storage device may have a unique device secret (UDS). The device unique key may be secured in the storage device such that upon completion of manufacture of the storage device, the device unique key is not communicated outside of the storage device and cannot be read by a host system via an interface of the storage device.

The presence of the storage device's unique device key may be verified by the security server through cryptographic calculations, such as generating cryptographic keys, hashing a message using a cryptographic function, and generating ciphertext of a message by encrypting the message with a cryptographic key.

The cryptographic computation to encrypt a message using a cryptographic key involves the computation of a ciphertext to represent the message. The message can be efficiently recovered from the ciphertext using a corresponding cryptographic key by performing a predefined decryption calculation. Without the appropriate cryptographic key for decryption, it is generally not possible to recover the message from the ciphertext. The level of difficulty in recovering the message without knowing the corresponding cryptographic key for decryption represents the security level of the encryption calculation. The security level generally depends on the length of the cryptographic key used in encryption and the algorithm used.

When symmetric cryptography is used, the cryptographic key for decryption and the cryptographic key for encryption are identical. When using asymmetric cryptography, the decryption key and the encryption key are different and are generated as a pair. One of the pair can be used as a private key and thus as a secret code; the other of the pair can be used as a public key. In general, it is impractical to compute the private key from the public key. The level of difficulty in recovering the private key from the public key represents the security level of asymmetric cryptography.

The cryptographic computation to hash a message associates the message with a hash value to represent the message. However, a lot of information is lost when calculating the hash value, so the message cannot be reconstructed from the hash value. Many messages can be mapped to the same hash value. In general, it is impractical to create a modified version of the message that can be hashed with the same value, especially when the modified version is similar to the original message.

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

In general, any technique of cryptographic computations for encryption, hashing, and key generation can be used with the storage device and security server. Thus, the present disclosure is not limited to any particular encryption, hashing, and/or key generation technique.

Besides the storage device's unique secret code, the memory may store additional data representing the data and/or hardware configuration of the storage device and/or the computing device in which the storage device is installed. A part of the additional data can be kept as a secret code in the storage device, but not necessarily. The unique secret code and the additional data can be used to generate a secret cryptographic key to represent the identity of the storage device and/or the computing device.

The logic circuitry (or local controller) of the storage device may implement a cryptographic engine, an identity engine, and access control. The cryptographic Storage device engine is configured to perform cryptographic computations (e.g., hashing, encryption/decryption, key generation) within the storage device to support identity engine and access control operations. The implementation of the cryptographic engine in the storage device avoids the need to rely on an external processor for security calculations of the storage devices and thus improves security by preventing the transfer of secrets outside of the storage device and by preventing tampering and hacking of cryptographic calculations. Optionally, at least part of the cryptographic computations involved in the security features of the storage device may be implemented by storing instructions in the storage device for execution by the storage device's host system, where there is a compromise between the level of security and the complexity of the logic circuitry ( or local control) of the storage device.

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

The storage device access controller is configured to control the execution of commands received at the storage device using cryptographic keys. For example, privileges may be required to request the storage device to execute commands to read, write, erase, modify, etc., various portions of the storage device's non-volatile memory. The rights can be represented by corresponding cryptographic keys. Upon receiving a privileged command at the storage device for execution, the access controller may perform a calculation using the cryptographic engine to determine whether the command originated from a sender who has a cryptographic key representing the rights. The access control enables the command to be executed in the storage device after the calculation has shown that the sender has the cryptographic key and therefore the right to do so. Otherwise, access control can reject, ignore, or discard the command. Such access control may prevent unauthorized access to the data stored in the storage device, prevent unauthorized modifications to the storage device, and prevent tampering and/or hacking intended to create counterfeits of the storage device and/or insecure devices.

In general, verifying that a sender of a message has a cryptographic key involves verifying a verification code of the message. The verification code may be in the form of a hash digest, a digital signature, a hash-based message authentication code (HMAC), a cipher-based message authentication code (CMAC), and so on. The verification code is generated using the cryptographic key and the message as input for cryptographic operations such as hashing, encrypting and/or other computations, so it is generally impractical to generate the verification code without the cryptographic key and to extract the verification code from a modified version of the generate message. Thus, by confirming that the received verification code is valid for the received message and a cryptographic key, the recipient can conclude that the sender has the corresponding cryptographic key and that the received message matches the message used to generate the received cryptographic key key was used.

In some implementations, the recipient performs verification of a message's verification code using the same cryptographic key that the sender used to generate the verification code. For example, the recipient uses the same cryptographic key to generate the verification code of the received message and to compare 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 cryptographic key. Otherwise, the received verification code for the received message is invalid; either the received message has been altered since the verification code was generated, or the received verification code was generated using a different cryptographic key, or both.

In some implementations, the recipient performs verification code verification of a message using a public cryptographic key in a key pair; and the sender generates the verification code using a private cryptographic key in the key pair. For example, the verification code can be generated by applying a hash function to the message to generate a hash value of the message. The ciphertext of the hash value obtained by encrypting the hash value performed using an encryption key can be used as the verification key. A recipient of the message and verification code performs the verification using a corresponding decryption key, which is identical to the encryption key when using symmetric cryptography and a different key in a key pair when using asymmetric cryptography. After reconstructing a hash value from the ciphertext using the decryption key, the reconstructed hash value can be compared to the hash value of the received message; if there is a match, the received verification code is valid for the received message; otherwise the received verification code for the received message is invalid. Alternatively, the recipient can use the encryption key to perform verification without performing decryption. The recipient can generate the verification code of the message by using the encryption key to compare it with the received verification code.

In some implementations, a message and a cryptographic key are combined to generate a hash value as a verification code, as in a hash-based message authentication code (HMAC) technique. For example, one cryptographic key can be used to generate two keys. After combining one of the two keys with the message to produce a key-modified message, a cryptographic hash function may be applied to the key-modified message to produce a hash value that is further combined with the other key to create another message. After applying the cryptographic hash function (or another cryptographic hash function) to the further message, a hash-based message authentication code is generated. A recipient of the message can use the same cryptographic key to generate the hash-based message authentication code of the received message for comparison to the received hash-based message authentication code. If there is a match, the verification is successful; otherwise the verification fails.

In general, any technique for generating and checking a verification code for a message from a sender and a cryptographic key that the sender uses to generate the verification code can be used to determine whether the sender possesses the cryptographic key. The recipient uses an appropriate cryptographic key to perform the verification, which may be the same as the cryptographic key used to generate the verification code, or the same pair of asymmetric cryptographic keys. Thus, the present disclosure is not limited to any particular hash digest, digital signature, and/or hash-based message authentication code technique.

For convenience, a verification code generated for a message using a cryptographic key to represent both the message and the cryptographic key can generally be referred to as a digital signature of the message signed with the cryptographic key, so the verification code can be verified using various techniques can be generated, for example with a hash-based message authentication code.

The storage device may be configured to store relevant cryptographic keys for checking verification codes signed with cryptographic keys configured to represent the requirements for executing the instructions in the storage device.

For example, access control can provide a set of privileges for an owner of the storage device, such that the owner can enable or disable one or more security features of the storage device, change one or more security settings, parameters, configurations, or preferences of the storage device, and/or data from a portion of the storage device can read that cannot be read by other users of the storage device.

For example, access control may grant authorized users of the storage device specific read, write, Provide deletion or modification of specific sections of the storage device.

When the storage device receives a command that requires an access right to execute, the access controller can retrieve a corresponding cryptographic key to verify a verification code or digital signature for a message containing the command. If the verification code received for the received command is checked successfully, the received command is considered to have come from a sender who possesses the cryptographic key representing the authorizations to execute the command in a storage device. In response, the access control allows the command to be executed in the memory device. Otherwise, access control blocks execution of the command.

The storage device can be made to be initially owned by the security server. Thereafter, the security server may provide and/or transfer some or all permissions to one or more owners and users in a process beginning with the placement of the storage device in a computing device to the computing device having the storage device used by an end user. Access control can prevent tampering, hacking, and unauthorized access while providing the flexibility to support different patterns of transferring permissions to different owners and users, such as: B. a manufacturer of a component of a computing device in which the storage device is installed, a manufacturer of a computing device in which the component of the computing device is installed, a retailer, an enterprise user, an end user and an alternative end user, etc.

The identity engine of the storage device is configured to generate data indicative of the identity of the storage device and/or the identity of the computing device on which the storage device is installed. To generate the identity data, the identity engine uses the cryptographic engine to generate a secret cryptographic key from the device unique key and other data stored on and/or collected by the storage device (e.g., during the boot process the computing device). The presence of the cryptographic secret key in the storage device may be taken as evidence that the storage device is in possession of the device's unique device key and the other data used to generate the cryptographic secret key. The presence of the secret cryptographic key in the storage device can be checked by the security server based on a verification code or a digital signature using the secret cryptographic key.

During manufacture of the storage device, a copy of the device's unique secret code is registered in the security server and/or passed securely and without detection. The security server is then configured to derive the same secret cryptographic key (and/or a corresponding public key if asymmetric cryptography is used) independently of the storage device without the storage device communicating its unique secret outside of the storage device. Thus, the security server can verify that the storage device has the unique device key by verifying that the storage device has the secret cryptographic key; and the cryptographic secret as the identity of the storage device may change during processing of the storage device integrated into a component, device, system and transmitted between manufacturers, retailers, distributors, companies and/or end users. Without changing the device unique key, the entity of the storage device as represented by a secret cryptographic key can be updated to represent the storage device as assembled into a component, device, system, customized and/or is personalized and/or owned and/or operated by different entities or users.

Cryptographic operations and communications may be performed to allow the security server to verify that the storage device has the secret cryptographic key.

For example, the identification data available for verification from the storage device may include a message indicating a public identification of the storage device. The public identifier can be used to distinguish the storage device from other storage devices. The identity data may include a verification code or a digital signature of a message in the identity data signed using the secret cryptographic key. The identity data includes a copy of the message and the verification code or digital signature. Once the verification code and the message data have been checked by the security server, the security server can conclude that the public identification provided in the identification data is authentic and the identification data originated from the storage device holding the secret cryptographic key.

The storage device cryptographic secret may be generated not only using the storage device's unique device key, but also using additional data representative of some aspect of the storage device and/or the computing device on which the storage device is installed. The additional data may be representative of software, firmware, boot loader, applications, trace data stored in the storage device, identifiers of components of the computing device residing in the computing device at a particular time of the last boot of the computing device. If the additional data has been modified, the identity engine generates a modified secret cryptographic key. Consequently, the verification code generated using the changed cryptographic secret fails the check performed on the security server. Thus, by checking the verification code generated by the identity engine, the integrity and authenticity of the hardware/software/data composition of the storage device and the computing device in which the storage device is installed is also verified.

Verifying the identity of the storage device and/or the host system can detect counterfeit, tampered with, and stolen/lost devices. Based on an owner's request, the security server can configure a stolen/lost storage device to operate in one of several degraded modes, e.g. unbootable, unreadable, encryption/erasure of data in the non-volatile memory, self-destruct of the storage functionality of the storage device etc.

The security server is configured with a database of information for verifying identity data generated in the identity engines of storage devices. The database enables the security server to generate the corresponding secret cryptographic keys (and/or the corresponding public keys if asymmetric cryptography is used) in the storage devices. The cryptographic keys can be generated by the security server without the storage devices communicating their unique secret codes outside of the storage devices after the storage devices are manufactured. The cryptographic keys may be generated based at least in part on the additional data available after the storage devices are manufactured.

The security server may store a cryptographic key representing the privileges of the owner of a storage device. Using the cryptographic key, the security server can generate commands to transfer ownership of the storage device and configure and/or transfer selected permissions to execute selected commands on the storage device. After a computing device has been reported as lost/stolen, the security server can detect the use of its storage device during verification of the storage device in connection with a service request from a third-party server.

For example, when the third party server receives a service request from a computing device with the storage device, it forwards the identity data generated by the storage device from the computing device to the security server for verification. If the identity information is verified by the security server, the third party server may provide services to the computing device; otherwise, the request can be denied, discarded, or ignored.

Upon request by an authorized party, the security server can sign commands or generate verification codes for the commands to grant or revoke access to the non-volatile memory in the storage device. The authorized party can forward the signed instructions to the storage device for execution. A signed command includes a message that includes the command and a verification code for the message that was signed/generated using a cryptographic key that represents the permissions to execute the command on the storage device.

The storage device may be installed in a computing device as part of the identity of the computing device and to provide main storage capacity for the computing device. For example, the instructions to be executed in the computing device and the associated data can be stored in the memory device and can have security features in the memory tampering, manipulation and/or hacking. Since the identity data generated by the identity engine of the storage device is based at least in part on the instructions/data stored in the storage device, the integrity and/or authenticity of the instructions and data to be used by the storage device is verified at least during the process of verifying the identity of the storage device and/or the computing device is checked.

The security services provided by the security server offload third party servers from securing operations and computing devices. Unauthorized access can be prevented without great effort by the manufacturers of the computing devices and the operators of the third-party servers by using the storage devices and the services of the security server. Thus, third party servers can operate their core competencies in providing their respective services without compromising security.

The services provided by the security server can be used by a third party to provide its subscribers with their services without the subscribers having to perform manual operations to configure the computing devices used by the subscribers. For example, a subscriber may use a computing device to access the subscribed wireless service in the subscriber's account without having to insert a physical SIM card into the computing device and/or perform other operations to customize the computing device for access using the subscriber's account .

Participants can be represented by identifiers of accounts. When a participant purchases a computing device, ownership of the computing device may be transferred to the participant via the security server. The security features of the storage device configured in the computing device can be used to generate a device identity. When the computing device is connected to a third party server for services, the third party server requests the security server to verify the device identity. Based on the ownership of the computing device and the ownership of the account, the computing device may be dynamically associated with the account to allow the computing device to access services provided by a third party using the account without requiring manual operations to configure the computing device are.

For example, during the verification of the identity of the computing device, the owner/subscriber of the computing device is identified by the security server's owner management service. Once the owner/participant is identified, the identification of the participant can be integrated into the device identity of the computing device or mapped to the device identity in the database of the security server. Thereafter, when the device identity is verified, the services in the subscriber's account can be provided by the third party to the computing device without the subscriber having to explicitly direct/request the services to the computing device.

Optionally, the computing device may establish separate credentials with the third party server so that the third party server does not need to contact the secure server each time the computing device connects to the third party server to consume services.

1 1 illustrates an exemplary computer system, in accordance with some embodiments of the present disclosure.

In 1 For example, an integrated circuit memory device 130 includes security features as discussed above.

The secure storage device 130 can store a unique device key 101 for its authentication. In one example, the unique device key 101 is injected into the storage device 130 in a secure facility and stored in a register of the storage device 130 . In another example, the device unique key 101 may be obtained from a physically unclonable function (PUF) of the storage device 130 . The device unique key 101 can be obtained and registered in the security server 140 via the secure facility. For example, the security device may be part of a memory device manufacturing facility (e.g., 130). After the storage device 130 is manufactured and/or left the secure facility, the device unique key 101 is no longer accessible through an interface (e.g., the host interface 147) in the storage device 130 . Thus, after the memory device 130 is manufactured, the unique device key 101 is sealed as that in the memory device 130 in the memory integrated circuit device 130 . A copy of the unique device key 101 is kept within the security server 140 with strong security measures (e.g. use of a hardware Security Module (HSM)) to prevent hacking and unauthorized access.

The storage device 130 includes a logic circuit or local controller that implements a cryptographic engine 107 . The cryptographic engine 107 can perform cryptographic calculations such as B. hashing, key derivation, encryption and / or decryption, without affecting the processing power external to the storage device 130, such. a computing device 118 of a host system 120 to be instructed.

For example, according to a method specified by the Device Identity Composition Engine (DICE) and Robust Internet-of-Things (RIoT) standards or another method, cryptographic keys 105 can be generated at boot based on a combination of the unique device key 101 and the one in the memory cells 103 of the storage device 130 stored and/or received device information 121 can be generated. Device information 121 may include non-secret data that can be obtained from outside of security server 140 and storage device 130 . To improve security, device information 121 may also include time-related information.

For example, cryptographic keys 105 may include two pairs of asymmetric cryptographic keys. A first pair of asymmetric keys is referred to as a device identification key; a second pair of asymmetric keys are called alias keys. The private device identification key is used to certify the authenticity of the alias keys, thus reducing its use and the risks associated with it. The alias keys can be used in more transactions/communications and the alias keys can be replaced more frequently than the device identification keys to improve security considering their more frequent use and thus risk. For example, the device private identification key may be generated at some point in time and used to sign certificates, such as an alias public key certificate; then the private device identification key is immediately erased from the storage device 130 to ensure its confidentiality.

In general, one of the cryptographic keys 105 generated using the device unique key 101 and the device information 121 can be used as the secret code and identity of the storage device 130 to be verified by the security server 140.

The authentication of the storage device 130 can be carried out, for example, by checking whether the storage device 130 has the secret cryptographic key 105 . The secret cryptographic key 105 in the storage device 130 can be taken as proof that the storage device 130 has the unique device key 101 and stores an untampered version of the non-secret data.

Using the cryptographic key 107 , the storage device 130 can prove that the storage device 130 has the secret cryptographic key 105 without communicating the secret cryptographic key 105 and/or the device unique key 101 outside of the storage device 130 . For example, the storage device 130 may digitally sign a certificate or a message using the cryptographic secret key 105 to provide a verification code of the message and the cryptographic secret key 105 . If the security server 140 has successfully checked the verification code, the security server 140 can conclude that the storage device 130 has the secret cryptographic key 105 and thus the identity represented by the unique device key 101 .

The storage device 130 includes a host interface 147 that can be used to receive commands in a host system 120 . A controller 116 of the host system can send commands to the memory device 130 to read data from the memory cells 103, write data to the memory cells 103, erase data in a portion of the memory cells 103, change data in a portion of the memory cells 103, activation of a security feature of the memory device 130, configuration of parameters relevant to a security feature in the memory device 130, etc. At least some of the commands require authorization through a cryptographic key 106 stored in the security server 140. Having the cryptographic key 106 to sign the command is considered an indication of having authority to request the storage device 130 to execute the command.

The storage device 130 includes an access controller 109 configured to use the cryptographic engine 107 to verify a verification code generated using a cryptographic key 106 representing the authorization associated with the command. If a command with a valid verification code is received, access controller 109 allows storage device 130 to execute the command; otherwise the command can be rejected, ignored or discarded.

When the storage device 130 is manufactured, one or more relevant cryptographic keys 105 are stored in the storage device 130 to provide the owner's credentials to the security server 140 . Using the owner credentials, the security server 140 can sign instructions for execution on the storage device 130 to enable or disable security features, to trigger the replacement of a secret cryptographic key as the identity of the storage device 130, to replace a cryptographic key used by the access control 109 is used to check permissions, to execute one or more instructions in the memory device 130 for one or more areas of the memory cells 103, etc.

Optionally, after authenticating the identity of an authorized requestor, the security server 140 can sign a command using a cryptographic key to generate a verification code or digital signature for the command so that the requestor can transmit the command with the verification code to the host interface 147 of the Storage device 130 may send to cause the command to be executed in storage device 130.

Optionally, the security server 140 can provide certain permissions to an entity by replacing a cryptographic key 105 in the storage device 130 or providing the entity with a corresponding cryptographic key 106 representing the permissions.

Typically, the storage device 130 is connected to a host system 120 to form a terminal 150 in a communications network 110, such as the Internet. In general, terminal 150 is a computing device. Examples of the terminal device 150 include a personal computer, a mobile computer, a personal media player, a tablet computer, a smartphone, a smart TV, a smart speaker, a smart device, an IoT (Internet of Things) device, etc .

The memory cells 103 of the storage device 130 may provide the storage/memory capacity for the host system 120 to store instructions and data for the implementation of the terminal 150 functionality. For example, processing device 118 of host system 120 is configured to execute instructions loaded from storage device 130 for booting and performing operations.

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

A request for services sent from terminal 150 to client-server 141 may include identity data generated by cryptographic engine 107 of storage device 130 . The client-server 141 can request the security server 140 to check the verification code contained in the identity data.

In addition to services for authenticating the identity of storage device 130, security server 140 may provide security services for managing permissions to operate storage device 130, configuring or changing security features or settings of storage device 130, detecting lost/stolen devices, disabling lost/ stolen devices etc. offer.

The storage device 130 and/or the terminal device 150 can have a unique identification 111 that is not secret. Unique identifier 111 may be used to uniquely identify storage device 130 and/or endpoint 150 in a population of storage devices and/or endpoints.

For example, the unique identifier 111 of the storage device 130 may include a manufacturer's number (MPN) of the storage device 130 and/or a serial number of the storage device 130 . For example, the unique identifier 111 of the storage device 130 may include a public key in a pair of asymmetric cryptographic keys that are generated based at least in part on the device unique key.

To authenticate that the storage device 130 and/or the terminal 150 has the identity represented by the unique identifier 111, the security server verifies 140 a message containing the unique identifier 111 (and other data 127) via a verification code of the message signed using a secret cryptographic key 105 of the storage device. The secret cryptographic key 105 in the storage device 130 is generated using the unique device key 101 in the storage device 130; and the corresponding cryptographic key 106 used to check a verification code signed with the secret cryptographic key 105 of the storage device 130 is generated in the security server 140 from the corresponding device unique key 101 .

The secret cryptographic key 105 of the storage device 130, which is used to prove the device identity of the storage device 130, can be generated based not only on the unique device key 101, but also on the device information 121 accessible to the storage device 130.

Device information 121 may include, for example, a hash value of instructions and/or data stored in memory cells 103 . Furthermore, the device information 121 may include trace data stored in the memory cells 103 in order to personalize/individualize the memory device 130 and/or the terminal device 150 during the arrangement of the components to build the terminal device 150 . Furthermore, the device information 121 may include identification information of other components in the terminal device 150, such as e.g. B. an identification of the controller 116, an identification of the processing device 118, an identification of the network interface 114, an identification of additional software or data packets of the terminal device 150 that are not stored in the storage device 130, and / or an identification and / or a Hash value of the firmware configured to control/operate the storage device 130. During the boot process, the identification data can be collected as device information 121 that is used to generate the secret cryptographic key 105 in the storage device 130 .

In a registration process, when the storage device 130 is configured to have the device information 121, a copy of the device information 121 is uploaded to the security server 140 to associate it with the unique identifier 111 of the storage device 130 and/or the terminal 150. By registering the device information 121, the identity of the storage device 130 can be linked to the data, software, and/or hardware configuration represented by the combination of the unique device key 101 and the device information 121.

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

In 2 the cryptographic engine 107 of a storage device 130 (e.g. as in 1 ) is used to generate at least one cryptographic key 137 using its unique device key 101 and device information 121.

For example, when using asymmetric cryptography, the secret key 137 is a private key of a cryptographic key pair 135. An associated public key 139 is generated using the cryptographic engine 107 along with the private key.

Alternatively, if symmetric cryptography is used, the secret key 137 can be generated and used without a public key 139 and without the key pair 135.

In some implementations, multiple key pairs 135 are generated and used. For example, when using a Device Identity Composition Engine (DICE) and Robust Internet-of-Things (RIoT) technique, a first pair of asymmetric keys is called a device identification key and a second pair of asymmetric keys is called an alias key. The private device identification key can be used to certify the authenticity of the alias keys and then immediately deleted and sanitized from the storage device 130 and/or the terminal 150 to ensure its confidentiality, particularly when generating or using the private Device identification key takes place at least in part in the host system 120. The alias keys can be used for authentication in further transactions and/or communications. For example, the private device identification key may be generated at some point in time and used to sign certificates, such as an alias public key certificate, and is then deleted. After the identity of the storage device 130 and the authentication of the alias public key using the certificates signed with the private device identification key as the secret key 137 verified or confirmed, the alias private key can be used as the secret key 137 of the storage device 130 in subsequent operations until the terminal 150 reboots.

The data 123 stored in the memory cells 103 for the device information 121 can include, for example, an instruction set (e.g. software, firmware, operating system, application) that is executed by the processing device 118 of the host system 120 with which the host interface 147 of the Storage device 130 is connected to be executed.

The data 123 may include, for example, a cryptographic hash of the instruction set. For example, a known hash value of the instruction set may be stored in memory cells 103; and the current hash value of the instruction set can be calculated for comparison to the known hash value. If the two hashes match, the integrity of the instruction set is checked and the hash of the integrity of the instruction set can be used as part of the device information 121 to calculate the secret key 137 .

Alternatively, the current hash value of the instruction set stored in the memory cells 103 can be used directly for the calculation of the secret key 137. If the instructions contain changes (e.g., due to data corruption and/or tampering or hacking), verification of the secret key 137 by the security server 140 will fail.

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

Optionally, the data 123 may include trace data stored in the memory cells 103 during the process of building and/or customizing the terminal 150 that includes the memory device 130 . For example, when storage device 130 is incorporated into a component device (e.g., a storage subsystem), a portion of trace data representing the manufacturer of the component device, the model of the component device, and/or the serial number of the component device is written to the Memory cells 103 stored as part of the device information 121. Subsequently, when the component device is built into the terminal device 150, part of the trace data is added into the memory cells as part of the device information 121. FIG. Furthermore, trace data may be added into the memory cells 103 as part of the device information 121 to reflect the history of the memory device 130 for individualizing the identity of the memory device 130 .

Optionally, the device information 121 may further include data 125 received at the host system 120 to which the host interface 147 of the storage device 130 is connected.

The terminal 150 may include the host system 120 and the storage device 130, for example. Some of the host system 120 components may be removed or replaced. At terminal 150 power-up, a portion of the instructions stored in memory cell 103 are executed to collect data 125 about the components present in host system 120 at the time of power-up. Thus, device information 121 may represent a particular configuration of software/data and hardware combinations of storage device 130 and/or terminal 150 . The secret key 137, which is generated based on the device information 121 and the unique device key 101, represents the identity of the storage device 130 with the respective configuration.

In order to represent the identity of the storage device 130 and/or the terminal device 150, the cryptography engine 107 generates a verification code 133 from a message 131 and the secret key 137.

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

Optionally, message 131 may include user identification, such as a name, email address, registered username, or other identifier of an owner or authorized user of terminal 150 in which identity data 113 is generated.

Optionally, a portion of message 131 may provide information in encrypted form. For example, the information can be encrypted with a public key of the security server 140 so that a third party cannot access the information.

The message 131 can be a certificate in which the unique identification 111 of the storage device 130 and/or the end device 150 is present. The message 131 can also contain other data 127, for example a counter value maintained in the storage device 130, a cryptographic nonce and/or other information relating to the verification of the identity data 113. The storage device 130 may monotonically increase the counter value to invalidate identity data having lower portions to prevent replay attacks.

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

In some implementations, secret key 137 is an alias private key in an asymmetric key pair. The data 127 contain a certificate in which the corresponding public alias key of the asymmetric key pair is present. The certificate representing the alias public key is signed using a device identification key of the storage device 130 . The alias public key can be used to verify the verification code 133 for the message 131 and the alias private key used as the secret key 137 . Once the security server 140 has verified the certificate representing the alias public key signed using the device identification key of the storage device 130 and provided as part of the data 127, the security server 140 can use the alias public key to verify the verification code 133 which was signed as secret key 137 using the alias private key. In such an implementation, security server 140 may use the alias public key provided in message 131 to verify verification code 133 without regenerating the alias key pair; and storage 130 may generate alias key pair 135 using data unknown to security server 140 .

The certificate representing the public alias key can be used as in 2 generated and verified, where the secret key 137 is the device identification key generated using the device information 121 and the device unique key 101 . Optionally, the storage device 130 first provides the security server 140 with the certificate comprising the alias public key. Then, the storage device 130 can use the alias private key as the secret key 137 without including the alias public key in the message 131 or without including the certificate of the alias public key 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 induce the storage device 130 to demonstrate that it is in possession of a secret key 137, a random piece of data may be represented as part of the data 127 to be signed using the secret key 137. In some implementations, a monotonically increasing counter value can be used as a challenge.

Further, verifying the identity of storage device 130 may include using multiple secret keys and verification codes signed using the secret keys. For example, a device identification secret may be used to first establish authentication of an alias secret and the identity of storage device 130; and then the alias secret key can be used to verify the authentication of the storage device 130 identity. In general, since the security server 140 can generate the corresponding cryptographic keys with the storage device 130, the device identification secret and the alias secret key can be based on asymmetric cryptography or symmetric cryptography.

To enhance security, storage device 130 does not use processing power external to storage device 130 to generate its copy of secret key 137, and does not communicate secret key 137 external to storage device 130. The generation and use of cryptographic key 137 is accomplished using logic circuitry performed by the cryptographic engine 107 sealed in the storage device 130.

Alternatively, part of the operations for generating and using the secret key 137 can be performed via an instruction set stored in the memory cells 103 and incorporated into the processing device 118 of host system 120 is loaded for execution. To improve security, the secret key 137 is not communicated over the host interface 147 in the clear; and the instructions may be configured to delete the secret key 137 from the host system 120 after it is generated and/or after it is used.

The identity data 113 may be generated in response to the storage device 130 being powered on, in response to a request received in the host interface 147, and/or in response to the terminal device 150 being powered up (e.g. by executing an in the memory cells 103 saved boot loader). Data 127 may include a count maintained in storage device 130 . The count increases when the operation for generating the identity data 113 is performed. Thus, a version of the identity data 113 has a count that invalidates previous versions of the identity data 113 that have counts less than the count.

3 FIG. 11 illustrates a technique for controlling execution of an instruction in a memory device, according to one embodiment. The technique of 3 can, for example, in the computer system of 1 be implemented and used with the technique of 2 .

In 3 When the controller 116 of the host system 120 sends a command 155 to the host interface 147 of the storage device 130, the access controller 109 determines whether the sender of the command 155 has permission to request the storage device 130 to execute the command 155.

A cryptographic key 145 is configured to represent the credential. A sender of the command 155 can generate a verification code 153 from the cryptographic key 145 and a message 151 containing the command 155 .

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

The access controller 109 uses a corresponding access control key 149 to verify the verification code 153 transmitted to the host interface 147 for the command 155. The access controller 109 uses the cryptographic engine 107 to generate a verification result 159 of the received message 151 and the received verification code 153 . Based on the validation result 159, the access controller 109 can selectively allow the execution of the instruction 155 in the storage device 130 or block the execution of the instruction 155.

The access control key 149 can be one of the cryptographic keys 105 stored in the storage device 130, for example. Different access control keys can be used to control different permissions to execute different commands and/or to execute a command operating on different portions of memory cells 103 .

For example, the cryptographic key 145 may be stored in the security server 140 to provide the associated credential to the security server 140 .

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

Optionally, cryptographic key 145 is generated upon verification of identity data 113 created using secret key 137; and a secret code (e.g. secret key 137) known between the storage device 130 and the security server 140 enables a session key to be generated as a cryptographic key 145 in order to authorize the execution of selected commands in the storage device 130 during a communication session presented with a time limit. Optionally, the amount of time the device is powered on can be used as a session delimiter so that on the next power-on a new count is generated to cause a new session key to be generated.

The cryptographic key 145 can be configured to be valid for a short time after verification of the identity data 113 and establishment of the session key. After the security server 140 has verified that the entity is authorized to execute the command 155 in the storage device 130, the security server 140 may generate the verification code 153 gen and provide it to the entity. The entity can then send message 151 and verification code 153 to host interface 147 . Once the access controller 109 of the storage device 130 determines that the verification code 153 is valid using the cryptographic key 107 and the access control key 149, the validation result 159 allows the storage device 130 to execute the received command 155; otherwise, access control 109 may reject or ignore received command 155.

In another embodiment, the security server 140, after configuring the access control key 149 in the storage device 130, may provide the entity with the cryptographic key 145 representing authorization to execute the command 155 in the storage device 130.

Message 151 may include data 157 representing constraints on the request to execute command 155 .

For example, data value 157 may include an execution count value that is maintained in storage device 130 such that verification codes generated for lower counts are invalid.

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

The data 157 can include, for example, a time window in which the verification code 153 is checked.

The data 157 can include, for example, the identification of a memory area in which the instruction 155 is permitted to be executed.

Data 157 may include, for example, any type of operations allowed for execution of instruction 155 in storage device 130 .

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

In 4 the storage device 130 not only stores the content 161 in the storage cells 103, but also a hash value 163 of the content 161. In order to determine the integrity status 165 of the content 161, the cryptographic engine 107 applies a cryptographic hash function to the content 161 to generate the current hash value of the content 161; and the cryptographic engine 107 compares the current hash value and the stored hash value 163 to determine if they are equal. If so, the integrity of the content 161 is confirmed according to the stored hash value 163

The hash value 163 may be stored as part of the device information 121 used to generate the secret key 137 for verifying the identity of the storage device 130 .

The content 161 and the hash value 163 are stored in different sections of the storage device 130 . The access controller 109 provides and/or enforces various levels of authorization for access to the content 161 and the hash value 163 .

For example, a manufacturer of the terminal 150 may store the content 161 in the memory cells 103 so that the processing device 118 of the host system 120 in the terminal 150 may execute a program or routine in the content 161 to provide a developed terminal 150 function. Furthermore, the manufacturer and/or the security server 140 can store the hash value 163 in a separate section for integrity checking. An end user of the terminal 150 can access and use the content 161 in the memory cells, but cannot access the hash value 163. If the Content 161 is corrupted or tampered with, the cryptographic engine 107 can detect the change and generate an integrity status 165 to cause the access controller 109 to prevent the Content 161 from being used. If the manufacturer has an updated version of the content 161 (or a replacement), he can perform the update in the memory cells 103 and issue a command 155 with a verification code 153 to update the hash value 163 . Optionally, the security server 140 can generate the verification code 153 in response to a request from the manufacturer.

The device information 121 and the cryptographic keys 105 in the storage device 130 can be stored in a secured area in the storage device 130 and protected via the access controller 109 by permissions of the owner, which are granted by an in cryptographic key 106 stored on the security server 140.

Different secrets (e.g., device unique keys 101, secrets 137) and content (e.g., device information 121, content 161) can be protected at different security levels and/or with different security strategies to balance security and utility.

The device unique key 101 can be protected in the storage device 130 in the highest security level. For example, once storage device 130 exits a secure storage device manufacturing facility and/or upon completion of operations to manufacture storage device 130, unique device key 101 is no longer accessible via a command to host interface 147 (and/or any interface of storage device 130 ) changeable. Preferably, the unique device key 101 is only accessible to the cryptographic engine 107 during generation of the secret keys (e.g., 137) used to represent the identity of the storage device 130 and/or the terminal 150. For example, the unique device key 101 can be configured such that it is only available for a limited time when the terminal device 150 boots up.

For example, a device identification key can be secured by keeping its use to a minimum. An alias identification key can be better secured if it is replaced more frequently than the device identification key. Different operations and/or permissions can be used to replace the device identification key and the alias identification key.

5 illustrates security services of a security server provided to a client-server based on security features implemented in a storage device according to an embodiment.

For example, the in 5 illustrated security services in the computer system of 1 based on the in the 2 , 3 , and/or 4 illustrated security features are implemented.

In 5 a client-server 141 is configured to provide services to computing devices such as B. a terminal 150 having a storage device 130 connected to a host system 120, as in FIG 1 .

To request a service from client-server 141 , host system 120 requests (e.g., executes instructions retrieved from storage device 130 ) identity data 113 on storage device 130 . The identity data 113 can be generated, for example, in a manner as illustrated in FIG 2 .

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

In order to determine whether the terminal 150 is entitled to services, the client-server 141 extracts the identity data 113 from the request 171 and generates a request 173 for the security server 140 to provide security services based on the identity data 113 .

The security server 140 can perform a verification of the identity data 113, determine whether the authenticity of the storage device 130 and/or the terminal 150 is given, and provide a result in the response 174 to the client-server 141. Based on the result, the client-server 141 can provide a response 172 to the host system 120 .

Response 174 can indicate, for example, whether the identity data 113 originates from a counterfeit device or from a device in which the data 123 or the content 161 relevant to the identity of the end device 150 and/or the storage device 130 has changed , has been tampered with or tampered with, or if the device is lost or stolen.

In some implementations, request 173 may identify an instruction 155 to be executed on storage device 130 . After verifying the identity data 113 and verifying the authorization of the client-server 141 and/or the terminal 150 to request the command 155 to be executed in the storage device 130, the security server 140 can generate a verification code 153 for the command 155 using the cryptographic key 145 and provide verification code 153 in response 174 to client-server 141. Using the security service, the client-server 141 can be relieved of the security burdens associated with managing the credentials and the cryptographic key 145 representing the credentials.

Optionally, response 174 may include cryptographic key 145 having permissions to execute command 155 on storage device 130 . For reduced security burdens on the client-server 141 the cryptographic key 145 may be configured to expire in a short period of time.

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

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

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

For example, the command 155 may cause the access controller 109 to request permissions in the form of a new cryptographic key 106 stored in the security server 140 in order to access one or more portions of the storage cells 103 .

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

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

The instructions retrieved from memory cells 103 for execution in host system 120 may include a routine that accepts command 155 in response to identity data 113 being provided to storage device 130 . In some implementations, client-server 141 may provide a connection that enables security server 140 to send command 155 to storage device 130 for execution.

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

For example, a storage device 130 may be configured to generate in the terminal 150 a multi-factor device platform identity with enhanced security. The identity can be established by combining a unique device key 101 of the storage device 130, a platform source code that identifies one or more applications running on the terminal device 150 to establish a secure connection to a service or network (e.g. a client-server 141 or 143) and a unique identifier of a network interface 114 or communication device. A unique identifier can be, for example, the identifier of a modem that is installed on the terminal device 150 for communication in the network 110 . For example, the multi-factor device platform identity may be based at least in part on an International Mobile Equipment Identity (IMEI) number for a terminal 150 configured to access cellular services. For example, if the terminal 150 includes a vehicle, the multi-factor device platform identity may be based at least in part on a vehicle identification number (VIN). Such a strong identity can be used in conjunction with a cloud-based Subscriber Identity Module (SIM) function during onboarding, network access, and registration of a cloud service, such as a cellular subscription service.

The security server 140 and the security features of the storage devices (e.g., 130) may provide a secure technology platform for storage devices 130. The platform can be configured to support authentication of end devices 150 by measuring data stored in memory cells 103 of secure storage devices (e.g. 130). Additional cyber security protection for end devices can be achieved by controlling access to the content 161 stored in the storage devices (e.g. 130). Access control can be implemented through secure hardware manufacturing operations and cryptographic-based authorization control, as described above in connection with 1 until 5 was explained. A platform equipped with such storage devices (e.g. 130) can achieve a sufficient level of cybersecurity to support a cloud-based virtual SIM solution and the need for a physical SIM card in a terminal 150 to access to eliminate a cellular connection.

The secure storage device technology platform may include a combination of secure storage devices (e.g., 130) and software that meets the DICE RIoT requirements to generate identity data 113 for end devices (e.g., 150) that use the secure storage devices for use boot. This identity data 113 of a terminal 150 are generated based on the identity of the storage device 130 used in memory to boot the terminal 150 and other factors. This identity data 113 can be passed to a client-server 141 during onboarding (e.g. to register for a service). The client-server 141 can communicate with the security server 140 to confirm the identity of the terminal 150 . If the identity data 113 is checked, the client-server 141 can trust that the terminal 150 is authentic and thus register a service for the terminal 150 .

Such a service can be, for example, a cellular connection, which is traditionally registered on physical SIM cards. The identity data 113 verified by the secure storage device technology platform and backed by secure onboarding can provide identification of end devices (e.g. 150) in a manner that is as secure or even more secure than using physical SIM cards to identify end devices . A cloud-based virtual SIM card may be bound to identity data 113 verified by the secure storage device technology platform for the duration of the service subscription.

Typically, a subscriber can be recognized by a network (eg, a payment card network, a cellular network) via a smart card. A traditional smart card is configured as an integrated circuit chip embedded in a plastic card. The integrated circuit chip in the smart card stores data identifying a customer's account and may optionally store data related to network-provided services for the account. The integrated circuit chip can be read via metal contacts configured in an area of the surface of the plastic card and/or a wireless transceiver.

For example, a subscriber identification module (SIM) (also known as a SIM card) is a type of smart card. A SIM card is typically used in a mobile phone to identify an account for accessing the services of a mobile network. When the SIM card is attached to a mobile phone, the cellular communication network provides services to the mobile phone that correspond to an account identified by the SIM card. If the SIM card is attached to a backup mobile phone, the backup mobile phone can access the services configured for the account.

For example, a SIM card may store the identity of a mobile subscriber, such as the International Mobile Subscriber Identity (IMSI) number. The operator of a mobile network or a cellular network can assign an authentication key to the IMSI number and the SIM card. The authentication key is stored on the SIM card. The SIM card can be authenticated based on digital signatures used with the authentication key. After authentication of the SIM card, the mobile phone that has the SIM card can receive mobile/cellular services on the account associated with the identity of the mobile subscriber.

Europay MasterCard Visa (EMV) cards are another example of smart cards. EMV cards can be used to receive financial services on a card processing network to access bank accounts such as debit accounts and credit accounts.

The integrated circuit memory device 130 can be configured to prevent unauthorized access to its memory cells 103 and to ensure a unique identity of the memory device 130 itself and/or a terminal 150 in which the memory device 130 is installed. A secure storage device 130 having security features can be used to implement the functionality of smart cards, such as SIM cards and EMV cards, by using data provided to the secure storage devices remotely and/or by Data are used that are stored in memory, as in 6 .

6 shows a system and method for configuring and authenticating a terminal device for a card-based service according to an embodiment.

For example, the system and method of 6 in the computer system of 1 be implemented using the techniques of 2 until 5 be used.

In 6 For example, the memory device 130 can be implemented using the integrated circuit memory device 130 that incorporates the security features of the 1 until 5 having. An access controller 109 of the storage device 130 may use one or more access control keys 213 to control read and write operations for access to at least some storage areas in the storage device 130 .

For example, the storage device 130 is first manufactured with an access control key 213 to allow the security server 140 to have full access to the storage areas in the storage device 130 . The storage device 130 is further manufactured to include at least a portion of device identity data 211 that uniquely identifies the storage device 130 in a population of storage devices.

The device identity data 211 can be generated, for example, using a technique as illustrated in 2 .

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

The device identity data 211 may be a root code that is not disclosed, not modified, and not provided outside of the storage device 130 .

After the storage device 130 leaves the manufacturing facility, the root code and other secret information in the device identity data 211 is no longer available through the communication interface (e.g., the host interface 147) of the storage device 130. Because storage device 130 enforces a data access policy to prevent leakage of secret information and manipulation of data stored in the restricted areas of storage device 130, storage device 130 can be considered a secure storage device. The security server 140 stores information that can replicate the calculation performed by the storage device 130 to generate the derived codes independently of the storage device 130 . The security server 140 can thus regenerate the derived codes of the storage device 130 without the storage device 130 transmitting the derived codes via its communication interface (e.g., the host interface 147).

The root code of the storage device 130 may be implemented using a physical unclonable function (PUF), for example. The root code of storage device 130 may be retrieved from storage device 130 and stored in security server 140 for storage registration 231 during manufacture of storage device 130 . The root code can be used to generate a derived code from the device identity data 211 . For example, the PUF can be used to derive a Diffie-Hellman key pair; and the Diffie-Hellman key pair can be used to create the Device Unique Key (UDS) 101, which can be securely exchanged between the device and the security server.

The device identity data 211 can be generated with a technique, for example, as in 2 .

The derived code is generated in such a way (e.g. based on a cryptographic hash function, a random number and/or a monotonic count) that the root code is not derived from the derived code and/or other information used in generating the derived codes were used can be calculated. For example, the derived code may include a private key of a pair of asymmetric cryptographic keys. For example, the derived code may include a symmetric cryptographic key.

The device identity data 211 may include a non-secret, public identification number of the storage device 130, such as a serial number of the storage device 130, a unique identification number of the storage device 130, and/or a public key of an asymmetric cryptographic key pair, etc. The publication identification number can be used to uniquely identify the storage device 130 in a population of storage devices without revealing the secret information of the storage device 130; and the secret information of the storage device 130 can be used in authentication/verification, that the storage device 130 is the one identified by the public identification number.

Derived codes in device identity data 211 may be generated and/or replaced after storage device 130 leaves the manufacturing facility. The access control key 213 can be used to control the execution of the operations to create and/or replace the derived codes to prevent tampering. The derived codes may include, for example, cryptographic keys and/or certificates generated according to a Device Identity Composition Engine (DICE) standard.

During storage registration 231 , at least the root code of storage device 130 is stored in security server 140 in association with a public identification number of storage device 130 . The root code of the storage device 130 is known between the storage device 130 and the security server 140 during storage registration 231 in a secure environment when the storage device 130 is manufactured. Thereafter, additional information used to generate derivative codes may be public without compromising confidentiality of the derivative codes. The derived codes can be used in authentication of a storage device 130 and can optionally be substituted.

An access control key 213 is configured to prevent unauthorized access to and/or operation on the secret information in the device identity data 211 . For example, once an access control key 213 is configured in storage device 130, the secret information can only be used by cryptographic engine 107 (e.g., to regenerate derived codes and/or generate digital signatures). For example, a command/request received at host interface 147 of storage device 130 must be verifiably digitally signed with access control key 213, as illustrated in FIG 3 . If the digital signature applied to the command/request is valid according to the access control key 213, the command/request can be rejected and/or ignored.

For example, the access control key 213 can be used to authenticate the digital signatures applied to commands to perform certain operations relative to the device identity data 211, such as replacing a cryptographic key or an asymmetric cryptographic key pair.

Furthermore, one or more additional access control keys 213 may be used to authenticate the digital signatures of the owner and/or authorized users of the storage device 130 . Different authorized users can be restricted to access different areas of the storage device for specific operations (e.g., write, erase, read). An owner and other authorized users may have different scopes and/or permissions in the operation of storage device 130 .

The security server 140 can be configured as the initial owner of the storage device 130 . For example, a security server 140 public key may be initially stored in the storage device 130 as the owner's access control key 213 to provide owner credentials to commands signed with the security server 140 private key. After the storage device 130 is shipped to a customer, a customer's public key may be stored as a substitute for the owner's access control key 213 to transfer the owner credentials to the customer.

Optionally, certain security features of storage device 130 may be enabled for a customer. Some aspects of memory device 130 related to enabling security features are found in US Pat. Note Ser. No. 17/014,203 , filed September 8, 2020, entitled Customer-Specific Activation of Functionality in a Semiconductor Device, the entire disclosure of which is hereby incorporated by reference.

A terminal 150 may be constructed to include a storage device 130 and other components 187 . During the construction 233 of the terminal 150, the storage device 130 is installed/mounted in the terminal 150; and soft modules 217 and trace data 215 may be stored in storage device 130 .

A soft module 217 may include, for example, a boot loader of the terminal 150, firmware of the storage device 130 and/or a storage subsystem that includes the storage device 130, or an operating system or software application of the terminal 150. The soft module 217 may include instructions and data configured to implement a function are. The instructions may be executed by the logic circuitry of the storage device 130, the controller of a storage subsystem in which the storage device 130 is installed, and/or the processing device 118 of the host system 120 of the storage device 130 and/or the storage subsystem.

During construction of the terminal 233, a terminal registration 235 may be performed to store trace data 215 in the security server 140 and/or in the storage device 130. The trace data 215 can be part of the configuration and/or identity of the end device 150 .

For example, the trace data 215 can contain a hash value of the soft modules 217 that is calculated using a cryptographic hash function. The trace data 215 can contain, for example, secret information which is assigned to the terminal device 150 . The trace data 215 may be

A forgery of the end device 150, which does not have the trace data 215, cannot pass the end device authentication 239 that is dependent on the trace data 215. Thus, the security of the system is improved. Further details and examples of the techniques related to the trace data 215 can be found in US Pat. Note Ser. No. 17/005,565 , filed August 28, 2020, entitled Secure Memory System Programming for Host Device Verification, the entire disclosure of which is hereby incorporated by reference.

The terminal identity data 188 can be configured using the techniques of 2 are generated to represent the configuration of the terminal 150 at boot. The end device identity data 188 can include, for example, a certificate (e.g. message 131) based on a combination of a part of the device identity data 211, the trace data 215 and the identification data of other components (e.g. network interface 114, Processing device 118, controller 116) is generated, which are present at the time the terminal device 150 is booted.

The device identity data 211 and/or the terminal identity data 188 may include one or more certificates generated using a Device Identity Composition Engine (DICE) according to a standard developed by the Trusted Computing Group (TCG) that includes hardware secrets and source code combined to create trusted identities. Further details and examples of techniques for generating the device identity can be found in US Pat. Note Ser. No. 16/374,905 , filed April 4, 2019, entitled "Onboarding Software on Secure Devices to Generate Device Identities for Authentication with Remote Servers)," and published as US Pat. Note Pub. No. 2020/0322134 on October 8, 2020, the entire disclosure of which is hereby incorporated herein by reference.

A virtual card registration 237 operation may be performed to configure terminal 150 for card-based network 225 services, such as a mobile/cellular communication network, bank card processing network, etc.

For example, the terminal 150 may connect to a map server 223 to request a map profile 219 for the terminal 150 represented by the device identity data 211 . To request the card profile 219, the terminal 150 transmits a public part of the terminal identity data 188 to the card server 223. The card server 223 forwards the terminal identity data 188 to the security server 140 for authentication 239 of the terminal 150. For example, the in 2 explained authentication technique are used.

Once the security server 140 has verified that the terminal identity data 188 using a correct combination of the device identity data 211 of the storage device 130, the trace data 215 and other data of the terminal device 150 transmitted to the security server 140 during the terminal registration 235 and/or recorded there, the map server 223 can assign and/or store the map profile 219 to the storage device 130 , or associate the map profile 219 with the terminal identity data 188 .

The virtual card registration 237 can be carried out via a soft module 217 secured in the storage device 130 and/or via the security manager, so that the card profile 219 stored in the storage device 130 cannot be falsified. Optionally, the security server 140 can generate a verification code for a command 155 to write the card profile 219 to a secure portion of the storage device 130 . The write authorization of the secured section can be controlled via a cryptographic key stored in the security server 140 . For example, an access control key 213 assigned to the map server 223 or the security server 140 may be used by access controller 109 to control the storage and/or replacement of card profile 219 in storage device 130.

Furthermore, the storage device 130 can check the integrity of the card profile and/or a soft module 217 responsible for using the card profile 219, as illustrated in FIG 4 .

With the card profile 219 saved in the storage device 130 in the terminal 150, the storage device 130 and/or the terminal 150 function in a manner equivalent to a corresponding smart card installed in the terminal 150. The card profile 219, which is securely linked to the device identity data 211, can be viewed as a virtual smart card.

In some implementations, a soft module 217 is configured to utilize the cryptographic functions and/or the processing capability of the logic circuitry of the integrated circuit memory device 130 to implement the cryptographic operations involved in using the card profile 219 . For example, the card profile 219 may include an authentication key; and the soft module 217 may be configured to generate a digital signature for authentication/verification that the card profile 219 includes the authentication key.

The map profile 219 can be, for example, as illustrated in 7 and 8th .

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

In 7 the card profile 219 can include card data 241 and a soft card module 243 . Optionally, the soft card module 243 can be installed as part of the soft modules 217 stored in the storage device 130 .

Card data 241 may include identification of a smart card (e.g., virtual card), account, and/or subscriber. The card data 241 may identify, for example, a smart card type, a service subscribed to for the account/card, and/or customer data associated with the services (e.g., a balance amount, transaction record, message, etc.). In some implementations, card data 241 may include the same set of data stored in a physical smart card (e.g., an integrated circuit chip embedded in a plastic card coded according to a Universal Integrated Circuit Card (UICC ) is configured).

The soft card module 243 may include instructions to operate the card data 241 in a cryptographic engine 107 in the storage device 130 . For example, the computational functionality of an integrated circuit chip used in a particular type of smart card may be implemented by executing soft card module 243 in secure storage device 130 . The soft card module 243 allows a terminal 150 to emulate the computational operations of a physical smart card.

8th 12 illustrates a virtual subscriber identification module (SIM) card profile according to one embodiment.

In 8th contains the card profile 245 card data 241, for example an integrated circuit card identifier (ICCI) 251, a mobile device identification number 253, an international mobile subscriber identification number 255, an authentication key 257, which is assigned to the international mobile subscriber identification number 255, and service data 247 in relation to the mobile/cellular communications service for the international mobile subscriber identification number 255.

In a conventional mobile phone using a conventional SIM card, an Integrated Circuit Card Identifier (ICCI) 251 is used to identify the SIM card in a population of SIM cards. A Mobile Equipment Identity Number 253 (e.g. in the form of an International Mobile Equipment Identity (IMEI) number or an IMEI software version (IMEISV)) is used to identify the mobile phone in a population of mobile phones. An IMSI (International Mobile Subscriber Identity) number is used to identify a subscriber/customer/account in a population. These numbers in the card profile 245 can be used for similar functions when the card profile 245 is attached to the terminal 150. For example, if the terminal 150 is a mobile phone without a physical SIM card, the card profile 245 can act as a virtual SIM card to identify the card, the subscriber, and the terminal/mobile phone. For example, the Integrated Circuit Card Identifier (ICCI) 251 corresponds to and/or identifies the device identity data 211 of the storage device 130; the mobile device identification number 253 corresponds to and/or identifies the terminal device identity data 188 of the terminal device 150; and the International Mobile Subscriber Identification Number 255 represents the subscriber/customer/account in a mobile/cellular communication network.

The authentication key 257 is the secret code assigned to the international mobile subscriber identity number 255, for example. When a terminal 150 uses the international mobile subscriber identification number 255 to request a connection in a communications network, the mobile/cellular network operator can look up the authentication key 257 in a database and require the terminal 150 to show that it is in possession of the authentication key 257 is. The security challenge may include digitally signing a message containing a random number (RAND) using the authentication key 257 . A response to the security query may include a portion of the digital signature for verification by the cellular network operator. The operator autographs the message using the appropriate authentication key 257 associated with the international mobile subscriber identification number 255 in the database. If the response matches the response calculated by the mobile/cellular network operator, the digital signature is verified and as a result it is determined that the terminal 150 has the authentication key 257 assigned to the international mobile subscriber identity number 255 and is authorized to receive the services associated with the International Mobile Subscriber Identity Number 255. Furthermore, a symmetric cryptographic key can be derived from the digital signature in order to secure the communication between the terminal 150 and the mobile/cellular communication network in the subsequent communication session.

For example, if the card profile 245 is installed in the terminal 150, the terminal 150 can communicate with the mobile/cellular network operator to request a connection and respond to a security query using the same protocol as a mobile phone with a physical SIM -Map. Thus, the operator of the mobile/cellular network does not have to distinguish between the terminal 150, which has the card profile 245 as a virtual SIM card, and other mobile phones that have physical SIM cards.

Optionally, the card profile 245 may include an authentication module 259 configured to be executed by a cryptographic engine of the secure storage device 130 and/or the processing device 118 of the terminal 150 to perform cryptographic calculations during use of the card profile 245, such as such as generating the answer to the security query and/or the symmetric cryptographic key for the communication session.

In 6 After receiving the virtual card registration 237, the terminal 150 can receive services from the card-based network 225 using the card profile 219 to identify a subscriber/customer/account. For example, the card-based service network 225, which is initially configured to provide services for conventional smart cards, can also seamlessly provide services for terminals (e.g. 150) that have virtual smart cards stored in secure storage devices (e.g. 130). are implemented by storing card profiles (e.g. 219).

Optionally, terminal 150 may be configured to communicate with card-based network 225 in the same manner as a mobile device using a physical smart card (e.g., SIM card) or a smart card (e.g., EMV map) has.

The end device 150 can function, for example, as a smart card for a reading device. Terminal 150 may include metal contacts for connection to a reader. Terminal 150 may include, for example, a transceiver similar to wireless smart card readers. Alternatively, additional readers can be configured in the card-based network 225 that use alternative communication links to read the virtual cards from the terminal device 150 . Examples of alternative connections may include a near field communication (NFC) connection, a Bluetooth connection, a Wi-Fi connection, a Universal Serial Bus (USB) connection, and so on.

In another example, the terminal 150 can function as a mobile station having an integrated reader to read a smart card inserted into the mobile station, for example a mobile phone having a SIM card. The terminal 150 can communicate with the card-based network 225 to access the service 227 using the same communication protocol as a mobile station having a physical SIM card.

Optionally, the card profile 219 can be stored in the card server 223 in connection with the identity data of the terminal device 188 . The terminal 150 can access services 227 in the card-based network 225 using the terminal identity data 188 . In reaction the card-based network 225 can then communicate with the card server 223 in order to identify a card profile 219 based on the terminal identity data 188 . Further, based on the terminal identity information 188, the card server 223 can communicate with the security server 140 to perform terminal authentication 239 to verify whether the terminal 150 has the secure storage device 130 as at the time of virtual card registration and has the same configuration as provided by the combination of the trace data 215, soft modules 217 and the components 187 is displayed. If the terminal 150 is tampered with and/or modified, the changes may be detected in the status check 229 and/or the terminal authentication 239; in response, the card-based network 225 may deny the request for access to services 227 .

Optionally, the virtual card registration 237 can be performed just-in-time in connection with the request for access to the services 227. In response to the request, the terminal identity data 188 is verified by the terminal authentication 239 . After successful verification of the terminal, the card profile 219 can be associated with the terminal identity data 188 and/or stored in the memory 130 .

In some implementations, map server 223 is implemented as part of security server 140 .

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

For example, the system of 6 to simplify, secure and accelerate the large-scale global deployment of Internet of Things (IoT) devices and a rich ecosystem of IoT services. For example, virtual subscriber identity modules (SIM cards) of IoT devices (e.g. terminal 150) used to connect to the Internet via mobile/cellular communication networks.

The security server 140 can be used as a storage-based security-as-a-service platform for end devices (e.g. 150), for example for IoT edge devices. A map server can be used to provide a cellular connection for such end devices. By combining as in 6 can create a universal end-to-end solution for zero-touch onboarding of cellular-connected IoT devices to cloud services.

The complexity of implementing IoT in enterprises poses a challenge for the large-scale global deployment of IoT devices. The challenges include difficulties in implementing cellular connectivity and cybersecurity. Cellular connections have significant advantages over wireless local area networks (eg, Wi-Fi) for IoT deployments, such as longer range, better outdoor performance, better security, and existing global infrastructure. The requirements for physical SIM cards and contracts with mobile/cellular network operators are slowing down the use of cellular connections for IoT devices. A solution as in 6 illustrated, takes on such challenges.

Virtual SIM cards, implemented via securely associating a card profile 219 with terminal identity data 188 and/or device identity data 211, can eliminate the need for physical SIM cards. Deploying virtual SIM cards provides highly scalable IoT security, cloud-based SIM management, secure zero-touch device registration and onboarding for IoT services, fluid global connectivity, and just-in-time SIM activation.

A solution as in 6 is particularly beneficial for the industrial, infrastructure, automotive, aerospace, transportation and logistics sectors that require far-reaching, borderless connectivity for portable devices even in the most remote locations not protected by borders and Wi-Fi -Networks in the vicinity are obstructed.

A system as in 6 illustrated, flexible global connectivity can drastically simplify and open multiple opportunities for innovation in the IoT market.

The use of physical smart cards requires a tight association of card and/or device identity with the services offered by a network (e.g., 225) during manufacture to prevent insecure devices, insecure operations, fraud, and/or counterfeiting.

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

The security server 140 and/or the map server 223 can be used for the secure installation of Soft modules can be used to customize IoT devices. For example, an online soft module store can be provided that allows a soft module to be stored in a terminal 150 to customize its functionality in a manner similar to that provided in the example provided for providing the functionality of different types of smart cards and/or or SIM cards has been explained. Such customization allows organizations to access vendor-agnostic IoT services to explore and experiment with intelligence and data insights in new ways.

As the threat landscape from sophisticated malicious actors and hacks to devices from IoT aquariums to baby monitors becomes more risky, cybersecurity presents a weakness in IoT adoption. The security server 140 can offer Security-as-a-Service powered by the security features implemented in storage devices (e.g. 130) that control access and device identity data 211 . Thanks to its silicon root-of-trust, a secure storage device 130 provides a unique level of protection for the lowest layers of IoT software - starting with the boot process, with strong cryptographic identity and security features natively built into the storage device 130.

For example, Security-as-a-Service implemented via a combination of the security server 140 and the security features embedded in secure storage devices (e.g. 130) may verify the authentication of a storage device (e.g. 130), that has a public identification number, by verifying that the storage device (e.g., 130) has a root code recorded via the storage registration 231 performed during the manufacture of the storage device 130.

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

For example, the security-as-a-service may optionally further include identifying a service provider of the terminal 150 with the storage device 130 based on the identity of the owner/manufacturer of the storage device 130 before distributing the terminal 150 to an end user/customer. Based on the provider, the security server 140 can download a soft module 217 relevant to the services provided by the provider in order to customize the terminal device 150 . For example, the adaptation can be performed during terminal registration 235 . Optionally, an end user or an enterprise user can select a provider and the security server 140 and/or the map server 223 can provide the soft module 217 in the storage device 130 . Further, in response to authentication of a storage device 239, the security server 140 may automatically push a software update to the storage device. Thus, in practice, the vulnerability of end devices (e.g. 150) can be reduced and/or minimized in an automated manner without requiring additional efforts from the individual end device OEMs (e.g. 150).

For example, the Security-as-a-Service may optionally further include tracking of lost/stolen devices. In response to a terminal authentication 239 of a terminal 150 that is registered as stolen in the security server 140, the security server 140 can request the access controller 109 of the storage device 130 to block access to specific storage areas and/or to delete data from specific storage areas. In some instances, access control 109 may disable normal operations of terminal 150 by restricting access to resources such as a boot loader, operating system, application, and so on. In some instances, access controller 109 may perform an operation to irreversibly destroy memory functionality in memory device 130 .

The security-as-service can also include an audit service for the integrity of the end device 150, for example. The storage device 130 can, for example, construct the end device identity data 188 based on the cryptographic hash values of soft modules 217 that are stored in the storage device 130, so that the security server 140 can check, when the soft modules 217 are changed, whether the current Soft modules 217 are valid distributions from corresponding providers of the soft modules 217. If a soft module 217 is found to be damaged, tampered with and/or damaged, the security server 140 may initiate an operation to repair the soft module using a valid distribution from an online software store.

If an updated version of a soft module 217 is available, the security server 140 can recalculate the terminal identity data 188 for the authentication of the terminal 150 . Thus, if the terminal 150 has an outdated Softmo dul 217, the security server 140 will detect the presence of the outdated version and request/initiate an over-the-air update of the soft module 217. Optionally, the security server 140 can track a history of terminal 150 configuration changes that affect the terminal identity data 188 . For example, if requested, the security server 140 can communicate with the storage device 130 to revert to a previous configuration.

For example, the security-as-service may further include a device tracking service that may provide activity data to an owner of the terminal device 150 that corresponds to the owner's access control key 213 (or another authorized user that corresponds to a different access control key). The activity data can include location data and the use of the terminal device 150 in various services of the map-based service network 225, for example.

The terminal identity data 188 may include a public identity of the terminal 150, such as an International Mobile Equipment Identity (IMEI) number (e.g., mobile device identity number 253). The registration of the public identity of the terminal 150 for a service of the map-based network 225 (e.g. mobile phone connections) can be pre-registered with the map server (223) without using the terminal 150 . The IMEI number may be associated with an international mobile subscriber identity number 255 in a map server 223 database, for example.

When the terminal 150 attempts to connect to the card-based network 225 , the public identity (e.g., IMEI number) of the terminal 150 is authenticated in the terminal authentication 239 using the terminal identity data 188 . In response, the subscription registered for the international mobile subscriber identity number 255 is identified and used to create the card profile 219 to bind the card profile 219 to the terminal 150 . Binding may be in the form of storing the card profile 219 in the secure storage device 130 in the terminal 150 . Alternatively, the binding can also be embodied in the form of an assignment in a database of the map server 223 of the map profile 219 to the end device identity data 188 .

In some instances, a number of end devices (e.g. owned by an enterprise client) may share a reduced number of virtual SIM cards for cellular connectivity. For example, corporate client IoT devices may not require cellular connectivity at the same time. When a device 150 of the enterprise client requires a cellular connection, an available card profile 219 representing a virtual SIM card is dynamically "installed" for the device 150 just-in-time for the cellular services after the device authentication 239 for the duration of a communication session “. When the communication session is over, the virtual SIM card can be used by another end device of the corporate client. A physical SIM card can be moved from one cellphone to another cellphone to allow different cellphones to access the cellular services registered on the same SIM card. However, physically moving the SIM card from one cellphone to another is inefficient and not scalable for a large deployment. The just-in-time installation of a virtual SIM card can overcome the limitations of physical SIM cards and provides improved security through terminal authentication 239 before the virtual SIM card installation.

For example, such a just-in-time installation of a virtual SIM card can be used to facilitate infrequent or one-time use of cellular connections. For example, the cellular connection can be used to perform an over-the-air firmware/software update. The status to be used can be used, for example, to report the status of the terminal 150 at regular intervals (e.g. once a day, week or month). For example, the terminal 150 may report its operating status and/or its location in relation to a warranty service based on the terminal 150's location.

The Security-as-a-Service can, for example, further include an identity service with which the public identity of the terminal device 150 can be changed in a secure manner. For example, a number of end devices of a corporate client can share a reduced number of IMEI numbers. If a terminal 150 attempts to connect to the card-based service network 225 using an alternative public identity number in the terminal identity data 188, the card server 223 and/or the security server 140 may perform a terminal authentication 239, the terminal 150 an unused one Assign IMEI number associate the card profile 219 with the IMEI number assigned to the terminal 150 to enable the terminal 150 to receive the services from the network 225 as a device received, which is represented by the IMEI number.

If such a secure storage device 130 is used with the Security-as-a-Service offered by the security server 140, an original equipment manufacturer (OEM) of end devices (e.g. 150) can provide security by migrating the secure storage device 130 to the Terminals (z. B. 150) builds without having to perform their own security operations, such. B. the injection of security keys, the design and implementation of secure elements, hardware components or special system-on-a-chip (SoC) functions. Thus, the security server 140 and secure storage devices (e.g., 130) can provide IoT device OEMs (e.g., terminals 150) with plug-and-play security.

The security server 140 services may be used to post-authenticate, activate, and manage secure storage devices (e.g., 130) in an edge region. This capability enables platform hardening and device protection throughout the lifecycle, extending from the manufacturing supply chain to on-site installation and management.

9 12 illustrates a technique for authenticating a storage device according to one embodiment. For example, the technique of 9 used by a security service 5 to implement the identity data used by 2 .

Through the authentication operations of 9 For example, a session key 263 may be established to secure communication between a security server 140 and a storage device 130 without trusting a client-server 141 to manage the security to protect the confidentiality of the storage device 130. Optionally, session key 263 may be used by access controller 109 to implement permissions to request selected commands 155 on storage device 130 .

In 9 the client-server 141 can send a request 271 for identity data 113 of the storage device 130 to the storage device 130 .

The request 271 may include a cryptographic nonce 267 . For example, cryptographic nonce 267 may be generated by security server 140 in response to a request from client-server 141 or generated by client-server 141 and communicated to security server 140 for request 271 . Alternatively, the storage device 130 may generate the cryptographic nonce 267 in response to the request 271 and provide a corresponding response 273 that includes the cryptographic nonce 267 .

In response to the storage device 130's request 271 for identity data 113 , the storage device 130 provides a response 273 that includes a message identifying the unique identifier 111 of the storage device 130 .

A verification code 133 is generated for the message provided in response 273 using the secret key 137 of storage device 130 . As discussed above, verification code 133 may be implemented using techniques such as hash digest, digital signature, and/or hash-based message authentication code. Verification of the verification code 133 may be performed by the security server 140 using a corresponding cryptographic key 106 stored in association with the unique identifier 111 .

To protect the Response 273 and/or Verification Code 133 from security attacks (e.g., reusing the Response 273 and/or attempts to recover the Secret Key 137), the Verification Code 133 is generated for a Message 131 containing the Unique Identifier 111 , a counter value 265 and the cryptographic nonce 267 . The counter value 265 is obtained from a counter 261 in the storage device 130 . The value of the counter 261 increases monotonically. For example, the counter 261 can be used to store a value representing the number of requests for identity data and/or other data elements or security-related operations received. Thus, a response containing a counter value 265 that is lower than a previously seen counter value may be considered invalid. Cryptographic nonce 267 is used once in generating response 273 and discarded in storage device 130 . If the cryptographic nonce 267 was previously provided to or generated by the security server 140, the response 273 need not explicitly include the cryptographic nonce 267 in the response 273.

The client-server 141 forwards the response 273 to the security server 140 to request authentication of the storage device 130 . Using the unique identifier 111 provided in response 273, the security server 140 can obtain a corresponding cryptographic key 106 for verification of the Locate verification codes 133. For example, the corresponding cryptographic key 106 can be the secret key 137, or a corresponding public key when using asymmetric cryptography.

Based on the verification code 133 check, the security server 140 provides the client-server 141 with an authenticity identifier 275 . The authenticity identifier 275 indicates whether the storage device 130 is considered 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 a storage device 130 back to the verifier (e.g., the security server). Optionally, security server 140 may allow downloading of a certificate signing request (CSR) that allows the requester to use a certificate authority (CA) of their choice (rather than security server 140).

By authenticating the storage device 130, the storage device 130 and the security server 140 can establish a session key 263 for communicating with each other in a subsequent communication session. The session may be restricted by a predetermined length of time after the response 273 or verification code 133 check. After the time period expires, the session key 263 expires and thus may be destroyed or discarded. Furthermore, a subsequent request for identity data may terminate the previous session started by the previous request for identity data.

Session key 263 may be generated based at least in part on a secret known between security server 140 and storage device 130 but unavailable to a communication channel between security server 140 and storage device 130 .

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

In some implementations, the session key 263 is independent of the verification code 133; and verification code 133 may be generated using session key 263 derived from secret key 137 or other code known between security server 140 and storage device 130.

10 11 illustrates a technique for generating a command to control security operations of a memory device, according to one embodiment. For example, the technique of 9 used by a security service 5 using the techniques of 3 and 10 to implement.

For example, after client-server 141's authorization to request execution of a command 155 in storage device 130 has been verified using client authorization data 283, security server 140 can send client-server 141 in response to a request 281 from the client -Servers 141 provide a verification code 153 for the command 155.

Some of the communications in 9 and 10 can be combined. For example, in some instances, the request 281 may include the identity data 113 provided in the storage device 130 in the response 273 to a request 271 to the storage device 130 .

After client-server 141 sends request 281 identifying command 155 and storage device 130, security server 140 may generate a verification code 153 for command 155 if client-server 141 is determined to be authorized to use storage device 130 under to control or operate using command 155. The request 281 may include the unique identification 111 of the storage device 130 in which the instruction 155 is to be executed. The unique identification 111 can be extracted, for example, by the client-server 141 from the response 273 to the request 271 for identity data of the storage device 130 and/or the authenticity identifier 275 provided by the security server 140 .

As discussed above, verification code 153 may be implemented using techniques such as hash digest, digital signature, and/or hash-based message authentication code. The verification code 153 check can be performed by the access controller 109 using an access control key 149 for the command 155 . The verification code 153 may be generated using a cryptographic key 277 stored in the Security server 140 is stored to represent the permissions to execute command 155 in storage device 130 . For example, cryptographic key 277 may be access control key 149 if asymmetric cryptography is not used; alternatively, when using asymmetric cryptography, the access control key 149 can be a public key in a key pair and the cryptographic key 277 a private key in the key pair.

In one embodiment, access control key 149 and cryptographic key 277 for command 155 permissions are preconfigured. In another embodiment, access control key 149 and cryptographic key 277 are based on session key 263. For example, session key 263 can be used as access control key 149 and cryptographic key 277 can be used for command 155 access control. In some embodiments, session key 263 is one of an asymmetric key pair that can be used to implement cryptographic key 277 and access control key 149, where encryption is performed using asymmetric cryptography.

If the verification code 153 is based on the session key 263, the verification code 153 expires when the session key 263 expires, preventing reuse of the verification code 153 beyond the session in which the session key 263 is valid.

A message 151 provided in the request 285 may include the command 155 and a cryptographic nonce 287 . The cryptographic nonce 287 is arranged for the command 155/request 285 and thus differs from the cryptographic nonce 267 for the transmission of the identity data of the storage device 130.

For example, security server 140 may generate cryptographic nonce 287 in response to request 281 and use it to generate verification code 153 . The cryptographic nonce 287 can be provided with the verification code 153 to allow the client-server 141 to generate the request 285 . Alternatively, client-server 141 may generate cryptographic nonce 287 and provide it to security server 140 with request 281 . Alternatively, the client-server 141 may request the cryptographic nonce 287 from the security server 140 to generate the request 281 .

After the client-server 141 sends the request 285 with the verification code 153 received from the security server 140, the storage device 130 uses the access control key 149 to verify the verification code 153 for the message 151 contained in the request 285. If verification code 153 is valid, access controller 109 allows storage device 130 to execute command 155; otherwise, access control 109 may block instruction 155 from executing in storage device 130 .

Command 155 may be configured to enable a security feature on storage device 130, for example.

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

Upon execution of command 155, storage device 130 provides a response 289 that may be forwarded by client-server 141 to security server 140. FIG. The security server 140 can determine whether the response 289 is correct. For example, storage device 130 may sign the response using session key 263 for verification by security server 140 .

In some implementations, a replacement secret key to replace an existing secret key 137 of the storage device 130 is generated independently by the storage device 130 and the security server 140 from a secret code (e.g., a unique device key 101) and additional data obtained via the client-server 141 to be exchanged. Optionally, the additional data can be protected by encryption performed using session key 263 .

In some implementations, a replacement secret key is transmitted from storage device 130 to security server 140 in an encrypted form of ciphertext generated using session key 263 .

11 Figure 12 shows a method for a virtual smart card according to one embodiment. For example, the process of 11 in the in 6 illustrated system with the security server 140 and the security features of a storage device 130 described above in connection with the 1-5 were explained using the techniques of 9 and 10 to be implemented.

At block 301, a logic circuit or controller resident in an integrated circuit package of a memory device 130 provides device identity data 211 representative of the memory device 130 and based at least in part on a root code of the memory device 130.

For example, the storage device 130 may include a Physical Unclonable Function (PUF) for generating the root code.

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

At block 303, the memory device 130 stores the device identity data 211 in a first memory area of integrated circuit memory cells formed on one or more chips included in the integrated circuit package.

At block 305, the logic circuit controls access to the first memory area based on an access control key 213.

At block 307, the memory device 130 stores in a second memory area of the integrated circuit memory cells boot instructions executable by a terminal 150 having the memory device 130 as one of a plurality of terminal 150 components.

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

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

The terminal device 150 can be configured, for example, in the storage device 130 in such a way that it generates identity data 188 in a storage device 130 which is representative of a component configuration of the terminal device 150 at its boot time. The terminal identity data 188 can be calculated using the device identity data 211, the trace data 215 stored in the storage device 130 during the construction 233 of the terminal 150, and the identification data of components of the terminal 150 that are external to the integrated circuit package of the storage device 130 will.

The card profile 219 can be identified, generated and/or assigned to the terminal device 150 based on the identification of the terminal device identity data 188, for example.

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

For example, the card profile 219 may be stored in the storage device 130 to emulate a SIM (Subscriber Identification Module) card typically used in the authentication of a cellular phone when accessing a cellular network. The card profile 219 may include the international mobile subscriber identity number 255 and an authentication key 257 associated with the international mobile subscriber identity number 255, for example.

For example, when terminal 150 requests a cellular connection to international mobile subscriber identity number 255, a mobile/cellular network operator may ask a security challenge to authenticate terminal 150. In response, the card profile 219 can be used to generate a response to a security query by signing a message with a random number using the authentication key 257 to show that the terminal has the authentication key 257 in possession. For example, the message containing the random number can be signed using authentication key 257 . An answer to the security query can contain part of the digital signature for authentication; and another portion of the digital signature can be used as a symmetric cryptographic key to encrypt a communication session associated with the cellular connection.

12 12 shows a method for security services provided based on security features of a storage device according to an embodiment. For example, the process of 12 in the computer system of 1 based on the security features of a storage device 130 described above in connection with the 1-5 were explained using the techniques of 9 and 10 to be implemented.

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

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

For example, the secret code may be a unique device key 101 that is not disclosed outside of the storage device 130 after the storage device 130 is completed in a secure facility. The identity data 113 is based on a secret key 137 that is generated based at least in part on the unique device key 101 . During manufacture of the storage device in the secured facility, the secret code is stored in the security server 140 to generate a cryptographic key 106 based at least in part on the secret code, which is verified in the identity data 113 . The cryptographic key 106 used to verify the identity data 113 can also be generated based on data 125 received from a host system 120 of the storage device 130 during a boot time of the host system 120 . Upon completion of the fabrication of the storage device 130 in the secure facility, the storage device 130 may be incorporated into a terminal 150 having the host system 120 connected to a host interface 147 of the storage device 130 . At least a portion of instructions configured for execution on a processing device 118 of host system 120 are stored on storage device 130 .

At block 325, the security server 140 generates a verification code 153 for an instruction 155.

For example, after determining, based on the client authorization data 283 stored in the security server 140, that the client-server 141 has authorizations to execute the command 155 in the storage device 130, the verification code 153 for the client-server 141 can be generated and stored in of response 174 based on permissions.

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

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

For example, the response 174 may be based on a determination that the storage device 130 has the secret code if the identity data 113 includes a verification code 133 generated using the secret code.

At block 329, client-server 141 transmits command 155 and verification code 153 to storage device 130.

At block 331, the access controller 109 of the storage device 130 examines the verification code 153 to determine whether execution of the instruction 155 in the storage device 130 should be blocked.

For example, when executed in storage device 130, instruction 155 causes a change in an access control key 149 used by access controller 109 to verify verification codes (e.g., 153) generated using a cryptographic key 145 that is associated with a is authorized to execute one or more instructions in storage device 130.

For example, when executed on storage device 130, command 155 causes a change in the setting of security features of storage device 130. The change may include, for example, enabling a security feature of storage device 130 or disabling the security feature.

For example, when executed on storage device 130, command 155 causes storage device 130 to disable a bootloader stored on storage device 130 after terminal 150 containing storage device 130 has been reported lost or stolen.

For example, instruction 155, when executed on memory device 130, causes access controller 116 to disable access to one or more portions of memory cells 103 on memory device 130.

For example, command 155, when executed on storage device 130, causes storage device 130 to erase a decryption key for data stored on storage device 130.

For example, instruction 155, when executed on storage device 130, causes storage device 130 to irreversibly destroy at least one aspect of storage device 130.

For example, based on a verification of the identity data 113, a session key 263 can be set up and made known between the security server 140 and the storage device 130 without the session key 263 being transmitted over a connection between the security server 140 and the storage device 130. An access control key 149 used by the access controller 109 to verify a verification code 153 for a command 155 may be based on the session key 263.

Optionally, security server 140 may cause command 155 and verification code 153 to be transmitted to storage device 130 based on instructions loaded from storage device 130 and executed for execution on host system 120 .

13 FIG. 12 shows a method for onboarding a terminal device to a service that has been subscribed to an account according to an embodiment. For example, the process of 13 in the computer system of 1 based on the security features of a storage device 130 described above in connection with the 1-5 were explained using the techniques of 9 and 10 to be implemented.

At block 341, a server system receives from a terminal 150 a request (e.g., 171 and/or 173) associated with a service. The service is provided over a computer network (e.g., network 110) serving a variety of subscribers represented by different accounts. The request includes identity data 113 generated by a storage device 130 configured in terminal 150 .

The server system can include the security server 140 and/or the map server 223, for example. Optionally, the server system may further include a client-server 141 that communicates with the security server 140 .

For example, the service may be a cellular connection service, a payment card service, a video surveillance service, a cloud-based storage or billing service, and so on.

At block 343, the server system, in response to the request and based on a secret code of the storage device 130 and the identity data 113, determines the authentication of the terminal 150. For example, the operations in block 343 can be performed in a manner similar to the operations operated in block 323 .

At block 345, based on the identity data 113, a participant of the plurality of participants is identified based on the terminal 150 ownership data.

For example, when the terminal 150 is manufactured at a terminal manufacturer's (e.g., 150) manufacturing facility, the storage device 130 is connected to the host system 120; and in the storage device 130, a software package for the operation of the terminal 150 is installed. The terminal 150 is tested. In the terminal registration 235, the storage device 130 is configured to generate the secret key 137, which not only represents the storage device 130 with the unique device key 101, but also the terminal 150, which represents the storage device 130 with the data 123 in the storage cells 103 and the data 125 from the host system 120 at boot time.

When the terminal 150 is transferred from the manufacturer to a retailer and to a user or subscriber, data associated with the public identification of the terminal 150 and the identity of the subscriber is stored in the server system. The proprietary data may be stored in the server system without physically operating the terminal 150 (e.g., without opening the box in which the terminal 150 has been packaged since the terminal 150 was manufactured). For example, the public identification of the terminal 150 the unique Identification 111 of the terminal 150 and/or data 127 identifying the manufacturer, model and serial number of the terminal 150 as known to the manufacturer of the terminal 150.

When the subscriber sets up an account for the service provided to terminal 150, the subscriber's identity may be associated with the account.

For example, client credential data 283 may include terminal 150 ownership data and/or subscriber data indicative of the subscriber's account.

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

For example, the account may be identified by matching the subscriber's identity associated with identity data 113 in the owner data with that associated with the account in the subscriber data.

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

In some implementations, client credential data 283 stored in security server 140 indicates the association between identity data 113 and the subscriber's account. Thus, when checking the authenticity of the terminal device 150 based on the identity data 113 received, the account can be identified using the client authorization data 283 .

In alternative implementations, the client credential data 283 stored in the security server 140 indicates the connection between the identity data 113 and the identity of the subscriber as the owner. Thus, when checking the authenticity of the terminal device 150 based on the identity data 113 received, the subscriber can be identified using the client authorization data 283 . Another server (e.g., client-server 141 or card server 223) stores the subscriber data to identify the account based on the subscriber identified by security server 140.

Using the method of 13 the service subscribed to an account can be provided/delivered to a terminal 150 without the terminal 150 itself having to be adapted to the subscriber and/or the subscriber's account. For example, the subscriber may simply open the packaging in which terminal 150 is packaged when terminal 150 is manufactured and use terminal 150 to access the service subscribed to for the subscriber's account without a card (e.g., a SIM card) to identify the subscriber or account and/or without interacting with an application or utility running on terminal 150 to identify the subscriber or account.

For example, after the terminal 150 is manufactured, prior to receiving the request in block 341, the terminal 150 has no customization for the subscriber and no customization for the account. The terminal 150 is manufactured in such a way that it can be used by a large number of participants. In response to the request received in block 341, the terminal 150 is automatically associated with the subscriber's relevant account for the service.

For example, prior to and/or after receiving service for the subscriber's account, terminal 150 does not include a hardware component inserted into terminal 150 to represent the subscriber, the account, or any combination thereof.

For example, at least prior to the request received in block 341, terminal 150 does not contain data stored in terminal 150 to represent the subscriber, account, or any combination thereof.

For example, at least prior to the request requested in block 341, terminal 150 does not contain an identifier of the subscriber, account, or any combination thereof without the proprietary data of terminal 150; and the property data is stored in the server system but not in the terminal 150.

Optionally, in response to the request received in block 341, the server system and/or the terminal 150 may store the association of the identity data of the terminal 150 with the subscriber's account.

For example, the security server 140 can generate a verification code 153 for an instruction 155 using a cryptographic key 145 . The server system can cause the storage device 130 to receive the command 155 and the verification code 153 . Prior to executing command 155 in storage device 130 , access controller 109 of storage device 130 is configured to verify verification code 153 based on access control key 149 . Optionally, the access control key 149 and the cryptographic key 145 is based on a session key established in the manner as in 9 explained.

When executed on storage device 130, command 155 causes storage 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 in generating updated identity data 113 . For example, the additional data in the data 127 in a message 131 may be included in updated identity data 113 generated in the storage device 130 after execution of the command. The additional data may include, for example, a card profile 219 identifying the subscriber's account.

Alternatively, data associated with the identity data 113 of the storage device 130 and/or the terminal 150 may be stored in the server system (e.g. as part of the client authorization data 283 and/or the card profile 219) without the secret Change key 137 used to sign identity data 113.

Because no operation is required on the terminal 150 to direct the service of a subscriber's account to the terminal 150, the terminal 150 can be configured as a cellular-connected IoT device without requiring a user interface for its customization to receive cellular-connected services . For example, the terminal 150 may be configured without a slot into which a card for identifying the subscriber may be inserted. For example, terminal 150 may be configured without a user interface to receive input from an end user to identify the subscriber.

In some implementations, a terminal 150 has a generic hardware configuration that can operate with different firmware to provide different functions. Furthermore, an updated version of the firmware may be installed on the terminal 150 to correct defects or bugs in the terminal 150 running the previous version of the firmware to improve performance and/or to provide new functionality. Optionally, a firmware application can run on a base version of the firmware to add functionality, features, and/or services.

For example, different client-servers 141,...,143 can provide different services by using the same hardware of the terminal 150 running different firmware. For example, the different client-servers 141, ..., 143 can provide similar services using the same hardware of the terminal 150, but perform different processes implemented with different firmware.

The terminal 150 can be adapted for different client-servers 141,...,143 after the terminal 150 has been assembled and shipped to an end user or subscriber by installing different firmware.

For example, an online firmware store may be configured in communication network 110 to allow the user to purchase a firmware version. Installation of a selected firmware version may or may not include installation of a firmware application that will run on a base version of the firmware. After installing the selected firmware version, the terminal 150 is customized in at least one aspect that differs from the terminal 150 running the previous firmware.

In some instances, the updated firmware represents a terminal 150 request requested by the terminal 150 user. The service of the terminal 150 may or may not rely on the services of a client-server or a provider.

The functionality of the terminal 150 may be defined, at least in part, by its firmware. For example, if the terminal 150 is running a version of the firmware, the terminal 150 may provide a function to the user of the terminal 150; and if the terminal 150 runs a different version of the firmware, the terminal 150 can provide a different function to the user of the terminal 150 .

For example, different third-party service providers can provide software/firmware solutions for IoT devices based on a common, generic hardware platform. For example, the firmware provided in the online store can be programmed to allow a generic IoT device to work with a third-party server to provide a specific type of service. Optionally, a firmware application provided in the online store can run on a generic version of the firmware and use the basic services provided by the generic firmware to provide the services of a particular type. A combination of a base version of the firmware and a firmware application can be used as one extended version of the firmware can be viewed. If base versions of firmware for different end device hardware platforms offer standardized services, a firmware application can be device independent and support a range of IoT devices from different manufacturers. Alternatively, a firmware application can also be device dependent and use hardware features that can vary from manufacturer to manufacturer.

A security server 140 may be coupled to the online firmware store to provide firmware updates to the terminals (e.g., 150) in response to verification of the authenticity of the terminals.

For example, when a terminal 150 is first connected to a client-server 141, the client-server 141 communicates with the security server 140 to verify the identity and/or authenticity of the terminal 150. The owner of the terminal 150 can be determined as part of the verification process. After the subscribed services of the terminal 150 have been identified, a corresponding firmware application can be downloaded from the online firmware store and installed on the terminal 150 through an over-the-air (OTA) update.

For example, the security server 140 can generate the verification code 153 for the command 155 to install the firmware application in the storage device 130 . After the execution of command 155, the firmware application becomes part of the data 123 stored in the memory cells 103 of the storage device 130 and part of the device information 121 when generating an updated secret key 137 for updated identity data 113 of the storage device 130 and the terminal 150 be used.

If an update for the firmware application is subsequently available in the online firmware store, the outdated firmware application can be detected in the terminal 150 during the verification of the identity data 113 and the security server 140 can perform an over-the-air update ( initiate OTA) for the terminal 150 to reduce the security risk.

For example, an online service store may offer cloud-based services provided via end devices (e.g., 150), such as Internet of Things (IoT) devices. The same terminal 150 can be customized via firmware updates used by the different vendors that may run different client-servers 141,...,143.

For example, the user of terminal 150 may visit the online store to subscribe to a provider's service, change the subscribed service, and/or move the subscription from one provider to another provider. The subscription ordered by the user for the terminal 150 may be tracked as part of the client credential data 283 associated with the terminal 150 identity. If the identity data 113 of the terminal device 150 is checked by the security server 140, the security server 140 can check whether the terminal device 150 requires a firmware update for the subscribed service and/or the replacement of an outdated firmware version. If this is the case, the security server 140 can initiate a firmware update via the online store to customize and/or update the terminal 150 before the terminal 150 receives the subscribed service from the provider. Optionally, the security server 140 communicates with the terminal 150 to refer the terminal 150 to the current client-server 141 of the provider. Alternatively, the updated firmware causes the terminal 150 to connect to the current client-server 141 of the provider.

In general, the security server 140 may be connected to or include the online service store and/or the online firmware store. A server system may include the security server 140, the online service store, and/or the online firmware store. The server system can track the accounts used to subscribe to the services of different providers and track the firmware customization selected/purchased by the users of the terminals (e.g. 150).

An account of the user of the terminal 150 with a provider of services subscribed to the terminal 150 can be tracked using an identity of the user and correlated to the identity of the user as the owner of the terminal 150 for automatic firmware update. The selection of the firmware and/or the service made by the user in the online service store and/or in the online firmware store can be mapped to the end device 150 of the user by the correlation. Alternatively, the user of the terminal 150 can select the firmware and/or services explicitly for the terminal 150 by using a public identification of the terminal 150 that is part of the identity data 113 of the terminal 150 .

In some implementations, terminal 150 first connects to security server 140 to consume services. The security server 140 can use the current provider of the subscribed service registered in the online service store based on the client's 283 entitlement data. After verifying the authenticity of the terminal 150 and determining the service provider, the security server 140 configures the firmware of the terminal 150 for the service provider (e.g., using the online firmware store) and forwards the terminal 150 to the client-server ( eg 141, ..., or 143) of the service provider. Thus, the terminal 150 can provide the services ordered in the online service store seamlessly and with minimal effort for the user.

14 FIG. 12 shows a technique for adapting terminals using online firmware storage according to an embodiment. For example, the technique of 14 in a computer system of 1 and or 6 with the in the 1 until 5 security services and features explained are implemented. The technique of 14 can be combined with the techniques of 9 until 13 be used.

In 14 an online firmware store 170 is configured to facilitate the selection of firmware and/or firmware applications for the customization and/or updating of terminals (e.g. 150) in connection with the security server 140 that maintains the identity of the Terminals (e.g. 150) checked.

The terminal 150 includes a variety of hardware including a host system 120 and a storage device 130 with security features. The functionality of the terminal 150 can be defined, customized and updated by the firmware 363 stored in the storage device 130 and executing in the host system 120 of the terminal 150 .

A manufacturer of the terminal 150 can install a basic version of the firmware 363 that is programmed so that the terminal 150 can generate identity data 113 and transmit it for verification by the security server 140 . The base firmware 363 is further configured to allow firmware update via the firmware store 170 in conjunction with verification of the identity data 113 by the security server 140 .

In general, the firmware update for terminal 150 may be the replacement of all firmware 363 running in host system 120, or the addition and/or replacement of one or more firmware applications (e.g., app 367, .., 369).

A terminal platform 361 may be used to represent a class of terminal hardware. Each terminal (e.g. 150) in the class can operate with different firmware versions (e.g. 363,...,365) to provide different functions and/or services.

In some implementations, the firmware 363 can be customized via one or more firmware applications (e.g., app 367, ..., 369). For example, the terminal 150 running the firmware 363 may also run an optional application (e.g., app 367, ... or 369) to provide a new feature not present in the firmware 363, an existing feature disable in the 363 firmware, change or customize an existing feature in the 363 firmware, etc.

For example, when a firmware application (e.g., app 367) runs on firmware 363 in terminal 150, terminal 150 is adapted to communicate with a provider's client-server 141 to implement a service or function and /or receive a service from the provider. If another firmware application (e.g. App 369) runs on the firmware 363 in the terminal 150, the terminal 150 is adapted differently to communicate with another client-server 143 from another provider in order to provide an alternative or similar service or implement a feature and/or receive an alternative or similar service from the other provider.

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

For example, the firmware application (e.g., App 367) can be programmed to perform a new computational function that produces a new type of results.

For example, the firmware application (e.g., app 367) can be programmed to communicate with client-server 141 for a service provided through client-server 141 . Examples of client-server 141 service include client-server 141 computing resources for processing data for terminal 150, client-server 141 data storage facility for data generated by terminal 150, messaging facility for notifications and/or alerts to one or more other devices associated with the terminal 150, connectivity via the client-server 141 to one or more other devices associated with the terminal advises 150, internet access by the terminal 150 via a Wi-Fi access point, a communication satellite and/or a communication link or equipment controlled by the client-server 141, etc.

In general, different vendors may provide different firmware versions and/or different firmware applications to accommodate the terminals (e.g., 150) in the same terminal platform 361. Terminals in platform 361 may be manufactured and/or assembled by the same manufacturer or by different manufacturers.

Optionally, a base version of the firmware (e.g. 363) may provide a standardized feature set on which to run the firmware applications (e.g. App 367,..., 369). Thus, the same firmware application (e.g. App 367) can be installed to adapt terminals (e.g. 150) that have a different hardware configuration and/or different base firmware versions (e.g. 363, ..., 365). Alternatively, different firmware applications can be programmed for different base firmware versions (e.g. 363, ..., 365) running on terminals with different hardware implementations to provide the same customized function of the terminals in question and/or for the same service of a client-server 141 to provide.

The use of firmware applications (e.g. app 367, ..., 369) can reduce the size of the data that needs to be downloaded from the firmware memory 170 to the terminal 150 when performing a firmware update. Alternatively, different sets of firmware functions can be implemented using different firmware (e.g. 363,...,365) without additional firmware applications. In general, a firmware update in terminal 150 may involve replacing the existing firmware 363 in its entirety or installing a firmware application (e.g., app 367).

Optionally, the firmware store 170 is configured so that a user of the terminal 150 can use a computer 180 to select and/or order 371 firmware for the terminal 150 customization. In some instances, purchasing a selected firmware version (e.g. 363) and/or firmware application (e.g. 367) entails requesting a service from a service provider and/or a client-server (e.g In response, the firmware store 170 and/or the security server 140 may store data indicative of a desired firmware configuration and/or a requested service for the terminal 150. For example, client entitlement data 283 may be updated to reflect selections of firmware and/or service used with user computer 180 .

In general, user computer 180 may be distinct and separate from terminal 150 . Thus, a hardware and/or software interface accessible to the user of terminal 150 is not required to customize terminal 150 for use with an account and/or provider. Optionally, the terminal 150 of some implementations and/or categories may include a user interface that enables it to be used as a user computer 180 to order firmware for the terminal 150 371.

For example, the owner or user of terminal 150 may use user computer 180 to visit online firmware store 170 and order 371 firmware for terminal 150 by installing a firmware application (e.g., App 367 ), a replacement firmware version, or a combination of a replacement firmware version and a firmware application. The order can be identified for the user as a service subscriber and/or the terminal 150 as a device to be adapted.

The terminal 150 can be identified, for example, via a public identification of the terminal 150, for example via a model and serial number of the terminal 150, a mobile device identity number 253, an international mobile subscriber identity number 255, the unique identifier 111 and/or another in the Data 127 of the identity data 113 identification contained.

The identity of the user or participant may be identified, for example, via an account identifier and/or personally identifiable information, such as an email address, phone number, name and address, etc.

The security server 140 can verify 373 identity data 113 transmitted by the terminal 150 and/or its storage device 130, as described above in connection with FIG 2 , 5 and 9 explained.

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

For example, terminal 150 may be configured via existing firmware 363 to automatically visit firmware store 170 and/or security server 140 for identity verification, firmware update, and/or service customization. Thus, in some instances, the identity data 113 may be communicated to the security server 140 via the firmware store 170, while in other instances it may be communicated directly to the security server 140.

For example, when a server (e.g., a client-server 141 or 143, the firmware store 170, or another server) receives the identity data 113 for a request 171 from the terminal 150, the server (e.g., 141) the identity data 113 to the security server 140 in a request 173 ready 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 for the terminal 150 is available. If this is the case, the security server 140 can cause the firmware store 170 to update the firmware of the terminal device 150 . For example, after a firmware download has been performed to store a new version of the firmware and/or a firmware application (e.g., App 367) in the storage device 130, an instruction 155 signed with a cryptographic key 145 is then stored in the Storage device 130 is executed to cause a new version of the firmware and/or the firmware application (e.g. app 367) to be executed in the storage device 130 and become part of the identity of the storage device 130 and/or the end device 150.

For example, firmware 363 may first be installed in terminal 150 (e.g., by a terminal 150 manufacturer) to provide service via client-server 141 . After a new version of the firmware 363 is available in the firmware store 170 for accessing the same client-server 141 service, the security server 140 may initiate the installation of the new version in response to the successful verification of the identity data 113 . Optionally, the update 377 can be implemented by installing a firmware application (e.g., App 367) that runs on the existing firmware 363, or by installing new firmware (e.g., 365).

For example, if the user of the firmware 363 visits the firmware store 170 to order 371 an alternative version of the firmware 365 to customize the terminal 150, and if the identity data 113 of the terminal 150 has been successfully verified in the security server 140, the firmware store 170 update the firmware of the terminal 150 according to the order 371 377.

In some instances, the terminal 150 first visits the security server 140. After the security server 140 verifies the identity of the terminal 150 (373), the security server 140 may communicate with the firmware store 170 to identify a firmware update of the terminal 150 ( 375).

In general, a firmware update may involve installing a firmware application (e.g., App 367), replacing an existing firmware application with a different firmware application, and/or installing a new firmware 365.

After the desired firmware update has been identified, the firmware store 170 communicates with the terminal 150 to update the terminal 150 377.

The access controller of the storage device 130 is configured to request verification of authorization to request execution of an instruction 155 in the storage device 130 to make a change to the firmware stored in the storage device 130 .

For example, after the data required for the firmware update is stored in a portion of the storage device 130, the command 155 may be sent to the host interface 147 to perform the firmware update operations in the storage device 130. Authorization to execute command 155 on storage device 130 may be represented by a cryptographic key 145 . The cryptographic key 145 can be configured beforehand or generated in response to the verification of the identity data 113 in the storage device 130 of the terminal device 150 . For example, the cryptographic key 145 can be the session key 263, which is determined based on the verification of the authenticity of the terminal device 150 in a similar manner as in FIG 9 is produced; and the security server 140 can generate a verification code 153 for the command by using the cryptographic key 145 for the firmware store 170 to update the terminal 150. Alternatively, the security server 140 can provide the session key 263 and/or the cryptographic key 145 to the firmware store 170 in order to update the firmware 377 of the terminal device 150 .

Upon successful firmware update, device information 121 is updated to generate secret key 137 to reflect the installed firmware and/or firmware application. For example, a hash value 163 of the installed firmware and/or firmware application can be stored as part of the device information 121 to verify its integrity, as in 4 . Subsequently, the identity data 113 for the terminal device 150 generated by the storage device 130 is based on the updated device information 121 and reflects the configuration of the terminal device 150 having the updated firmware functionality or configuration.

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

In some implementations, the firmware update 377 may be performed automatically based on the service subscribed to by the terminal 150, as discussed further below in connection with FIG 15 .

15 12 shows a technique for routing services to a terminal via an online service store, according to an embodiment. The technique of 15 can be used, for example, in combination with the techniques of 14 .

In 15 For example, an online service store 190 is configured to facilitate a terminal 150 in selecting a service from a variety of services provided by one or more providers (e.g., 381). The service of a service provider (e.g. 381) can be implemented via one or more terminal platforms (e.g. 361, ..., 362).

For example, a user of terminal 150 may use a computer 180 to visit the online service store 190 to order 391 a service 391 from a service provider 381. The service provided by service provider 381 may be used with terminals of multiple terminal platforms (e.g. 361, ..., 362) can be used. The terminals (e.g. 150) in the terminal platforms (e.g. 361, ..., 362) run different firmware for the service provider 381 service Identify subscribers and/or services ordered for the terminals (e.g. 150).

The service offered by the service provider 381 can be implemented via a client-server 141, for example, and the subscription data 387 can identify the servers to which the terminals should connect in order to receive the services subscribed to for the terminals.

For example, a service may be explicit for terminal 150 with reference to terminal 150 public identification, terminal 150 model and serial number, mobile device identity number 253, international mobile subscriber identity number 255, unique identifier 111, and/or another identification contained in the data 127 of the identity data 113 can be ordered.

Alternatively or in combination, a service may be ordered with reference to the identity of the user or subscriber identified via an account identifier and/or personally identifiable information such as email address, phone number, name and address, etc can.

As in 14 the user computer 180 is typically distinct and separate from the terminal 150. In some instances, the terminal 150 may include a user interface that allows it to be used as a computer 180 to order 391 services for the terminal 150.

When a service is ordered implicitly for the terminal 150, the identity of the subscriber can be used to order the services of the subscriber's terminals based on the match of the identity of the subscriber used to order the service and the identity of the owner of the Terminal 150 to determine.

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

The security server 140 and the service store 190 may communicate with each other to identify a service subscribed to by the terminal 150 393, in response to the service being ordered or changed, or in response to the identity data 113 of the terminal 150 being verified .

In response to a service request 171 from the terminal 150, the security server 140 verifies 373 the identity data 113 of the terminal 150 provided in the service request 171.

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

After the security server 140 has checked 373 the identity and authenticity of the terminal 150, the security server 140 can, based on the client authorization data 283 stored in the security server 140 and/or based on the subscription data 387 in the service store 190, the service subscribed for the terminal 150 identify 393.

Based on the identified service, the security server 140 may communicate with the firmware store 170 to identify 375 a firmware update for the terminal 150. For example, the terminal 150 may be upgraded by replacing the firmware or installing a firmware application (e.g., App 367) updated to adapt the terminal 150 to the subscribed service. The firmware update can be performed and backed up in the same way as explained above in connection with 14 .

For example, the terminal 150 can be manufactured with a generic version of the firmware 363 that is unable to receive the service from the service provider 381, that has no knowledge of the client-server 141 for the service offered by the service provider 381 and/or or which has not implemented a communication protocol for communication with the client-server 141. A firmware application (e.g. App 367) running on the general firmware 363 can be installed to adapt the terminal 150 to the service ordered for the terminal 150. Once the terminal 150 has been customized via the firmware application (e.g., app 367), it can receive the service of the service provider 381 from the client-server 141. For example, after installing the firmware application (e.g., app 367) for updating 377 the firmware, the terminal 150 has knowledge of the client-server 141, communication ability to communicate with the client-server 141 according to a client-server Server 141 used communication protocol and the processing routines for using the service offered by the client-server 141 on.

For example, the service subscribed to for the operations of the terminal 150 may include the calculations performed by the client-server 141 for processing data for the terminal 150, storing data generated by the terminal 150 in the client-server 141, sending notifications and/or or alerts to one or more other devices connected to terminal 150, connecting terminal 150 via client-server 141 to a computer network or the Internet using a base station, Wi-Fi access point, communications satellite, and/or a client-server 141 controlled communications link or equipment, etc.

Optionally, after the firmware update 377, the terminal 150 is configured via its firmware 363 and/or a firmware application (e.g., app 367) to automatically visit the client-server 141 for the subscribed service. Alternatively, the security server 140 may redirect the terminal 150 to the client-server 141 to access the subscribed service 379 after verifying the identity data 113 of the terminal 150 having the updated firmware.

In general, the service store 190 can be used by a user (or a user representative) to subscribe to a service of a service provider 381 for the terminal 150, change a subscribed service, subscribe from one service provider 381 to another service provider to move. The firmware 363 of the terminal 150 is automatically updated to support the currently subscribed service without the user of the terminal 150 performing any operation on the terminal 150 to customize the terminal 150 for the subscribed service.

16 FIG. 12 shows a method for updating firmware using firmware storage and a security server according to one embodiment. For example, the process of 16 be implemented using the technique of 14 .

At block 401 a server system receives from a terminal 150 a request with identity data 113 generated by a storage device 130 configured in the terminal 150 .

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

The terminal 150 can be in a delivery state, for example, as is the case when terminals (eg 150) are manufactured, without an adaptation to specific servers and/or service providers being necessary.

At block 403, the server system, in response to the request received in block 401 and based on a secret code of the storage device 130 and the identity data 113, determines the authentication of the terminal 150. For example, the operations in block 403 can be carried out in a manner similar to those in block 323 and/or block 343 operated operations are performed.

The identity data 113 include, for example, a verification code 133 for a message 131 shown in the identity data 113. The security server 140 can check whether the verification code 133 was generated using a secret key 137 of the storage device 130 and the message 131, without the terminal having the secret Key 137 represents. The secret key 137 is generated using the unique device key 101 of the storage device 130 and device information 121 representative of the software and hardware configuration of the terminal 150 .

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

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

For example, order 391 for terminal 150 may be identified using a terminal 150 public identifier. The identity data 113 can include the public identification in the message 131 signed with the secret key 137 to generate the verification code 133 provided in the identity data 113 . After verifying that the message 131 has not been modified, the security server 140 can instruct the online firmware store 170 and/or the terminal 150 to update 377 the firmware 363 of the terminal 150.

At block 407, in response to a determination that terminal 150 is authentic, the server system generates verification code 153 for an instruction 155 executable on storage device 130 to perform the update.

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

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

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

The data downloaded to the storage device 130 may include, for example, a firmware application (e.g., App 367) running with the first firmware executed to generate the request after the update firmware command 155 is executed. A combination of the firmware application (e.g., App 367) and the first firmware provides a second firmware for the terminal 150.

For example, after executing the command 155 to update the firmware via the second firmware, the terminal 150 is configured to provide a function that was not present in the terminal with the first firmware before the update.

After the execution of the firmware update instruction 155 , the second firmware may become part of the identity of the storage device 130 and the terminal 150 . For example, based on device information 121, memory 130 is configured to generate a secret key 137 representative of the identity of memory device 130 and terminal 150. After the execution of the firmware update 377 instruction 155 , the device information 121 is updated to include as content 161 a hash value 163 of the second firmware stored in the memory cells 103 . Subsequently, the storage device 130 is configured to generate identity data 113 of the terminal 150 using a cryptographic key which is based at least in part on the secret code (e.g. the unique device key 101) of the storage device and the second firmware stored in the storage device 130 is generated.

17 FIG. 12 shows a method for adapting terminals using a service store and a security server according to an embodiment. For example, the process of 17 be implemented using the technique of 14 and 15 .

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

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

At block 423, the security server 140 verifies the identity data 113 in response to the request received in block 421 and based on the information stored in the security server 140 about the terminal device 150. This information includes a secret code of the storage device 130, for example the unique device key 101. This information may also include device information 121 that represents the software/hardware configurations of the terminal device 150 . The verification can be performed in the same manner as explained above in connection with 2 .

In response to determining that the identity data 113 in the request received in block 421 is valid, the server system identifies in block 425 a service ordered from the online service store 190 for the terminal device 150.

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

For example, before receiving the request in block 421, the online service store 190 may store an order 391 of the service for the terminal 150. The client-server 141 can be identified based on the order 391 .

For example, the order 391 can be received in the online service store 190 via a user computer 180 and thus without a detour via the terminal device 150 . The order 391 may be identified/placed for the terminal 150 using a public terminal 150 identification. The identity data 113 can include the public identification. Alternatively, the order 391 may be associated with the identity of a user as the owner of the terminal 150 in the client credential data 283 of the security server.

At block 429 the server system forwards the terminal 150 to the client-server 141 .

For example, in response to determining that the identity information 113 in the request received in block 421 is valid, the server system may configure the terminal 150 for the service ordered from the online service store 190 .

In order to configure the terminal 150 for the service, the server system can update the firmware of the terminal 150, for example. For example, the firmware update can be performed in the same way as described above in connection with the 14 until 16 was explained.

For example, before the firmware update 377 , the terminal 150 is unable to receive the service from the client-server 141 and has no knowledge of the client-server 141 . For example, terminal 150, as initially configured by a terminal manufacturer (e.g., 150), is programmed to include service store 190, firmware store 170, security server 140, or other gatekeeper visited so that terminal 150 can be properly configured and/or updated for use without the end user having to perform any operation on terminal 150 to customize it.

For example, after firmware update 377 , a second firmware is stored in storage device 130 to replace the first firmware used to generate the request received in block 421 . When the terminal 150 runs the second firmware, the terminal has a function that the terminal with the first firmware before the firmware update 377 did not have. For example, the second firmware may include an identification of the client-server 141 to instruct the terminal to visit the client-server 141 for the service ordered from the online service store 190 . In some implementations, the second firmware is a combination of the first firmware and an additional firmware application. After the firmware update 377, the storage device 130 is configured to generate the updated identity data 113 of the terminal device 150 using a secret key 137, which is based at least in part on the secret code (e.g. the unique device key 101) and the in the Storage device 130 stored second firmware is generated.

Optionally, in order to configure the terminal 150 for the service ordered from the service store 190, the server system identifies an account that is used to subscribe the terminal 150 to the service. The storage device 130 is configured to store an identifier of the account and to include the identifier in the updated identity data 113 as part of the message 131 .

For example, to perform the firmware update 377 , the server system may generate a verification code 153 for an instruction 155 using a cryptographic key 145 that has authorization to execute the instruction 155 on the storage device 130 . When executed on storage device 130, instruction 155 causes the first firmware to be replaced with the second firmware. After storage device 130 receives command 155 and verification code 153, storage device 130 checks verification code 153 for authorization before executing command 155.

The security server 140 can be used not only to verify the identification of a terminal 150 based on the security features of a storage device 130 configured in the terminal 150, but also to verify the integrity of packets stored in the storage device 130 and/or in stored in terminal 150. A package stored in the terminal 150 can be, for example, a boot loader, firmware, software, a module, at least part of an operating system or an application, a set of files with information about resources, configuration parameters and/or other data of a program or a routine etc. If a packet is found to be corrupted, modified, tampered with, or out of date, the security server 140 may initiate an over-the-air (OTA) update to maintain the integrity of the terminal 150.

Storage device 130 may store content 161 in storage cells 103 and separately store a hash value 163 as part of device information 121, as illustrated in FIG 4 . If the current hash value calculated from the content 161 stored in the memory cell 103 does not match the expected hash value 163 stored as part of the device information 121, the storage device 130 may allow the modification or corruption of the content 161 detect and initiate repair of the content.

Content 161 may include a core packet of terminal 150, for example. The integrity of the core packet may affect the operations of the terminal 150 in communicating with the security server 140 in verifying 373 the identity of the terminal 150 . Examples of a core package may include a boot loader, firmware, and/or at least a portion of the terminal 150 operating system. If the core package is modified, corrupted, or tampered with, the security of the terminal 150 operations performed to verify identity may not be trusted. If the integrity status 165 generated by the cryptographic engine 107 indicates a change in the core package, the access controller 109 can prevent the host system 120 from accessing the content 161 until the core package is repaired.

For example, storage device 130 may store a reliable backup copy of the core package in a separate section; and if the core packet in the content 161 stored in the storage cells 103 has a hash value different from the corresponding hash value 163 stored for the device information 121, the storage device 130 can use the copy stored in the separate section to replace the core packet stored in memory cells 103. Optionally, execution of the replacement copy in terminal 150 may be configured to start a recovery process to obtain a current version of the package from a reliable source, such as firmware store 170. Alternatively, the security server 140 may initiate the update (e.g., using the firmware store 170) after verifying the identity information 113 of the storage device 130 and/or terminal 150 communicated via the backup copy.

Some packets stored in the memory cells 103 do not affect the security of the initial operations to verify 373 the identity data 113 of the terminal 150 and the subsequent operations to update the terminal 150. Thus, it is not necessary to have a recovery copy of these packets in the storage device 130 to save. The repair and/or update of these packages can be performed via the security server 140 . For example, if integrity status 165 indicates that a non-core packet has changed, access controller 109 can block host system 120 from accessing the corrupted or changed packet until terminal 150 communicates with security server 140 to recover the corrupted packet to repair or restore.

Optionally, the data 127 provided in the identity data 113 can contain the current hash value of a packet in the content 161 stored in the memory cells 103 . During operations to verify 373 the identity data 113 of the terminal 150, the security server 140 may verify the current hash value provided in the identity data 113 for the packet. If the current hash value of the packet indicates that the packet is modified, corrupted, or out of date, the security server 140 can initiate repair or recovery of the packet.

Furthermore, some packets of terminal device 150 may be stored in another device that does not have the security features of storage device 130 . Execution of the core packet in the host system 120 may generate the current hash values of the packets as state identifiers of the packets. The state identifiers may be provided as part of the data 127 embedded in the identity data 113 of the terminal 150 to enable the security server 140 to monitor the integrity of the packets.

In general, the identity data 113 can contain data that provide information about the status of the packets in the terminal device 150 . As part of the operations for verifying 373 the identity data 113 of the terminal 150, the security server 140 may determine whether any of the packets should be repaired and/or updated. The repair or update may be performed before the security server 140 confirms the authenticity of the terminal 150.

Furthermore, in response to the verification 373 of the identity data 113 of the terminal 150 for accessing services from client-servers (e.g. 141, ..., 143), the security server 140 can be configured to monitor the activities of the terminal 150 upon access to track and/or monitor services in order to implement further operations to ensure security.

For example, an owner or user of terminal 150 may request security server 140 to track terminal 150 activities. Aspects of the activities of the terminal 150 can be represented by the terminal 150 and/or the client-servers (e.g. 141, ..., 143) in the identity data 113 and/or in the requests 173 for verifying the identity data 113 .

The information about the tracked activities can contain, for example, location information of the end device 150 and/or the type of services requested by the end device 150 by transmitting the identity data 113 .

For example, in order to generate the identity data 113 for a service from the client-server 141, the terminal device 150 in the message 131 of the identity data 113 can contain not only the unique identification 111 of the terminal device 150, but also the context and/or the aspects of the service such as client-server 141 identification, terminal 150 location, request date and time, service category/type, service parameter, etc.

For example, if the terminal 150 sends a request 171 for a service to a client-server 141, the client-server 141 can provide not only the identity data 113 of the terminal 150 in the request to the security server 140, but also information about the request 171 for the service of the client-server 141.

For example, in response to a request 171 from terminal 150, client-server 141 may estimate the location of terminal 150 based on a wireless communication link to one or more access points associated with client-server 141 and the location provide the security server 140 in connection with the request 173 for authentication of the identity data 113.

Optionally, the owner or user of the terminal 150 can visit a portal of the security server 140 to view the tracked activities. For example, the owner or user can determine if the terminal 150 has been stolen or lost based on the activities tracked based on one or more current locations.

Optionally, a parent may use the security server 140 portal to set parental control settings to restrict terminal 150 activities; and the security server 140 may implement the restriction settings in connection with the authentication of the terminal 150 identity.

18 illustrates the generation of identity data to facilitate monitoring of the integrity and/or activities of a terminal according to one embodiment.

For example, the technique of 18 in a computer system of 1 and or 6 with the in the 1 until 5 security services and features explained. The technique of 18 can be combined with the techniques of 9 until 17 be used.

In 18 the terminal 150 stores a packet 167 which has a hash value 169. Packet 167 may be stored in storage device 130 having the security features discussed above, or stored in another storage device of terminal 150, which may or may not have security features of storage device 130 . When the packet 167 is stored in the storage device 130, the cryptographic engine 107 of the storage device 130 can calculate the hash value 169 of the packet 167 without relying on the processing device 118 of the host system 120 in the terminal 150. If the packet 167 is stored outside of the storage device 130, the hash value 169 may be obtained by the processing device 118 of the host system 120 executing a routine that is stored in the storage device 130 and has been checked to determine that it is not was changed (e.g. as in 4 ).

In general, packet 167 may include instructions and/or data, such as resources that are common to a set of terminals (e.g., 150) and configuration parameters that are shared from one terminal (e.g., 150) to another terminal may vary.

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

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

After the security server 140 has determined that the identity data 113 is valid, the security server 140 can extract the hash value 169 provided in the identity data 113 to determine whether the packet 167 has been modified in the terminal 150 and/or whether the packet 167 is no longer up-to-date.

For example, a working and up-to-date copy of package 167 may be stored on a server (e.g., security server 140, firmware store 170, or other server) to facilitate repair or recovery of package 167 in terminal 150. If the hash value 169 extracted from the identity data 113 differs from the hash value of the functional and current copy, the security server 140 can initiate an update in a similar manner to the update 377 of the firmware 363 of the terminal 150, as in connection with the 14 until 17 explained.

The packet 167 can be individualized for the terminal 150. For example, if package 167 includes configuration parameters that are specific to terminal 150 in a platform 361 but not applicable to other terminals in platform 361, after successfully configuring package 167 in terminal 150, a working copy of package 167 can appear the server (e.g., the security server 140, the firmware store 170, or another server).

In some implementations, the storage device 130 and/or the terminal 150 may be configured to store the hash value of the operational, individualized copy of the packet 167 . For example, the healthy hash value can be stored as part of the device information 121 used to create the secret key 137 . The message 131 in the identity data 113 can contain an identifier that indicates whether the current package 167 is functional, without the current hash value 169 of the package 167.

For improved security and/or privacy protection, the operational copy of the customized package 167 can be uploaded to and stored on the server in encrypted form using a cryptographic key of the storage device 130 . To reinstall package 167 using the working copy, storage device 130 decrypts the encrypted version using a corresponding storage device 130 decryption key.

For example, upon successful configuration of customized package 167 in terminal 150, terminal 150 and/or storage device 130 may calculate the hash value of the operational copy of customized package 167 and use public key 139 to encrypt customized package 167. The terminal 150 may transmit the hash value and the encrypted packet 167 for storage on the server to facilitate monitoring and/or recovery. During recovery, the secret key 137 in the key pair 135 is to be used to decrypt the encrypted packet. Optionally, the cryptographic engine 107 can generate a separate key pair to secure the individualized packet 167.

Alternatively, a secret key with symmetric cryptography can also be used to protect the individualized packet 167. A session key 263, which was generated during the verification of the identity data 113 of the terminal device 150 at the time of the successful configuration of the individualized packet 167 in the terminal device 150, can be used, for example, to encrypt the individualized packet 167 in order to send it to the server (e.g (e.g. the security server 140, the firmware store 170 or another server) and/or store it there.

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

For example, the activity information 177 can contain the current location of the terminal device 150, with the identity data 113 being generated.

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

For example, the activity information 177 can contain an identification of the client-server 141 to which the identity data 113 are transmitted in order to request a service 171 .

For example, activity information 177 may include one or more attributes of the requested service, such as a category of service, an identification of another party involved in the service, an amount or quantity involved in the service, etc.

For example, if identity data 113 is transmitted for a communication link, the attributes may include identification of the link type, name of the link, and so forth.

For example, if identity data 113 is submitted for a payment, the attributes may include identification of a purchase category, payee, payment amount, and so on.

The activity information 177 can be used by the security server 140 to detect fraudulent activity and unauthorized uses of the terminal and to enforce activity restrictions (e.g. as specified in parental control settings), etc.

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

19 FIG. 11 illustrates a technique for maintaining the integrity of packets stored on a terminal, according to one embodiment.

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

A core package 441 stored in the storage device 130 may be executed in the processing device 118 of the host system 120 connected to the storage device 130 in the terminal 150 . The packet 441 controls the operations of the terminal 150 in transmitting the identity data 113 of the terminal 150 to the security server 140 and in communicating with a packet store 191 to repair and/or update packets 441, 443, ..., 445. The package repository 191 can be, for example, the firmware store 170 of the 14 and 15 include.

The security features of the storage device 130 ensure that a valid version of the packet 441 is executed in the terminal 150 to avoid tampering and/or corruption in terminal 150 identity verification 373 and packet repair 385 operations.

For example, the storage device 130 may store a backup version of the core package 441 in a secure area of the storage device 130 . If the package 441 has a change, the storage device 130 may replace the changed version of the package 441 with the backup version to perform at least the operations of verifying 373 the identity of the end rats 150 and for repairing 385 and/or updating 377 the packages.

After the terminal 150 has generated the identity data 113, the terminal 150, which executes the package 441, transmits the identity data 113 to the security server 140 for verification 373. The identity data 113 can be generated, for example, using the technique of 18 .

The identity data 113 can contain information about the functional status of the packages 447, for example current hash values of the packages 441, 443, ..., 445, and/or information as to whether one of the packages 443, ..., 445 is damaged, based on a comparison of the current hash values and the stored hash values of function versions of the respective packages.

Optionally, a portion of message 131 may be provided as ciphertext generated using session key 263 . For example, the encrypted portion of the message may include package 447 health information and/or activity 177 information. The session key 263 may be generated to be shared by the storage device 130 and the security server in connection with the verification 373 of the identity of the terminal 150, as in FIG 9 explained.

In general, the identity data 113 can be transmitted from the terminal 150 to the security server 140 directly via a communication link or indirectly via an intermediate server, for example a client-server 141 as in 5 , 9 , or 10, a firmware store 170 in 14 or 15 , a service store 190 in 15 , or the package repository 191 from 19 .

After checking 373 the identity data 113, the security server 140 can communicate with the package repository 191 in order to check the integrity of the packages 441, 443, . . . , 445 based on the package information 447 provided in the identity data 113.

For example, the packet 441 in the terminal 150 can be checked. However, as a new version of package 441 is released to package repository 191, package 441 may become obsolete. Thus, by updating the packet 441, the security of the operations of the terminal 150 and the integrity of the system can be improved.

For example, packet 443 or 445 may have changes in terminal 150 and thus become corrupted. The state data 195 of the corresponding packages 193 in the repository 191 can be compared with the package state information 447 provided in the identity data 113 in order to detect the change.

If a package (e.g. 441, 443, ..., 445) is detected as obsolete or corrupt, the security server 140 can instruct the terminal 150 and/or the package repository 191 to repair 385 or 377 the package To update.

The operation to repair 385 or update 377 a package may include the security server 140 generating a verification code 153 for a command 155 to write data to the storage device 130 . If a packet contains sensitive information, such as configuration parameters customized for terminal 150, the replacement packet may be provided in storage device 130 as ciphertext generated with session key 263 or another secret key.

After repairing 385 or updating 377 the terminal 150 can transmit the updated identity data 113 . If the security server 140 determines that the identity data 113 is valid and the packet information 447 in the identity data 113 indicates that the packets 441, 443, ..., 445 in the terminal 150 are intact and up to date, the security server 140 certify the authenticity of the terminal 150.

20 12 shows a system that implements security operations based on tracking activities of a terminal according to an embodiment.

For example, the security operations of 20 in combination with the techniques from the 9 , 10 , 14 , 15 , and/or 19, using security features in the storage devices associated with the 1 until 5 , have been explained, and in combination with the systems of 1 and/or 6 can be implemented.

In 20 For example, a user computer 180 may be used to visit an activity tracker 451 to set preferences 455 and/or review tracked activity records 453 of the terminal 150 having the unique identifier 111.

As in the 14 and 15 , user computer 180 is typically distinct and separate from terminal 150. In some instances, terminal 150 may include a user interface that allows computer 180 to set user preferences 455 and/o to be used for reviewing activity records 453.

The activity tracker 451 is coupled to a security server 140 to store activity records 453 about the activities of the terminal 150 in which the identity data 113 of the terminal 150 is verified by the security server 140 .

Preferences 455 may include security settings for terminal 150 activities. For example, the security settings may be implemented to implement parental controls, detect fraudulent use of the terminal 150, track the location of the terminal 150, etc.

For example, references 455 may identify a geographic region for terminal 150. If the terminal 150 sends identity data 113 from a location outside of the geographic region, the activity tracker 451 may generate a security alert to a registered owner or user of the terminal 150 .

For example, the security notification may be delivered to an 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, cell phone, smartphone, etc will.

Preferences 455 may include, for example, a user-selected option associated with a predetermined condition specified in preferences 455 . If an activity associated with the transmission of the identity data 113 satisfies the condition, the selected option causes the security server 140 and/or the client-server 141 to generate a rejection in an access response 172 for the corresponding access request 171. Alternatively or in combination, the option may trigger a security alert to a contact registered in Settings 455.

The terminal 150 can transmit the access request 171 to the client-server 141 to request a service. For example, the service may provide the terminal 150 with a cellular connection, an Internet connection, a connection to the user's computer 180, online storage, an online computing resource, and so on. For example, the service may involve the processing of a payment, a transaction, a message, and so on.

The identity data 113 provided in the access request 171 may include activity information 177, as illustrated in FIG 18 . Alternatively or in combination, the client-server 141 may provide similar or separate activity information in the verification 173 requested to the security server 140 . For example, the client-server 141 may specify access attributes 449 in the request 173 validation. The access attributes 449 identify certain aspects of the current activity of the terminal 150 for which the identity of the terminal 150 is to be authenticated by the security server 140. The client-server 141 transmits the verification request 173 to the security server 140, which verifies the identity data 113 to determine the authenticity of the identity of the terminal 150.

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

Based on the activity record 453, the activity tracker 451 determines whether the current activity meets any of the conditions set in the preferences 455. When a condition in the settings 455 is met, the activity tracker 451 can run a security operation to implement an option selected for the condition.

The security operation may include, for example, a notification to a register holder or user of the terminal 150.

The security operation may include, for example, directing the security server 140 to provide a verification response 174 indicating a security restriction, a security issue, unauthorized use of the terminal 150, and so on.

Optionally, the activity tracker 451 can identify a pattern of activities of the terminal device 150 from past activity records 453 .

For example, the pattern may include a geographic area or region of the terminal 150 in which the terminal 150 operated in the past. The pattern can include, for example, a time in a day or in a week when the end device 150 has no past activity. The pattern may include, for example, an access attribute 449 portion of past terminal 150 activities.

If the current activity deviates from the pattern, the activity tracker 451 can generate a notification and optionally cause the security server 140 and/or the client-server 141 to deny the access request 171 .

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

For example, the date and time and/or location specified in the activity information 177 can be compared to the corresponding information in the access attributes 449 to identify inconsistencies. A mismatch may be an identifier for the use of stolen identity data 113, for tampering with the terminal 150, or for insecure operations.

21 FIG. 12 shows a method for updating or repairing a package stored in a terminal according to an embodiment. For example, the process of 21 be implemented using the techniques from 18 and 19 .

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

For example, the server system may include a security server 140 that stores secrets from storage devices (e.g., 130) and/or other servers, such as a package repository 191, firmware store 170, and/or other server stands.

At block 463, the security server 140 verifies the identity data based on the information stored in the security server 140 about the terminal device 150, including a device key in the storage 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.

In block 465, the security server 140 extracts the health information 447 of a package (e.g. 167, 441, 443, ..., 445) stored in the terminal 150 from the identity data 113 that has been verified.

The status information 447 can contain, for example, a current hash value 169 of the packet 167 as it is stored in the terminal device 150 . The security server 140 can compare the current hash value 169 extracted from the identity data 113 with a hash value of a functional, current version of the package 167 stored in the server system (e.g. in the repository 191, the firmware store 170).

Receiving the identity data in block 461 may be the result of the terminal 150 executing the packet 167 as stored in the terminal 150, for example. The package 167 can contain at least part of the firmware 363 or an operating system of the terminal device 150 . The state information 447 can be used to determine whether the package 167 is out of date.

In another example, receiving the identity data in block 461 may be the result of the terminal 150 executing a first packet 441 as stored in the terminal 150 . The first package 441 can contain at least part of the firmware 363 or an operating system of the terminal device 150 . State information 447 can be used to determine whether a second package (e.g., 443 or 445) is out of date, corrupt, or modified.

If the second packet (e.g. 443 or 445) contains data adapted for the terminal 150. The server system may receive a copy of the second package (e.g. 443 or 445) at the time the second package (e.g. 443 or 445) is successfully configured in the terminal 150. The second packet (e.g. 443 or 445) may contain one or more configuration parameters of the terminal device 150, for example. In response to successfully configuring the second packet (e.g., 443 or 445), the server system may receive an operational version of the second packet (e.g., 443 or 445) from the terminal 150. Thereafter, if the state information 447 extracted at block 465 indicates that the second package (e.g., 443 or 445) needs to be repaired, the working version stored in the repository 191 can be used.

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

The identity data 113 includes a first verification code 133. The security server 140 verifies the identity data 113 by determining whether the first verification code 133 was generated from the message 131 and the identity of the storage device 130. The secret can be the unique device key 101 in the memory 130 and/or the secret key 137, for example. The secret code of the storage device 130 is not transmitted outside the storage device 130 after the storage device 130 is built into the terminal 150. FIG.

At block 467, the security server 140 blocks, at least in part, with the state information 447 that the package stored in the terminal 150 requires an update or repair.

At block 469, the security server 140 initiates an operation to perform the update or repair on the package stored in the terminal 150.

For example, to replace or repair a package stored on storage device 130, security server 140 generates a second verification code 153 for an instruction 155 using a cryptographic key that represents authorization to execute instruction 155 on storage device 130. For example, instruction 155, when executed on storage device 130, causes the packet (e.g., 441 or 443) to be replaced on storage device 130.

In some implementations, to repair a package 445 stored off storage device 130, a replacement of package 445 is first stored on storage device 130. After the storage device has verified the integrity of the replacement, the package 445 may be replaced by executing instructions in a package 441 loaded from the storage device 130 . Optionally, a second verification code 153 may be generated to write the replacement to the storage device 130 and/or allow a repair or replacement of the package 445 to be performed.

22 FIG. 12 shows a method for performing a security operation based on one or more activities of a terminal according to an embodiment. For example, the process of 22 be implemented using the techniques from 18 and 20 .

At block 481 , a server system stores data representing one or more preferences 455 for a terminal 150 .

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

At block 483, the server system receives a verification request 173 with identity data 113 generated by a storage device 130 configured in the terminal 150.

At block 485, the server system determines that the identity data 113 is valid based at least in part on an identity of the storage 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 an activity associated with the identity data 113 meets a condition specified for the terminal 150.

The condition can be specified in the preferences 455 for the terminal 150, for example. if

At block 489, the server system performs a security operation associated with the condition by providing a verification response 174 in response to the verification request 73. FIG.

The operation may include, for example, transmitting an alert or notification to a contact registered in one or more references 455.

For example, the security operation may include identifying a security risk or limitation in the validation response 174 . Optionally, the security server 140 can provide the verification response 174 that does not confirm the authenticity of the terminal device 150 even if the identity data 113 has a valid verification code 133, given the secret key 137 of the storage device 130 and the message contained in the identity data 113 131. If the activity associated with the identity data 113 satisfies the condition, the verification response 174 may be configured to cause a client-server to issue a request 171 for a service to the terminal 150, as indicated by the identity data 113 identified to reject.

The condition may be assessed for the activity based on activity information 177 embedded by storage device 130 in identity data 113 and/or access attributes 449 provided by client-server 141 in verification request 173 .

For example, after the security server 140 has determined that the verification code 133 in the identity data 113 is valid, the security server 140 can trust that the activity information 177 embedded in the identity data 113 has not been altered after the storage device 130 generated the verification code 133. Thus, the activity information 177 can be extracted from the identity data 113 for evaluating the condition. Optionally, the activity information 177 can be provided in the message as ciphertext, which is encrypted using one of the methods specified in 9 explained manner generated session key 263 or another secret cryptographic key for decryption in the storage device 130 is to be decrypted.

Alternatively or in combination, the security server 140 can extract access attributes 449 from the verification request 173 . For example, the client-server 141 may generate the verification request 173 to the security server 140 after receiving the access request 171 for a service provided by the client-server 141 . The verification request 173 is generated to include the identity data 113 from the access request 171 . Further, the client-server 141 may add the access attributes 449 to provide information about the activity of the terminal 150 in the context of requesting the client-server 141 service.

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

In some implementations, the server system communicates with a user computer 180 to receive the data representing one or more preferences 455 for the terminal 150.

Alternatively, or in combination, the server system may derive the preferences 455 from the historical activity records 453 .

For example, a server system activity tracker 451 may store a plurality of records 453 of terminal 150 activities. Based on the plurality of records 453, the activity tracker 451 can determine a pattern of the terminal 150 activities. The pattern may include a geographic area, a point in time in a day or week, or an activity attribute area, or any combination thereof. A condition to trigger the security operation of block 489 may be satisfied by non-pattern activity.

Optionally, the activity tracker 451 may present the activities of the terminal 150 to an owner or authorized user of the terminal 150 based on the records 453 . For example, the owner or authorized user can set conditions for implementing parental controls, access restrictions, etc. based on a review of past activities.

The identity of a terminal 150, authenticated by the security server 140, can be dynamically associated with a subscription account, represented by an account identifier, to receive the services provided by a client-server 141 for the account. If the terminal 150 is not using the Services, the association between the identity of the terminal 150 and the subscription account may be removed to allow another terminal to use the subscription account. Thus, a group of terminals (e.g. 150) can be configured to share the subscription account and use the subscription account at any given time.

For example, a group of terminals may be configured to use a client-server 141 service for cellular connections. Traditionally, a subscriber identification module (SIM) card is used to represent a subscriber/subscription account. The group of terminals can use the subscription account represented by the SIM card by installing the SIM card in a terminal of the group at a certain point in time. In order to allow another terminal in the group to use the subscription account, the SIM card has to be physically moved from one terminal to another terminal.

A system like the one above in conjunction with 6 was explained, allows the use of a virtual subscriber identification module (vSIM) on a terminal (z. B. 150) through a virtual card registration 237 based on of identity verification or terminal authentication 239 performed using the security server 140. The system of 6 may be further configured to separate the terminal (e.g., 150) from the card profile 219 representing the subscription account so that the virtual card registration 237 can be performed for another terminal to use the subscription account.

For example, a subscribed service (e.g., a cellular connection) provided to a subscription account may be shared among a number of terminals owned by a business (or other entity). The terminals (e.g. 150) in the population may not require the account's service at the same time. Thus, it may be advantageous to configure the terminals in the population to share one or more subscription accounts. When more than one subscription account is configured to be shared by the population of endpoint devices (e.g., Internet of Things (IoT) devices), a small portion of the population can use the services subscribed to for the accounts at the same time.

For example, a server system can be configured to track the current usage states of the terminals in the population. When a terminal communicates with a client-server to request a service, the terminal can be dynamically bound to a subscription account. If the end device is no longer actively using the service, the subscription account can be released from the end device. If the number of terminals actively using the services provided for the subscription accounts is not greater than the number of subscription accounts available for sharing, the active terminals can use the services of the accounts at the same time. If the subscription accounts are currently bound to and actively used by part of the population, a request for service from another terminal may be denied until one of the subscription accounts is released from active use and thus becomes available for sharing.

For example, a virtual subscriber identification module (vSIM) may be bound to an enterprise Internet of Things (IoT) device in response to the IoT device's request for a cellular connection. If the cellular connection has been idle for a period longer than a threshold, the cellular connection may be disconnected; and the virtual subscriber identification module (vSIM) can be shared by the IoT device and made available to connect to another enterprise IoT device. Thus, the enterprise can subscribe to a reduced number of vSIMs, and when all vSIMs are used, the request for a cellular connection from another device can be queued until one of the connections is disconnected and a vSIM is queued for assignment to the device becomes free.

Optionally, the security server 140 can be configured to throttle and/or schedule the forwarding of requests to control the use of the limited number of subscribed cellular connections.

23 and 24 12 illustrate systems configured to implement subscription sharing among a group of terminals, according to one embodiment.

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

The terminal group 501 has a large number of unique identifiers 111,...,112. Each of the unique identifiers (e.g. 111) represents a storage device (e.g. 130) installed in a corresponding terminal (e.g. 150) in a group of terminals.

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

For example, subscriber identity number 505 may be used to represent a unique subscriber, just as a subscriber identification module (SIM) represents a subscriber in a cellular network.

When the SIM card is inserted into a mobile phone, a communication link is established with the subscriber; and the mobile phone is provided with the services on the subscriber's account. If the SIM card is inserted into another mobile phone, the communication link to the subscriber is established with the other mobile phone that currently has the SIM card.

Likewise, when the subscriber identity numbers 505 are associated with the unique identifier 111, the services offered to the account of the subscriber represented by the subscriber identity numbers 505 are provided to the terminal 150 having the unique identifier 111. When the subscriber identity numbers 505 are associated with an alternative unique identifier 112 , the services offered to the subscriber's account represented by the subscriber identity numbers 505 are provided to an alternative terminal having the unique identifier 112 .

In 23 the security server 140 is configured to dynamically link a subscriber identity number 505 from the subscriber group 503 and a unique identifier 111 from the terminal group 501 .

For example, in response to a verification request 173 from client-server 141 that includes identity data 113 , security server 140 may determine whether identity data 113 includes a valid verification code 133 for a storage device 130 with unique identifier 111 . If the identity data 113 is valid, the security server 140 can determine whether the subscriber group 503 currently has a subscriber identity number 505 that can be used by the storage device 130 and/or the terminal 150 with the unique identifier 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 terminal 150 with the services offered for the account identified by subscriber identity number 505 .

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

The verification requirement 173 in 23 may include access attributes 449 specifying a requested time period for mapping the unique identifier 111 identified in the identity data 113 to an available subscriber identity number (e.g., 505) for use by the terminal 150 having the unique identifier 111, specify.

In some implementations, the system is configured to associate the unique identifier 111 and the subscriber identity number 505 with the unique identifier 111 and/or identity data 113 for a predetermined period of time after the verification response 174 identifying the subscriber identity number 505 . After the predetermined period of time, the service store 190 disassociates the subscriber identity number 505 from the unique identifier 111 and makes the subscriber identity number 505 available for use by another terminal with a different unique identifier (e.g., 112) in the terminal group 501. After the predetermined period of time, the client-server 141 will not provide the services offered for the account represented by the subscriber identity number 505 to any of the terminals (e.g. 150) with the unique identifiers 111, ..., 112 in the terminal group 501 available until it has another verification response 174 from the security server 140 linking the subscriber identity number 505 to one of the unique identifiers 111,...,112 in the terminal group 501.

If the terminals with the unique identifiers 111, ..., 112 compete in the use of the subscriber identity numbers (e.g. 505) from the subscriber group 503, the service store 190 can allocate the use of the subscriber identity numbers (e.g. 505 ) in the subscriber group 503.

For example, the service store 190 can track the terminals in the group 501 that have rejected access requests for lack of available subscriber identity numbers 505 and prioritize the subsequent assignments of available subscriber identity numbers 505 based on tracked priorities.

For example, when the subscriber identity number 505 is available for use, the service store 190 can open a time window in which access requests can be received from different terminals; if multiple access requests for the group 501 are received, a terminal with the earliest request that was rejected before the timeslot may have the highest priority in order to be given the opportunity to use the subscriber identity number 505.

In some implementations, the terminals having unique identifiers 111,...,112 in terminal group 501 may compete for the opportunity to identify the subscriber identity numbers (e.g., 505) in subscriber group 503 based on one or more predefined ten rules to use. For example, after receiving a rejection of a request, a terminal (e.g., 150) may wait a random amount of time to make another request. The randomness of the waiting times after a rejection allows the opportunities to use the subscriber group 503 for service access to be distributed to terminals that require services.

In some implementations, a terminal 150 that has been temporarily assigned a subscriber identity number 505 may inform the client-server 141 and/or the security server 140 to release the subscriber identity number 505 from assignment to the terminal 150. For example, after terminal 150 has completed the communication using a service provided for subscriber identity number 505, subscriber identity number 505 may be returned to a pool of subscriber identity numbers in group 503 assigned to another terminal with a unique identifier 112 in group 501 assigned to and/or used by.

In some implementations, the system can track the active activities of terminal 150 using subscriber identity number 505 . After a period of inactivity, the service store 190 may disassociate the subscriber identity number 505 from the unique identifier 111 .

23 12 illustrates a configuration wherein the assignment of a subscriber identity number 505 to a unique identifier 111 is controlled by a security server 140 in response to a verification request 173 and/or a verification response 174. FIG. Alternatively and/or in combination, the client-server 141 can be connected to the service store 190 to implement the assignment and/or to use the assignment to provide a service, as described in 24 is illustrated.

In 24 , the client-server 141 is coupled to a service store 190 and an activity tracker 451 . Based on the verification response 174, which indicates the authenticity of the terminal 150 with the unique identifier 111 and the availability of the subscriber identity number 505 for use in the terminal group 501, the client-server 141 can cause the service store 190 to store data that the specify temporary assignment of the subscriber identity number 505 for unique identification 111.

The client-server 141 can then use the activity tracker 451 to determine whether to remove the association with the subscriber identity number 505 from the unique identifier 111 .

For example, after an inactive period of predetermined duration in which the terminal 150 does not use the services offered to the account represented by the subscriber identity number 505, the client-server 141 can cause the service store 190 to update the subscription data 387 and to end the assignment of the subscriber identity number 505 to the unique identifier 111.

For example, after receiving an identifier or notification from terminal 150, client-server 141 may cause service store 190 to stop associating subscriber identity number 505 with unique identifier 111.

In some implementations, the client-server 141 may cause the service store 190 to de-associate the subscriber identity number 505 with the unique identifier 111 after a period of time following the association of the subscriber identity number 505 with the unique identifier 111 . The period of time can be predetermined or can be determined from an access request 171 received from the terminal device 150 .

25 FIG. 12 shows a method for facilitating the sharing of subscriptions in a group of terminals according to an embodiment. For example, the procedure of 25 using the above in conjunction with the 23 and 24 explained techniques are implemented in a system with security features that are used in conjunction with the 1 until 19 was explained.

At block 521, a server system stores data by which a terminal group 501 is associated with at least one subscriber identifier (e.g., identity number 505). The terminal group 501 may comprise a plurality of terminals (e.g. 150) identified by unique identifiers 111,...,112.

For example, the server system may include a security server 140 that stores secrets from storage devices (e.g., 130) and/or other servers, such as a service store 190, an activity tracker 451, a package repository 191, a Firmware Store 170 and/or another server is available. The server system may further include a client-server 141 and/or a map server 223, as illustrated in FIG 6 .

At block 523, the server system receives a verification request 173 with identity data 113 generated by a storage device 130 configured in a terminal 150. The identity data 113 identify the terminal 150 based on its unique identifier 111, which is in the terminal group 501.

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

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 the subscriber identifier (e.g., subscriber identity number 505 ) is not currently assigned to any terminal in terminal group 501 .

At block 529, the server system assigns the subscriber identifier to terminal 150 based on the data associated with terminal group 501 having the subscriber identifier (e.g., identity number 505). The assignment causes the terminal to be provided with a service for an account represented by and/or associated with the subscriber identifier (e.g. identity number 505).

For example, the subscriber identifier (e.g., identity number 505) represents a unique subscriber to the service provided in a network (e.g., 225) having multiple terminals (e.g., 150), including the plurality of End devices from end device group 501 and other end devices that are not in end device group 501.

For example, the network (e.g., 225) can be configured to provide the terminal with services such as a cellular connection, an Internet connection, a connection to a user's computer, an online storage facility, an online computing resource, a payment, a transaction or a message or any combination thereof.

For example, assigning the subscriber identifier (e.g., identity number 505) to terminal 150 includes configuring terminal 150 to have a unique identity identified by the subscriber identifier (e.g., identity number 505) on a network (e.g., B. 225) is shown.

For example, the network (e.g. 225) may require different terminals in the network (e.g. 225) to have different identities represented by different subscriber identifiers (e.g. identity number 505). The identity data 113 generated in the storage device 130 does not contain any subscriber identification. The identity data 113 and/or unique identifier 111 of the storage device 130 and/or the terminal 150 may be dynamically assigned or associated with a subscriber identifier (e.g. identity number 505) to identify the terminal 150 to the service network (e.g. B. 225) to configure.

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

For example, the server system may remove the data representing the assignment of the subscriber identifier to the terminal after the period of time to de-subscribe the terminal 150 receiving the service on the network. After the data has been removed, the terminal 150 no longer has the identity of the subscriber represented by the subscriber identifier (e.g. identity number 505) in the service network (e.g. 225).

For example, the server system may monitor the activities of the terminal 150 in receiving the service as a subscriber in the service network (e.g., 225), and in response to detecting a time of inactivity of the terminal 150 in receiving the service as a subscriber in the network (e.g., 225), the server system may remove the data to reconfigure the terminal 150 to use the subscriber's identity, represented by the subscriber identifier (e.g., identity number 505), in the service -Network (e.g. 225) does not have.

Alternatively, the enabling of terminal 150 may be performed by the subscriber identifier (e.g., subscriber identity number 505) configured in the service network (e.g., 225) in response to a terminal 150 message or request.

Alternatively, the length of time period after which the subscriber identifier (e.g. identity number 505) is released from the binding to terminal 150 may be a predetermined length, starting from a time of assignment of the subscriber identifier (e.g. identity number 505) to the terminal 150.

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

For example, the verification request 173 is received from a client-server 141 in the service network (e.g., 225). To configure terminal 150 to have a subscriber's identity by subscriber identifier (e.g., identity number 505), security server 140 may transmit a verification response 174 to client-server 141 and in response to verification 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 the subscriber identifier (e.g., identity number 505).

In general, a terminal 150 can be identified using different identifiers for different services, in different networks and/or different contexts. Each terminal 150 identifier may be used to represent the terminal 150 as a member, subscriber, account, authorized device, and/or one entity among many in a group specific to a type of service, connection, communication, and so on.

For example, the terminal 150 can be configured to communicate with various client-servers 141,...,143 for their services. The terminal 150 can be identified with different client-servers 141,...,143 using different subscriber identifiers. Each of the subscriber identifiers of terminal 150 represents a unique subscriber and/or account recognized by a respective client-server (e.g., 141,...,143) for its services to its subscriber population.

For example, the terminal 150 can be configured to communicate with a client-server 141 for various types of services. Different identifications of the terminal 150 can be used to represent the terminal 150 as a subscriber to a different type of service.

For example, terminal 150 may be assigned an integrated circuit card identifier 251 to act as a smart card, a mobile device identity number 253 to act as a cellular device, a subscriber identity number 255 to act as a subscriber to cellular connections, and so on.

The security server 140 can be configured to manage the identities of the terminal 150 using the security features of the storage device 130 configured in the terminal 150 .

For example, a third party may request the security server 140 to associate a subscribed service in an account with a public identification of the terminal 150. Because the identifier may be public knowledge, there is a potential risk of fraudulent use of the public identifier. The identity data 113 of the terminal 150 can be configured to include the public identification. Based on a Unique Device Secret (UDS) 101 of the storage device 130 configured in the terminal 150, the security server 140 can verify whether the identity data 113 received from the terminal 150 is authentic; and thus terminal 150 has the identity represented by the public identification contained in identity data 113 . The verification performed by the security server 140 can detect fraudulent use of the public identification as an identity.

The security server 140 can be configured to manage the secure, dynamic binding of the public identification to the terminal device 150 . For example, in response to a request from an authorized party in an application domain, the security server 140 may bind a unique public identifier to the terminal 150 for the application domain. For example, the authorized party may be verified based on tracking the ownership rights of storage devices configured in the terminals (e.g., 150). Each application domain can have a variety of public identifiers that represent separate identities in the application domain. The security server 140 binds a unique public identifier to each end device.

For example, in response to a request to bind a public identifier to a terminal 150, the security server 140 may verify that the public identifier is not currently bound to another terminal and using a cryptographic key that provides ownership authorization for operation of the storage device 130, generate an instruction to store the public identification in the storage device 130 as part of the device information 121 for the generation of the identity data 113 of the storage device 130 and/or the terminal device 150.

Alternatively, the security server 140 may store data with which the terminal 150 is associated with the public identification of the terminal 150 in an application domain. In reaction upon a verification request 173 in the application domain, the security server 140 verifies the identity data 113 provided in the terminal 150 and looks up the public identification of the terminal 150 in the application domain. The public identification can be provided in the verification response 174 .

The secure, dynamic binding of the public identifier to the terminal 150 can be used to facilitate security operations. For example, if the terminal 150 is lost/stolen, the owner of the terminal 150 can request the security server 140 to bind the public identification of the lost/stolen terminal 150 to a replacement terminal. Once the security server 140 binds the public identification of the lost/stolen terminal 150 to the substitute terminal, the service subscribed for the lost/stolen terminal 150 is transferred to the substitute terminal. Optionally, the owner of the lost/stolen terminal 150 may request the transfer of data from the lost/stolen terminal 150 to the replacement device; and after the transfer, the owner can request the deactivation of the lost/stolen terminal 150 to minimize the loss/impact of the terminal 150.

26 FIG. 12 shows techniques for managing an identification of a terminal according to an embodiment.

For example, the techniques of 26 in the system of 1 and/or 6 using security features in the storage devices associated with the 1 until 5 and 9 until 10 were explained. For example, the techniques of 26 with the services of the firmware store of 14 and 15 of the service store 190 of the 15 , 23 and/or the activity tracker 451 are used by 20 .

In 26 the security server 140 stores a unique identification 111 of a storage device 130 and its unique device key 101. Furthermore, the security server 140 stores device information 121 that characterizes the hardware, software and/or data configuration of the terminal device 150 in which the storage device 130 is installed. As in 2 , a secret key 137 is based on the device unique key 101 and the device information 121. The secret key 137 is used by the storage device 130 to generate the verification code 133 of the identity data 113; and the security server 140 verifies that the verification code 133 is generated using the secret key 137 indicating that the identity data 113 was generated in the storage device 130 having the unique device key 101 .

In 26 the security server 140 can link the unique identifier 111 to a public identifier 541 of the terminal device 150 . For example, after public identifier 541 is assigned to terminal 150 in an application domain, security server 140 may store public identifier 541 as part of device information 121 associated with the unique identifier of storage device 130 and/or terminal 150 .

For example, the application domain can be configured for the cellular connection, for the smart card process, for a service of a client-server 141 and so on. The identifier 541 can be used to represent the terminal 150 in a population of terminals in the application domain. Identifier 541 can be used to represent terminal 150 as a device, member, service subscriber, account, contact, and so on.

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

After verifying the identity data 113, the security server 140 can add the public identification 541 to the device information 121 and cause the storage device 130 in the terminal 150 to update the device information 121 543. The storage 130 has a new secret key after the update 543, with which he creates new identity data 113, which contain the public identification 541. For example, the message 131 in the new identity data 113 may include the public identifier 541 in addition to the unique identifier 111. The security features of storage device 130 are configured to prevent misuse of unique identifier 111, and can also prevent misuse of public identification 541. For example, when the client-server 141 receives the new identity data 113 containing the public identification 541 , the client-server 141 can request the security server 140 to verify the new identity data 113 . If the new identity data 113 has a valid verification code 133, this is generated by a terminal 150 to which the public identification 541 is assigned.

The security server 140 may update 543 the device information 121 in a manner similar to updating 377 the firmware of the terminal 150 and/or repairing 385 a package installed in the terminal 150 . For example, the security server 140 can generate a verification code 153 for an instruction 155 to store the public identification 541 in the memory cells 103 of the storage device 130 . The verification code 153 is generated using a cryptographic key 145 representing ownership authorization to operate the storage device 130, including authorization controlled by the access controller 109 in the storage device 130 to execute the command 155 in the storage device 130.

Optionally, associating public identifier 541 with terminal 150 does not require generating a new secret key to represent storage device 130 and/or terminal 150 . The public identifier 541 may be included in the message 131 used to generate the verification code 133 signed with the secret key 137 . Examination of the verification code 133 indicates that the public identifier 541 provided in the message 131 has not been altered; and the verification code 133 is signed by the storage device 130 installed in the terminal 150.

Optionally, update 543 is skipped; and the storage device 130 and/or the terminal 150 does not store the public identification 541. The security server 140 stores data with which the unique identifier 111 is associated with the public identifier 541 . After the security server 140 has verified the identity data 113 provided in a verification request, the security server 140 can look up the public identifier 541 relevant to an application domain for the unique identifier 111 identified in the message 131 of the identification data 113 and provide the public identifier 541 in a verification response, in a manner similar to the representation of the Subscriber Identity Number 505 in a Verification Response 174 illustrated in FIG 23 .

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

In one embodiment, terminal 150 includes a packet stored in storage device 130 . When the package is loaded from the storage device 130 and executed in the host system 120, the terminal 150 can communicate with the server 140 for update 543 . The communication between the terminal device 150 and the server 140 can take place via a client-server (e.g. 141), a firmware store 170, a service store 190, an activity tracker 451 or another server (e.g. the portal 545) or without the intermediary of a server.

For example, a terminal manufacturer (e.g., 150) may use a computer 180 to configure the terminals (e.g., 150) and request the binding of identifiers (e.g., 541) associated with the terminals (e.g., B. 150) have been assigned by the manufacturer. Such public identifiers can be, for example, identification numbers for mobile devices (e.g. 253), which represent individual devices in a communication network.

For example, a service provider may assign subscriber identity numbers (e.g., 255) to subscribers of a service that it offers. When an owner or user of a terminal 150 subscribes to the provider's services, the service provider may use a computer 180 to request binding of a subscriber identity number 255 to the terminal 150 .

27 FIG. 12 shows a method for managing an identification of a terminal according to an embodiment. For example, the procedure of 27 using the above in conjunction with 26 explained techniques are implemented in a system with security features that are used in conjunction with the 1 until 19 was explained.

At block 561, a server system stores the association of a device key (e.g., 101) of a storage device 130 configured in a terminal 150, a first identifier 111, and device information 121 of the terminal 150.

The server system may include a security server 140, for example. 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 other server. In some implementations, the server system may further include a client-server 141 and/or a map server 223, as illustrated in FIG 6 .

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

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

In one embodiment, the authority to attach such a second identifier 541 to the terminal 150 is associated with an entity that operates the computer and owns the storage device 130 (e.g., as a manufacturer, retailer, service provider, end-user of the terminal 150). .

For example, the entity may communicate with the terminal 150 and/or the storage device 130 via the computer to retrieve the current identity data 113 generated in the storage device 130 . The current identity data 113 contains the first identification 111 and can be checked by the server system as to whether the current identity data 113 in the storage device 130 is authenticated.

For example, the server system may store data associated with the first identifier 111 and the second identifier 541 in response to the request.

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

For example, the server system can communicate with the terminal 150 to update the data stored in the storage device 130 and/or to store the second identifier 541 in the storage device 130 .

Optionally, the second identification 541 can be used as part of the device information 121 in the storage device 130 to generate a secret key 137, wherein the secret key 137 is used to verify the verification code 133 of the identity data 113 of the storage device 130 and/or the terminal device 150 to create.

Optionally, the second identifier 541 does not alter the generation of the secret key 137. However, the second identifier 541 is stored in an access-controlled area of the storage device 130 and incorporated into the message represented in the identity data 113 (e.g., as part of the data C 127). 131 recorded.

For example, in response to the request to bind the second identifier 541 to the terminal 150, the server system may generate a verification code 153 for an instruction 155 and cause the storage device 130 to execute the instruction 155 with respect to the verification code 153. After receiving command 155 and command 155 verification code 153, access controller 109 of storage device 130 is configured to verify command 155 verification code 153 using a cryptographic key (e.g., access control key 149) that has permission to execute instruction 155 in memory 130. Storage device 130 is configured to execute command 155 in response to a determination that verification code 153 for command 155 is valid, execution of command 155 in storage device 130 stores second identifier 541 in storage device 130 for the subsequent generation of the identity data 113. For example, the second identification 541 can be stored as part of the device information 121 and/or for presentation in the message 131 of the identity data 113.

For example, the memory stores an instruction set executable in the terminal 150 . The set of instructions may be part of the content 161 or a package 441 of the terminal's firmware or operating system. The storage device 130 is configured to verify the integrity of the instruction set, before allowing terminal 150 to load the instruction set for execution. Since the instruction set is secured via the storage device 130, the server system can reliably communicate with the terminal 150 executing the instruction set to cause the storage device 130 to execute the command 155. The communication path between the terminal 150 and the server system can optionally take place via a client-server 141 and/or optionally be secured via a session key 263 and symmetric cryptography.

At block 565, the server system receives a verification request 173 with identity data 113 generated by the storage device 130. FIG. The identity data 113 includes a verification code 133 generated by a message 131 represented in the identity data 113 and a cryptographic key (e.g. secret key 137) derived at least in part from the secret code (e.g. 101). .

For example, in some implementations, the message 131 represented in the identification data includes the second identification 541. Optionally, the cryptographic key (e.g., the secret key 137) used to sign the message 131 in the form of the verification code 133 may be further based be derived on the second identifier 541 if the second identifier 541 is configured as part of the device information 121; alternatively, the cryptographic key is independent of the second identifier 541.

In some implementations, the message 131 represented in the identification data 113 does not include the second identification 541.

At block 567, the server system determines that the identity data 113 is valid based at least in part on a secret code (e.g., 101) of the storage 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, 485, and/or block 525.

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

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

28 FIG. 6 illustrates an example machine of a computer system 600 in which an instruction set may be executed that causes the machine to perform one or more of the methodologies discussed herein. In some embodiments, computer system 600 may correspond to a host system that includes, couples to, or uses a storage subsystem, or may be used to perform the operations of a security manager 160 (e.g., to execute commands, to perform operations consistent with the security server 140 and/or the security features of the storage device 130 identified with respect to the 1 - 27 have been described). In alternative embodiments, the machine may be connected (e.g., networked) to other machines on a LAN, an intranet, an extranet, and/or the Internet. The machine can function as a server or a client machine in a client-server network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or client machine in a cloud computing environment infrastructure or environment are operated.

The machine can be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile phone, a web appliance, a server, a network router, a Be a switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify the actions to be performed by that machine. Further, while only a single machine is illustrated, the term "machine" should include any collection of machines that individually or collectively execute a set (or sets) of instructions for performing one or more of the methodologies discussed herein.

The example computer system 600 includes a processing device 602, a main memory 604 (e.g., read only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), or RAM). bus DRAM (RDRAM), static random access memory (SRAM), etc.) and a data storage system 618 that communicate over a bus 630 (which may be multiple buses).

Processing device 602 represents one or more general purpose processing devices, such as a microprocessor, central processing unit, or the like. In particular, the processing device may be a Complex Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computing (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, or a processor that implements other instruction sets, or processors that implement a combination of instruction sets. Processing device 602 may also be one or more specialized processing devices, such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), a network processor, or the like. The processing device 602 is configured to execute instructions 626 for performing the operations and steps discussed herein. Computer system 600 may further include a network interface device 608 for communicating over network 620 .

The data storage system 618 may include a machine-readable medium 624 (also referred to as a computer-readable medium) storing one or more sets of instructions 626 or software embodying one or more methodologies or functions described herein. Instructions 626 may also reside wholly or at least partially in main memory 604 and/or processing device 602 during their execution by computer system 600, where main memory 604 and processing device 602 also constitute machine-readable storage media. The machine-readable medium 624, data storage system 618, and/or main memory 604 may correspond to a storage subsystem.

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

In general, a terminal 150, a server (e.g., the security server 140, a client server 141 or 143, or a map server 223) can be a computer system that includes a host system 120 and a storage subsystem. The storage subsystem may include media such as one or more volatile storage devices, one or more non-volatile storage devices (e.g., storage device 130), or a combination thereof.

The storage subsystem may be a storage device, a storage module, or a hybrid storage device and storage module. Examples of a storage device include a solid-state drive (SSD), a flash drive, a USB (Universal Serial Bus) flash drive, an eMMC (Embedded Multi-Media Controller) drive, a UFS (Universal Flash storage), an SD (Secure Digital) card and a hard disk drive (HDD). Examples of memory modules include a dual in-line memory module (DIMM), a small outline DIMM (SO-DIMM), and various types of non-volatile dual in-line memory modules (NVDIMM).

The computer system can be, for example, a computing device such as a desktop computer, a laptop computer, a network server, a mobile device, a vehicle (e.g., an airplane, drone, train, car, or other means of transportation) , an Internet of Things (IoT)-enabled device, embedded computer (e.g., one in a vehicle, industrial facility, or connected commercial device), or computer system that includes storage and processing equipment.

The computer system's host system 120 is coupled to one or more storage subsystems. As used herein, "coupled to" or "coupled to" generally refers to a connection between components, which may be either an indirect communicative connection or a direct communicative connection (e.g., without intervening components), regardless of whether whether they are wired or is wireless, including connections such as electrical, optical, magnetic, etc.

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

The host system 120 can be coupled to the storage subsystem via a physical host interface. Examples of a physical host interface include, but are not limited to, a Serial Advanced Technology Attachment (SATA) interface, a Peripheral Component Interconnect Express (PCIe) interface, a Universal Serial Bus (USB) interface, a Fiber Channel , a Serial Attached SCSI (SAS) interface, a Double Data Rate (DDR) memory bus interface, a Small Computer System Interface (SCSI), a Dual In-Line Memory Module (DIMM) interface (e.g., DIMM socket interface that supports Double Data Rate (DDR)), an Open NAND Flash interface (ONFI), a Double Data Rate (DDR) interface, a Low Power Double Data Rate (LPDDR) interface, or another interface. The physical host interface can be used to transfer data between the host system 120 and the storage subsystem. Host system 120 may also use an NVM Express (NVMe) interface to access components (e.g., storage devices 130) when the storage subsystem is coupled to host system 120 via the PCIe interface. The physical host interface can provide an interface for passing control, address, data, and other signals between the storage subsystem and the host system 120 . In general, host system 120 may access one or more storage subsystems via a single communication link, multiple separate communication links, and/or a combination of communication links.

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, and so on. In some instances, controller 116 may also be referred to as a memory controller, memory manager, and/or initiator. In one example, controller 116 controls communications over a bus coupled between host system 120 and the storage subsystem. In general, controller 116 may send commands or requests to the storage subsystem for desired access to storage devices 130. The controller 116 may also include interface circuitry for communicating with the storage subsystem. The interface circuit may convert the responses received from the storage subsystem into information for the host system 120.

The controller 116 of the host system 120 may communicate with the controller of the storage subsystem to perform operations such as reading data, writing data, or deleting data in the storage devices 130 and other such operations. In some instances, controller 116 is integrated into the same package as processing device 118 . In other instances, the controller 116 is separate from the processing device 118 package. Controller 116 and/or processing device 118 may include hardware, such as one or more integrated circuits (ICs) and/or discrete components, a buffer memory, a cache memory, or a combination thereof. Controller 116 and/or processing device 118 may be a microcontroller, dedicated logic circuitry (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), or other suitable processor.

Storage devices 130 may include any combination of the various types of non-volatile and/or volatile memory components. The 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 negative-and (or NOT AND) (NAND) flash memory and write-in-place memory, such as three-dimensional cross-point ("3D cross-point") memory. A cross-point array of non-volatile memory, in conjunction with a stackable cross-lattice data access array, can perform bit storage based on a change in bulk resistivity. In addition, unlike many flash-based memories, the cross-point non-volatile memory can operate a write-in-place operation, where a non-volatile memory cell can be programmed without changing the non-volatile memory cell was previously erased. The NAND type flash memory includes, for example, two-dimensional NAND (2D NAND) and three-dimensional NAND (3D NAND).

Each of the memory devices 130 may include one or more arrays of memory cells. One type of memory cell, e.g. B. Single Level Cells (SLC), can store one bit per cell. Other types of memory cells, such as multi-level cells (MLC), triple-level cells (TLC), quad-level cells (QLC), and penta-level cells (PLC), can store multiple bits per cell. In some embodiments, each of the memory devices 130 may include one or more arrays of memory cells, such as SLCs, MLCs, TLCs, QLCs, PLCs, 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 storage devices 130 may be grouped as pages, which may relate to a logical unit of the storage device used to store data. In some types of memory (e.g. NAND), pages can be grouped to form blocks.

Although non-volatile memory devices such as 3D crosspoint and NAND memory (e.g., 2D NAND, 3D NAND) are described, memory device 130 may be any other type of non-volatile memory, such as read-only memory (ROM), phase change memory (PCM) , self-selecting memory, other chalcogenide-based memory, ferroelectric transistor random access memory (FeTRAM), ferroelectric random access memory (FeRAM), magneto random access memory (MRAM), spin transfer torque (STT) MRAM, conductive bridging RAM (CBRAM), resistive Random Access Memory (RRAM), Oxide-based RRAM (OxRAM), Negative-or (NOR) Flash memory, and Electrically Erasable Programmable Read Only Memory (EEPROM).

A storage subsystem controller may communicate with storage devices 130 to perform operations such as reading data, writing data, or deleting data in storage devices 130 and other such operations (e.g., in response to commands that scheduled on a command bus by the controller 116). The memory subsystem controller may include hardware such as one or more integrated circuits (ICs) and/or discrete components, a buffer memory, or a combination thereof. The hardware may include digital circuitry with dedicated (e.g., hard-coded) logic to perform the operations described herein. The memory subsystem controller may be a microcontroller, dedicated logic circuitry (e.g., a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), etc.), or other suitable processor.

The memory subsystem controller may include a processing device (e.g., processor) configured to execute instructions stored in local memory. In the illustrated example, the memory subsystem controller's local memory includes embedded memory configured to store instructions for performing various processes, operations, logic streams, and routines that control the operation of the memory subsystem, including the Handling of communication between the storage subsystem and the host system 120.

In some embodiments, local storage may include storage registers that store memory pointers, requested data, and so on. Local storage may also include read only memory (ROM) for storing microcode. While some storage subsystems have storage subsystem controls, other storage subsystems do not have storage subsystem controls and may instead rely on external control (e.g., provided by an external host or by a storage subsystem separate processor or controller).

In general, the storage subsystem controller may receive commands or operations from host system 120 and convert the commands or operations into instructions or appropriate commands to achieve desired access to storage devices 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, caching operations, and address translations between a logical address (e.g., logical block address (LBA), namespace ) and a physical address (e.g., physical block address) associated with storage devices 130 . The storage subsystem controller may further include host interface circuitry for communicating with the host system 120 via the host physical interface. The host interface circuit can convert the commands received from the host system into commands for accessing the storage devices 130 and the convert responses associated in storage devices 130 into information for host system 120 .

The memory subsystem may also include additional circuitry or components that are not illustrated. In some embodiments, the memory subsystem may include a cache or buffer (e.g., DRAM) and address circuitry (e.g., a row decoder and a column decoder) that can receive an address from the memory subsystem controller and decode the address to access storage devices 130 .

In some embodiments, storage devices 130 include local media controllers that work in conjunction with the storage subsystem controller of the storage subsystem to perform operations on one or more storage cells 103 of storage devices 130 . A local media controller may be used to implement the cryptographic engine 107 and/or the access controller 109. An external controller (e.g., the storage subsystem controller or the controller 116 of the host system 120) may externally manage the storage device 130 (e.g., perform media management operations on the storage device 130). In some embodiments, a storage device 130 is a managed storage device; H. a raw storage device in combination with a local media controller for media management in the same storage device package. An example of a managed memory device is a managed NAND (MNAND) device.

The storage subsystem controller and/or a storage device 130 may include a security manager 160 configured to provide the security features discussed above. In some embodiments, the storage subsystem controller and/or the local media controller in the storage 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 . Storage subsystem controller, controller 116, and/or security server 140 may include logic circuitry and/or execute instructions to implement security manager 160, for example. For example, the storage subsystem controller or processing device 118 (e.g., processor) of the host system 120 may be configured to execute instructions stored in the storage device 130 to perform the security manager 160 operations described herein. In some embodiments, security manager 160 is implemented in an integrated circuit chip located in the memory subsystem. In other embodiments, the security manager 160 may be part of the storage subsystem firmware, an operating system of the host system 120, a device driver, or an application, or any combination thereof.

Some portions of the foregoing detailed descriptions have been presented in terms of algorithms and symbolic representations of operations on data bits in computer memory. These algorithmic descriptions and representations are used by those skilled in the data processing arts to convey the substance of their work most effectively to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those that require physical manipulations of physical quantities. Usually, but not necessarily, these quantities take the form of electrical or magnetic signals that can be stored, combined, compared, and otherwise manipulated. At times it has proven convenient, primarily for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

However, it should be borne in mind that all of these and similar terms should be associated with the appropriate physical quantities and are merely convenience labels applied to those quantities. The present disclosure may relate to the actions and processes of a computer system or similar electronic computing device that manipulate and convert data represented as physical (electronic) quantities in the computer system's registers and memories into other data that is similarly represented represented as physical quantities in the memories or registers of the computer system or other such information storage system.

The present disclosure also relates to an apparatus for performing the operations described herein. This device may be specially designed for the intended purposes or may incorporate a general purpose computer which is selectively activated or reconfigured by a program stored in the computer. Such a computer program may be stored on a computer-readable storage medium, such as, but not limited to, any type of disk, including floppy disks, optical Disks, CD-ROMs and magneto-optical disks, read only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards or any type of media suitable for storing electronic instructions and each containing a Computer system bus are coupled.

The algorithms and displays presented herein are not necessarily tied to any particular computer or other device. Various general purpose systems may be used with programs according to the teachings herein, or it may prove convenient to construct more specific apparatus for performing the method. The structure for a variety of these systems appears as given in the following description. Additionally, the present disclosure is not described with reference to any particular programming language. It is understood that a variety of programming languages can be used to implement the teachings of the disclosure 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 a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form that can be read by a machine (e.g., a computer). In some embodiments, a machine-readable (e.g., computer-readable) medium includes a machine-readable (e.g., computer-readable) storage medium, such as read-only memory ("ROM"), random access memory ("RAM"), magnetic disk storage media, optical storage media, flash memory components, etc .

In this specification, various functions and operations are described as being operated or prompted by computer instructions in order to simplify the description. However, those skilled in the art will recognize that these terms mean that the functions result from the execution of the computer instructions by one or more controllers or processors, such as a microprocessor. Alternatively or in combination, the functions and operations may be implemented using special purpose circuits, with or without software instructions, such as using application specific integrated circuits (ASIC) or field programmable gate arrays (FPGA). Embodiments may be implemented using hardwired circuitry without software instructions or in combination with software instructions. Thus, the techniques are not limited to any combination of hardware circuitry and software, nor to any particular source for the instructions executed by the data processing system.

In the foregoing specification, the embodiments of the disclosure have been described with reference to certain exemplary embodiments. Obviously, various modifications can be made without departing from the broader spirit and scope of the embodiments of the disclosure as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

QUOTES INCLUDED IN DESCRIPTION

This list of documents cited by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent Literature Cited

• US17/005565 [0002,0185]
• US63/059617 [0002]
• US 17/080684 [0002]
• US2020/0322134 [0002]
• US 17/014203 [0002,0180]
• US 16/374905 [0187]

Claims (20)

Method comprising: receiving, at a server system and from a terminal, a request associated with a service provided over a computer network serving a plurality of subscribers, the request including identity data retrieved from a storage device configured in the terminal be generated; determining, by the server system in response to the request and based on a secret of the storage device and the identity data, an authenticity of the storage device; identifying, based on the identity information, a subscriber of the plurality of subscribers based on the ownership information of the terminal; and determining, in response to the request, an account of the subscriber as a result of identifying the subscriber for providing the service to the terminal based on the account. procedure after claim 1 , wherein after manufacture of the terminal, the terminal has no customization for the subscriber and no customization for the account before the request. procedure after claim 2 , wherein the terminal is manufactured in such a way that it can be used by a large number of participants. procedure after claim 3 , wherein the terminal does not include a hardware component that is inserted into the terminal to represent the subscriber, the account, or any combination thereof. procedure after claim 4 wherein at least prior to the request, the terminal does not contain data stored in the terminal to represent the subscriber, the account, or any combination thereof. Procedure according to one of claims 3 until 5 wherein at least prior to the request, the terminal does not include an indication of the subscriber, the account, or any combination thereof, without the terminal ownership data; and the property data is stored in the server system but not in the end device. Procedure according to one of claims 3 until 6 , further comprising: storing, in the server system and in response to the request, data associating the identity data with the account. Procedure according to one of claims 3 until 7 , further comprising: generating, by the server system using a cryptographic key, a verification code for an instruction; and causing, by the server system, the storage device to receive the command and the verification code, wherein the storage device is configured to check the verification code prior to executing the command in the storage device. procedure after claim 8 wherein the command, when executed on the storage device, causes the storage device to store additional data for identifying the account. procedure after claim 9 , wherein after executing the command, the storage device is configured to generate updated identification data for identifying the account. procedure after claim 10 wherein the storage device does not transmit the secret code outside the storage device after completion of the storage device in a secure facility. procedure after claim 11 , further comprising: establishing a session key based on verification of the identity data. procedure after claim 12 , wherein the storage device is configured to verify the verification code based on an access control key configured based on the session key. procedure after claim 12 or 13 , further comprising: registering the secret code during manufacture of the storage device in the secure facility; and generating, based at least in part on the secret, a cryptographic key for verification in the identity data. procedure after Claim 14 wherein the cryptographic key used to verify the identity data is further generated based on data received from a host system of the storage device upon booting of the host system. A computer system, comprising: a memory that stores cryptographic keys in the storage devices; and at least one processor configured via an instruction set to: receiving a request associated with a service provided over a computer network serving a plurality of subscribers, the request including identity data generated by a storage device configured in a terminal; determining, in response to the request and based on a secret code of the storage device and the identity data, an authenticity of the terminal; identifying, based on the identity information, a subscriber of the plurality of subscribers based on the ownership information of the terminal; determining, in response to the request, an account of the subscriber; and causing the service to be provided to the terminal based on the account. computer system after Claim 16 wherein the authenticity of the terminal is determined based at least in part on security features of the storage device, and wherein the security features include: generating a cryptographic key representative of an identity of the terminal based at least in part on the identity of the storage device and stored in the storage device firmware to execute on a host system connected to the storage device in the terminal; and controlling commands executed on the storage device based on permissions represented by cryptographic keys. computer system after Claim 17 wherein the terminal is not operated to identify the account prior to the request and wherein the security features further include a cryptographic engine. A non-transitory computer storage medium storing instructions that, when executed by a server, cause the server to perform a method, the method comprising: Receiving from a client-server, in response to a terminal connecting to the client-server, a request for a service provided over a computer network to a plurality of accounts, the request including identity data that generated by a storage device configured in the terminal; determining, in response to the request and based on a secret code of the storage device and the identity data, an authenticity of the terminal; identifying, based on the identity information and in response to the request, one of the plurality of accounts; and Transmitting, to the client-server, a response to the request, the response configured to identify the account and cause the client-server to provide the service to the terminal based on the account. non-volatile computer storage medium claim 19 , wherein the terminal has no adaptation for identifying the account.

Images