Token-based zero-touch registration for provisioning edge computing applications

Abstract

To allow zero-touch enrollment of devices with manager systems.SOLUTION: A device at startup can contact a central directory service (CDS) for information about an associated manager. The CDS can authenticate the device using device information included in the request, and can send a challenge token to the device in response thereto. The challenge token can include information regarding the manager, protected with multiple layers of security that should only be able to be decrypted by the authenticated device. The device can decrypt the challenge token to determine the manager information, and can convert the challenge token to a bearer token. The device can then send the determined manager a request that includes the bearer token, and the manager can use the token to authenticate the device. The manager can then send the device appropriate configuration information.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to token - based zero - touch registration for provisioning edge - computing applications.

Background Art

[0002] To connect and exchange data with other devices or systems via a network such as the Internet, an increasing number of diverse devices are being configured. These devices are often called Internet of Things (IoT) devices and need to be able to locate or identify other devices or systems with which they should communicate. However, since these devices may be sold to multiple entities or associated with a wide variety of external systems, these devices are usually not produced with their information already stored in them. As a result, the devices must obtain or be provided with information about these other devices or systems. To eliminate the need to manually program or configure these devices, which may include many devices for a particular entity, various "zero - touch" techniques have been utilized, by which these devices can automatically obtain this information without manual intervention. However, conventional techniques have various problems, such as the need for direct communication between a central agency and a device manager and the disclosure of the device manager's location to other devices or entities, which can create unnecessary security risks and may be undesirable for certain systems or usage scenarios. Furthermore, conventional techniques require a multi - trip communication challenge - response between each device and the corresponding central agency, which significantly increases the traffic and complexity of these techniques.

Summary of the Invention

Means for Solving the Problems

[0003] With reference to the drawings, various embodiments according to the present disclosure will be described.

Brief Description of the Drawings

[0004]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Modes for Carrying Out the Invention

[0005] The techniques according to various embodiments overcome these and other deficiencies by utilizing one or more token-based techniques with advantageous signature and encryption structures. In at least one embodiment, a device receiving an initial boot can send an information request to a central authority, or other entity, system, or service from which the device can obtain information and whose address or destination is stored in the device. The central authority can then generate and send a challenge token unique to the device if the device is recognized. The challenge token can include one or more security mechanisms (e.g., encryption using a specific key or digital signature) that enable the challenge token to be decrypted and verified by the device. The device can then convert this challenge token from the central authority into an unforgeable bearer token, such as by digitally signing the decrypted version of the challenge token. The device can then present this bearer token to a device manager or other entity, system, or service associated with the device that can provide configuration information regarding the device for the device's intended task. The device manager can use the bearer token to authenticate the device and then send the respective configuration data to the device. The device can then use this configuration information to perform the device's intended task after the boot is complete. Such techniques enable a manager to authenticate a device using information from a central authority such as a central directory service (CDS) without any direct communication between the CDS and various managers. In one embodiment where there can be only one trip between the device and the CDS, the CDS provides a response to confirm the validity of the device to prove that the device is legitimately targeting its manager, provides identification information regarding the manager that can only be accessed by devices whose validity has been confirmed, and can include a token that the device can provide to the manager.

[0006] Figure 1 shows an exemplary architecture 100 that can be used to provide such functionality, according to at least one embodiment. In this example, there may be various devices 104, 108, 110 that can communicate via at least one network. Any number of these devices may exist and can be of various device types. Generally, these devices include at least circuitry and software that enables these devices to communicate over a connected network such as the Internet, Ethernet®, a local area network (LAN), a cellular network, or a peer-to-peer network, either via a wired connection and / or a wireless connection. In some embodiments, the device may include an embedded computer circuit that may include a microprocessor or microcontroller, as well as memory for storing at least executable instructions and configuration information. These devices may include devices such as computer peripherals, smart vehicles, or other IoT devices or network-connected devices.

[0007] As described above, manufacturers produce many of these devices, and these devices can be sold to various entities. Each of these entities may desire for each device to communicate with a particular other device, system, or service, such that it may be possible to manage and configure these devices. For at least some of these entities, it may be desirable that it is not necessary to manually program or configure these devices for this communication, such as by providing an address to one or more device managers that can provide configuration data, updates, and other such information. As an example, a retailer may purchase many cameras for its stores and may prefer that it is not necessary to manually configure each of these cameras to communicate with its security system. In at least one embodiment, these devices can instead be configured to contact a central directory service ("CDS") 102 or other such trusted entity, system, or service upon startup. The role of the CDS in such a configuration is to authenticate the device and then redirect the device to an appropriate manager server. This directory service 102 may include a server or computing system or computing device that can receive requests or communications from any of these devices 106, 108, 110, verify information about those devices, and then send information about a device manager associated with a particular device, such as a device manager that may be associated with the entity that purchased the device, to those devices. There may be multiple such manager systems 112, 114, and the directory service 102 (which may also be more than one) can provide information to a given device 104 about which manager 112 the device should contact to obtain information. In at least one embodiment, the directory service 102 that receives a request from a device can check information in a device database 116 or other such location to determine whether the information provided in the request corresponds to valid device information.In the case of correspondence, the directory service 102 can examine the mapping database 118 or other such storage locations to identify the manager 112 corresponding to (e.g., mapped to) that device. The directory service 120 can then send this information and any other relevant information to the device 104.

[0008] When appropriate manager information is received, the device 104 can contact the identified manager 112, and the manager 112 can identify the appropriate configuration information that can be stored in the configuration repository 120 and provide that configuration to the device 104 so that the device can complete the startup process and be ready to perform its respective tasks. These tasks can be any appropriate tasks known or used in network-connected devices, which can include security monitoring, status monitoring, automation, navigation, data processing, etc.

[0009] In at least one embodiment, token-based communication can be used as a security mechanism for any or all of these communications. In various embodiments, this security mechanism can include a single token or multiple tokens. These tokens can include or be protected using information unique to one or more of the device, CDS, and respective managers. For example, a device can have a serial number and one or more identifiers of internal components such as a trusted platform module ("TPM") that can store confidential information such as one or more secret keys. The device and CDS may have one or more symmetric or asymmetric keys that can be used to encrypt one or more of these tokens. In at least one embodiment, a combination of encryption and digital signatures can be used with these tokens to enhance the security of these communications.

[0010] Figure 2 shows exemplary token 200 that can be generated for use in such processes. Each of these tokens can include multiple security layers that use information that should only be known to the associated entity. Thus, an entity attempting to impersonate any of these devices or systems should not be able to decrypt one or more of these tokens in a registration or other such process. A first exemplary token is a request token 202 that can be provided from a device to a CDS or other such entity during a startup process. In this example, the request token includes the identifier of that device ("deviceID"). This deviceID may be generated by the device based on specific information that may include a tuple of the device's serial number, TPM identifier (TPM_ID), and the device's permanent endorsement key (EK). In some embodiments, other device identifiers, such as those that may correspond to only the serial number, may be used as well. This request token 202 can be wrapped in an external security layer that can include encryption using a self-generated key (SRK), which is an untrusted key in this example. In at least one embodiment, this self-generated key can be a key generated by this device to represent the device instead of using the permanent key EK. Both EK and SRK may correspond to an asymmetric key pair of a public (PUB) key and a private (PRIV) key. Since a given device may be sold or reused and thus may be associated with various managers during the device's lifetime, a self-generated key can be used. Using a self-generated key instead of a permanent key can prevent the device from accessing information about another owner or task that it would normally be able to access only if it were using an unchanging permanent key.When the device is wiped and reused, the device can generate a new asymmetric key pair (e.g., SRK_PRIV and SRK_PUB) to be used for verification, such that the device can then access only information for the current purpose of the device, or information associated with the current owner or manager.

[0011] A second exemplary token is challenge token 204 that can be generated by the CDS and sent to the requesting device. This challenge token can be protected in such a way that only the valid device can decrypt it when the device presents itself as a valid device. This exemplary challenge token includes information useful for the device to identify the appropriate manager, such as the manager's URL (or other contact address or mechanism) and the manager's identifier, and is useful for the manager to verify that the device is contacting the correct manager. The challenge token can also include device-specific information, such as deviceID and SRK_PUB, which helps the device and the corresponding manager verify that this information pertains to this particular device. Similarly, additional information can be included, such as an expiration or time-to-live (TTL) value and a random nonce generated for each token, such that if a second challenge token is received with the same nonce, this can indicate that someone or something is attempting to reuse the same challenge token.

[0012] Within the internal layer, the CDS secret key can be used to sign this challenge token. Within the intermediate layer, the device's persistent public key EK_PUB can be used to encrypt this signed key. This helps ensure that only this device can decrypt this challenge token using its EK_PRIV key in its TPM, regardless of the current owner or manager of the device. Next, within the external layer, the self-generated public key (SRK_PUB) can be used to encrypt this token, and the self-generated public key should only be decodable by the device in its current ownership state using its self-generated private key (SRK_PRIV). Encrypting using both EK_PUB and SRK_PUB helps ensure that an appropriate device has obtained access (since SRK is a key generated by the device and can be difficult to authenticate) and that the device has obtained only information regarding its current operational state (since EK persists across all owners or states). Next, within the external-external layer, the CDS secret key signature can be used to sign this challenge token. It should be understood that these layers can be in a different order and that similar, fewer, additional, or alternative layers can be used within the scope of various embodiments.

[0013] A third exemplary token is the bearer token 206. A device that has successfully decrypted the challenge token 204 to identify the appropriate manager information can provide the bearer token 206 to its manager to obtain configuration information. This bearer token 206 can include the signed but decrypted challenge token. In this example, the challenge token can include not only information about the manager and the device, but also a nonce and a TTL value. Based on the information about the device and the manager, the manager can determine that this request is from a specific device targeting this specific manager. Meanwhile, based on the TTL value, the manager can determine that the bearer token remains valid. Based on the nonce, the manager can determine that no attempt has been made to reuse the bearer token. Next, this bearer token can be signed with the device's self-generated private key (SRK_PRIV). Thus, the manager can verify that this was sent from the appropriate device by decrypting it using the corresponding public key. In at least some embodiments, it may be important for the device to use a self-generated key for signing instead of a persistent key because the manager should only be able to decrypt data related to the device in its current state or under its current ownership, and not data related to other states or potential ownerships associated with other managers.

[0014] Figure 3 shows an exemplary process 300 for zero-touch enrollment of a device, which may be carried out according to at least one embodiment. For this and other processes presented herein, unless otherwise specified, within the scope of various embodiments, additional steps, fewer steps, or alternative steps may exist in a similar or alternative order, or at least partially in parallel. In this example, the device undergoes an initial startup (302) as a new device or after a wipe of the device for which new configuration and manager information is to be obtained. The device can generate a manager information request and send that request to a central directory service (CDS) or other such entity (304), and that request can include device identification information within a request token as described with respect to FIG. 2. The CDS that receives this request can verify the device information and identify an appropriate manager for the device. Next, a challenge token can be received from the CDS by the device (306), and that challenge token includes information regarding the manager with multiple secure wrappings. The device can decrypt the challenge token (308) to obtain a base token (or decrypted challenge token) that includes manager information and potentially other information described herein, and can perform some appropriate verification. Next, the device can generate a bearer token digitally signed by the device that includes the decrypted token (610), effectively converting the challenge token into a bearer token. Next, a configuration information request including the bearer token can be sent to the manager identified using the manager information found from the decrypted token (312). The manager can verify the information and send appropriate configuration (and other related) information to the device. The device can receive this configuration information from the manager (314) and use the received configuration information to configure the device (316). After startup and configuration are complete, the device can operate for its intended purpose (318).

[0015] FIG. 4 shows an exemplary process 400 that may be performed by an entity or system such as a Central Directory Service (CDS), which may be part of the registration process described with respect to FIG. 3. In this example, the CDS can receive from the device a request that includes an encrypted or signed device identifier (ID) using the device's self-generated key (402). The CDS can compare the device identifier and the information contained in the device identifier against a database of known valid devices to verify the validity of the device (404). In at least one embodiment, this comparison can include not only finding the serial number of the device in the database, but also ensuring that the provided key information corresponds to that serial number in the device's database. If the validity of the device cannot be verified, the CDS can, among other options, ignore the request or send back some type of error message. If the validity of the device information can be verified, a manager 406 or other relevant system or service for that device can be identified, such as by referring to a set of known device mappings (406). The CDS can generate a token that includes information useful for identifying the appropriate manager for this device (408), and that information may include the device identifier, manager information, token expiration, and a randomly generated nonce. This token can be wrapped with one or more security wrappings to generate a protected challenge token (410), which can be encrypted and / or signed one or more times. The challenge token can then be sent to the device (412), and the device with the appropriate security information should be able to decrypt and utilize the information within the challenge token.

[0016] FIG. 5 shows an exemplary process 500 that may be performed by a device that receives a challenge token for cryptographic validity verification, such as the challenge token generated in the process of FIG. 4, and this process may be part of the registration process described with respect to FIG. 3. Similar to other processes described herein, the order or inclusion of at least some of these steps may vary between embodiments. In this example, the device receives a challenge token from a central directory service (CDS) or other such entity in response to an information pre-request (502). The device can determine the integrity of the challenge token by first verifying the CDS signature on the challenge token (504). Next, the device can decrypt the challenge token using the device's self-generated key and the persistent key. As described above, by using both keys, it can be ensured that the device only accesses information that it is permitted to access with respect to the owner of the device or the current state of the usage situation, and that the device is the device it claims to be. Next, a device that has successfully decrypted the challenge token can verify the internal signature of the challenge token using the CDS public key (508). Once decrypted and verified, the device can identify the manager information contained in the token (510). The manager information can include, for example, an identifier and address information such as a uniform resource locator (URL). Next, the device can create a bearer token by combining the signed but decrypted challenge token with the nonce from within the token (512), and then can sign the bearer token using the self-generated device key (514). The self-generated key is used instead of the persistent device key because the manager should only be able to access information about the device while that manager is associated with the device and should not be able to access it at other times. Next, the device can send the bearer token to the identified manager along with a configuration information request or other such communication (516).In this process, the device communicates with the CDS in a single round-trip communication, and then the device communicates directly with the manager, so the manager does not communicate directly with the CDS. In such a process, the identification of the manager is not disclosed to the device unless the device can authenticate itself via a challenge token.

[0017] FIG. 6 shows an exemplary process 600 that may be performed by a device manager that receives a bearer token, such as a bearer token generated in the process of FIG. 5, along with a configuration information request, and this process may be part of the registration process described with respect to FIG. 3. In this example, a signed bearer token is received along with the request (602). The manager can verify that the inside of the bearer token is correctly signed by the CDS (604). In at least one embodiment, security requirements may direct that the manager verify, without contacting the CDS, that the device has been referenced by the CDS to the manager. The manager can also verify that the manager information contained in the bearer token is correct and that the token has not expired (606). The manager can also verify that the external or wrapper is signed with the same self-generated device key that is embedded inside (608). The manager can also verify that the nonce within this CDS-signed bearer token matches the nonce that is outside of this CDS-signed token but is included in the bearer token (610). As described above, at least some of these steps can be performed in a different order or at least partially in parallel. When this information is verified, the correct configuration information can be identified and sent to the device (612), whereby the device can complete its startup procedure using the configuration to be able to perform the intended tasks of the device. In at least some embodiments, this manager may provide or be associated with a console or interface that allows a user or entity associated with this device, and possibly other devices, to manage these devices. In at least one embodiment, an entity can log in to such a console and view a list of devices that have been automatically registered and / or provisioned through such a process.The device can also make calls using one or more application programming interfaces (APIs) published by the manager system, and may utilize self-generated keys for these API calls.

[0018] Data center FIG. 7 shows an exemplary data center 700 that may be used in at least one embodiment. For example, in at least one embodiment, the CDS or device manager may be included in the data center. In at least one embodiment, the data center 700 includes a data center infrastructure layer 710, a framework layer 720, a software layer 730, and an application layer 740.

[0019] As shown in FIG. 7, in at least one embodiment, the data center infrastructure layer 710 may include a resource orchestrator 712, grouped computing resources 714, and node computing resources ("node C.R.") 716(1) to 716(N), where "N" represents any positive integer. In at least one embodiment, the node C.R. 716(1) to 716(N) may include any number of central processing units ("CPUs") or other processors (including accelerators, field programmable gate arrays (FPGAs), graphics processors, etc.), memory devices (e.g., dynamic read-only memory), storage devices (e.g., semiconductor drives or disk drives), network input / output ("NW I / O") devices, network switches, virtual machines ("VMs"), power modules, and cooling modules, but are not limited thereto. In at least one embodiment, one or more of the node C.R. 716(1) to 716(N) may be servers having one or more of the computing resources described above.

[0020] In at least one embodiment, the grouped computing resources 714 may include separate groups of node C.R.s housed within one or more racks (not shown), or multiple racks housed in a data center at various graphical locations (also not shown). Separate groups of node C.R.s within the grouped computing resources 714 may include grouped compute resources, network resources, memory resources, or storage resources that may be configured or allocated to support one or more workloads. In at least one embodiment, some node C.R.s that include a CPU or processor may be grouped within one or more racks to provide compute resources for supporting one or more workloads. In at least one embodiment, one or more racks may also include any combination of any number of power modules, cooling modules, and network switches.

[0021] In at least one embodiment, the resource orchestrator 712 may configure or otherwise control one or more node C.R.s 716(1)-716(N) and / or the grouped computing resources 714. In at least one embodiment, the resource orchestrator 712 may include a software design infrastructure ("SDI") management entity for the data center 700. In at least one embodiment, the resource orchestrator may include hardware, software, or some combination thereof.

[0022] As shown in FIG. 7, in at least one embodiment, the framework layer 720 includes a job scheduler 722, a configuration manager 724, a resource manager 726, and a distributed file system 728. In at least one embodiment, the framework layer 720 may include a framework for supporting software 732 of the software layer 730 and / or one or more applications 742 of the application layer 740. In at least one embodiment, the software 732 or the application 742 may each include web-based service software or an application, such as those provided by Amazon Web Services, Google Cloud, and Microsoft Azure. In at least one embodiment, the framework layer 720 may be a kind of free and open-source software web application framework, such as Apache Spark (registered trademark) (hereinafter referred to as "Spark"), which can use the distributed file system 728 for large-scale data processing (e.g., "big data"), but is not limited thereto. In at least one embodiment, the job scheduler 722 may include a Spark driver to facilitate the scheduling of workloads supported by various layers of the data center 700. In at least one embodiment, the configuration manager 724 may be able to configure different layers, such as the software layer 730 and the framework layer 720 including Spark and the distributed file system 728 for supporting large-scale data processing. In at least one embodiment, the resource manager 726 may be able to manage the clustered or grouped computing resources mapped or allocated to support the distributed file system 728 and the job scheduler 722. In at least one embodiment, the clustered or grouped computing resources may include the grouped computing resources 714 in the data center infrastructure layer 710.In at least one embodiment, the resource manager 726 may manage these mapped or allocated computing resources in cooperation with the resource orchestrator 712.

[0023] In at least one embodiment, the software 732 included in the software layer 730 may include software used by at least a portion of the node C.R. 716(1) - 716(N), the grouped computing resources 714, and / or the distributed file system 728 of the framework layer 720. The one or more types of software may include, but are not limited to, Internet web page search software, email virus scanning software, database software, and streaming video content software.

[0024] In at least one embodiment, the application 742 included in the application layer 740 may include one or more types of applications used by at least a portion of the node C.R. 716(1) - 716(N), the grouped computing resources 714, and / or the distributed file system 728 of the framework layer 720. The one or more types of applications may include, but are not limited to, any number of genomics applications, recognition computing, and software for training or inference, machine learning applications including machine learning framework software (e.g., PyTorch, TensorFlow, Caffe, etc.), or other machine learning applications used in conjunction with one or more embodiments.

[0025] In at least one embodiment, any one of configuration manager 724, resource manager 726, and resource orchestrator 712 may implement any number and type of self-corrective measures based on any amount and type of data obtained in any technically feasible manner. In at least one embodiment, the self-corrective measures may prevent a data center operator of data center 700 from determining a configuration that may be defective and may eliminate parts of the data center that are not being fully utilized and / or have low performance.

[0026] In at least one embodiment, data center 700 may include tools, services, software, or other resources for training one or more machine learning models or for predicting or inferring information using one or more machine learning models according to one or more embodiments described herein. For example, in at least one embodiment, a machine learning model may be trained by calculating weight parameters according to a neural network architecture using the software and computing resources described above with respect to data center 700. In at least one embodiment, a trained machine learning model corresponding to one or more neural networks may be used to infer or predict information using the resources described above with respect to data center 700 by using weight parameters calculated by one or more techniques described herein.

[0027] In at least one embodiment, the data center may use a CPU, an application specific integrated circuit (ASIC), a GPU, an FPGA, or other hardware to perform training and / or inference using the resources described above. Further, the one or more software and / or hardware resources described above may be configured as a service to enable a user to perform training or inference of information, such as image recognition, voice recognition, or other artificial intelligence services.

[0028] Such components can be used for zero-touch enrollment of devices via a secure token-based approach by an associated manager system.

[0029] Computer system FIG. 8 is a block diagram illustrating an exemplary computer system, which may be formed with a processor that may include an execution unit for executing instructions, along with interconnected devices and components, a system-on-chip (SoC), or some combination of these 800. In at least one embodiment, computer system 800 may include components such as processor 802 for using an execution unit that includes logic for executing algorithms for processing data in accordance with the present disclosure, such as in the embodiments described herein. In at least one embodiment, computer system 800 may include a processor such as a PENTIUM® processor family, Xeon®, Itanium®, XScale®, and / or StrongARM® available from Intel Corporation of Santa Clara, California, Intel® Core®, or Intel® Nervana® microprocessor, although other systems (including PCs having other microprocessors, engineering workstations, set-top boxes, etc.) may be used. In at least one embodiment, computer system 800 may execute a version of the WINDOWS® operating system available from Microsoft Corporation of Redmond, Washington, although other operating systems (e.g., UNIX® and Linux®), embedded software, and / or graphical user interfaces may be used.

[0030] Embodiments may be used in other devices such as portable devices and embedded applications. Some examples of portable devices include cellular phones, Internet Protocol devices, digital cameras, personal digital assistants (PDAs), and portable PCs. In at least one embodiment, the embedded application may include a microcontroller, a digital signal processor (DSP), a system-on-chip, network computers (NetPCs), set-top boxes, network hubs, wide area network (WAN) switches, or any other system capable of executing one or more instructions according to at least one embodiment.

[0031] In at least one embodiment, computer system 800 may include a processor 802, without limitation, which may include one or more execution units 808 for performing training and / or inference of a machine learning model according to the techniques described herein, without limitation. In at least one embodiment, computer system 800 is a single-processor desktop or server system, although in another embodiment, computer system 800 may be a multi-processor system. In at least one embodiment, processor 802 may include, without limitation, a complex instruction set computer (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor implementing a combination of instruction sets, or any other processor device, such as a digital signal processor, etc. In at least one embodiment, processor 802 may be coupled to a processor bus 810, which may transmit data signals between processor 802 and other components within computer system 800.

[0032] In at least one embodiment, processor 802 may include, without limitation, a level 1 (L1) internal cache memory (cache) 804. In at least one embodiment, processor 802 may have a single internal cache or multiple levels of internal caches. In at least one embodiment, the cache memory may be external to processor 802. Other embodiments may also include a combination of both internal and external caches, depending on the particular implementation and requirements. In at least one embodiment, register file 806 may store different types of data in various registers including, without limitation, integer registers, floating point registers, status registers, and instruction pointer registers.

[0033] In at least one embodiment, the execution unit 808, which includes logic for performing integer and floating point operations without limitation, is also in the processor 802. In at least one embodiment, the processor 802 may also include a microcode ( "u-code") read-only memory ( "ROM") that stores microcode for certain macro instructions. In at least one embodiment, the execution unit 808 may include logic for handling the packed instruction set 809. In at least one embodiment, by including the packed instruction set 809 in the instruction set of the general-purpose processor together with the associated circuitry for executing the instructions, operations used by many multimedia applications can be executed using the packed data of the general-purpose processor 802. In one or more embodiments, by performing operations on packed data using the full width of the processor's data bus, many multimedia applications can be accelerated and executed more efficiently, thereby eliminating the need to transfer smaller units of data between the processor's data buses to perform one or more operations on one data element at a time.

[0034] In at least one embodiment, the execution unit 808 may also be used in microcontrollers, embedded processors, graphics devices, DSPs, and other types of logic circuits. In at least one embodiment, the computer system 800 may include memory 820 without limitation. In at least one embodiment, the memory 820 may be implemented as a dynamic random access memory ( "DRAM") device, a static random access memory ( "SRAM") device, a flash memory device, or other memory device. In at least one embodiment, the memory 820 may store instructions 819 and / or data 821 represented by data signals that may be executed by the processor 802.

[0035] In at least one embodiment, a system logic chip may be coupled to a processor bus 810 and a memory 820. In at least one embodiment, the system logic chip may include, without limitation, a memory controller hub (“MCH”) 816, and the processor 802 may communicate with the MCH 816 via the processor bus 810. In at least one embodiment, the MCH 816 may provide a high-bandwidth memory path 818 to the memory 820 for storing instructions and data and for storing graphics commands, data, and textures. In at least one embodiment, the MCH 816 may direct data signals between the processor 802, the memory 820, and other components of the computer system 800, and may bridge data signals between the processor bus 810, the memory 820, and the system I / O interface 822. In at least one embodiment, the system logic chip may provide a graphics port for coupling to a graphics controller. In at least one embodiment, the MCH 816 may be coupled to the memory 820 via the high-bandwidth memory path 818, and the graphics / video card 812 may be coupled to the MCH 816 via an Accelerated Graphics Port (“AGP”) interconnect 814.

[0036] In at least one embodiment, computer system 800 may use a system I / O 822, which is a proprietary hub interface bus for coupling MCH 816 to an I / O controller hub (“ICH”) 830. In at least one embodiment, ICH 830 may provide direct connections to several I / O devices via a local I / O bus. In at least one embodiment, the local I / O bus may include, without limitation, a high-speed I / O bus for connecting peripheral devices to memory 820, the chipset, and processor 802. By way of example, it may include, without limitation, a legacy I / O controller 823 including an audio controller 829, a firmware hub (“flash BIOS”) 828, a wireless transceiver 826, data storage 824, a user input and keyboard interface 825, a serial expansion port such as a Universal Serial Bus (“USB”), and a network controller 834. Data storage 824 may comprise a hard disk drive, a floppy (registered trademark) disk drive, a CD-ROM device, a flash memory device, or other mass storage device.

[0037] In at least one embodiment, FIG. 8 shows a system including interconnected hardware devices or “chips,” while in other embodiments, FIG. 8 may show an exemplary system-on-chip (“SoC”). In at least one embodiment, the devices may be interconnected by a proprietary interconnect, a standard interconnect (e.g., PCIe), or some combination thereof. In at least one embodiment, one or more components of computer system 800 may be interconnected using a Compute Express Link (CXL) interconnect.

[0038] Such components can be used for zero-touch registration of devices via a secure token-based approach by the associated manager system.

[0039] FIG. 9 is a block diagram showing an electronic device 900 for utilizing a processor 910 according to at least one embodiment. In at least one embodiment, the electronic device 900 may be, for example, without limitation, a notebook, a tower server, a rack server, a blade server, a laptop, a desktop, a tablet, a mobile device, a phone, an embedded computer, or any other suitable electronic device.

[0040] In at least one embodiment, system 900 may include, without limitation, a processor 910 communicatively coupled to any suitable number or type of components, peripherals, modules, or devices. In at least one embodiment, processor 910 is coupled using a bus or interface such as a 1°C bus, a System Management Bus (“SMBus”), a Low Pin Count (“LPC”) bus, a Serial Peripheral Interface (“SPI”), a High Definition Audio (“HDA”) bus, a Serial Advance Technology Attachment (“SATA”) bus, a Universal Serial Bus (“USB”) (versions 1, 2, 3), or a Universal Asynchronous Receiver / Transmitter (“UART”) bus. In at least one embodiment, FIG. 9 shows a system including interconnected hardware devices or “chips,” while in other embodiments, FIG. 9 may show an exemplary System-on-Chip (“SoC”). In at least one embodiment, the devices shown in FIG. 9 may be interconnected by proprietary interconnects, standard interconnects (e.g., PCIe), or some combination thereof. In at least one embodiment, one or more components of FIG. 9 may be interconnected using a Compute Express Link (CXL) interconnect.

[0041] In at least one embodiment, FIG. 9 shows a display 924, a touch screen 925, a touch pad 930, a Near Field Communications unit (NFC) 945, a sensor hub 940, a thermal sensor 946, an Express Chipset (EC) 935, a Trusted Platform Module (TPM) 938, a BIOS / firmware / flash memory (BIOS, FW flash) 922, a DSP 960, a drive 920 such as a Solid State Disk (SSD) or a Hard Disk Drive (HDD), a wireless local area network unit (WLAN) 950, a Bluetooth unit 952, a Wireless Wide Area Network unit (WWAN) 956, a Global Positioning System (GPS) 955, a camera such as a USB3.0 camera (USB3.0 camera) 954, and / or a Low Power Double Data Rate (LPDDR) memory unit (LPDDR3) 915 implemented, for example, to the LPDDR3 standard. These components may each be implemented in any suitable manner.

[0042] In at least one embodiment, other components may be communicatively coupled to the processor 910 via the components described above. In at least one embodiment, an accelerometer 941, an ambient light sensor (“ALS”), a compass 943, and a gyroscope 944 may be communicatively coupled to the sensor hub 940. In at least one embodiment, a thermal sensor 939, a fan 937, a keyboard 946, and a touch pad 930 may be communicatively coupled to the EC 935. In at least one embodiment, a speaker 963, headphones 964, and a microphone (“mic”) 965 may be communicatively coupled to an audio unit (audio codec and class D amplifier) 962, and this audio unit may be communicatively coupled to the DSP 960. In at least one embodiment, the audio unit 964 may include, for example and without limitation, an audio coder / decoder (“codec”) and a class D amplifier. In at least one embodiment, a SIM card (“SIM”) 957 may be communicatively coupled to the WWAN unit 956. In at least one embodiment, components such as the WLAN unit 950 and the Bluetooth unit 952, as well as the WWAN unit 956, may be implemented in a next generation form factor (“NGFF”).

[0043] Such components can be used for zero-touch registration of the device via a secure token-based approach by the associated manager system.

[0044] FIG. 10 is a block diagram of a processing system according to at least one example. In at least one embodiment, system 1000 includes one or more processors 1002 and one or more graphics processors 1008 and may be a single-processor desktop system, a multi-processor workstation system, or a server system having a number of processors 1002 or processor cores 1007. In at least one embodiment, system 1000 is a processing platform incorporated within a system-on-chip (SoC) integrated circuit for use in a mobile device, portable device, or embedded device.

[0045] In at least one embodiment, system 1000 may include or be incorporated in a server-based gaming platform, a game console including games and media consoles, a mobile gaming console, a portable gaming console, or an online gaming console. In at least one embodiment, system 1000 is a mobile phone, a smartphone, a tablet computing device, or a mobile Internet device. In at least one embodiment, processing system 1000 may also include, be coupled to, or be integrated within wearable devices such as smartwatch wearable devices, smart eyewear devices, augmented reality devices, or virtual reality devices. In at least one embodiment, processing system 1000 is a television or set-top box device having one or more processors 1002 and a graphical interface generated by one or more graphics processors 1008.

[0046] In at least one embodiment, each of one or more processors 1002 includes one or more processor cores 1007 for processing instructions that, when executed, perform operations for system and user software. In at least one embodiment, each of one or more processor cores 1007 is configured to process a particular instruction set 1009. In at least one embodiment, instruction set 1009 may facilitate computing via a complex instruction set computing (CISC), reduced instruction set computing (RISC), or very long instruction word (VLIW). In at least one embodiment, processor cores 1007 may each process a different instruction set 1009, which may include instructions that facilitate emulation of other instruction sets. In at least one embodiment, processor cores 1007 may also include other processing devices such as a digital signal processor (DSP).

[0047] In at least one embodiment, processor 1002 includes a cache memory 1004. In at least one embodiment, processor 1002 may have a single internal cache or multiple levels of internal cache. In at least one embodiment, the cache memory is shared among various components of processor 1002. In at least one embodiment, processor 1002 may also use an external cache (e.g., a level 3 (L3) cache or a last level cache (LLC)) (not shown), which may be shared among processor cores 1007 using known cache coherence techniques. In at least one embodiment, a register file 1006 is further included in processor 1002, and this register file may include different types of registers (e.g., integer registers, floating point registers, status registers, and instruction pointer registers) for storing different types of data. In at least one embodiment, register file 1006 may include general purpose registers or other registers.

[0048] In at least one embodiment, one or more processors 1002 are coupled to one or more interface buses 1010 to transmit communication signals such as address, data, or control signals between the processor 1002 and other components within the system 1000. In at least one embodiment, the interface bus 1010 can be a processor bus such as a version of a Direct Media Interface (DMI) bus in one embodiment. In at least one embodiment, the interface 1010 is not limited to the DMI bus and may include one or more peripheral component interconnect buses (e.g., PCI, PCI Express), a memory bus, or other types of interface buses. In at least one embodiment, the processor 1002 includes an integrated memory controller 1016 and a platform controller hub 1030. In at least one embodiment, the memory controller 1016 facilitates communication between the memory device and other components of the system 1000, while the platform controller hub (PCH) 1030 provides connections to I / O devices via a local I / O bus.

[0049] In at least one embodiment, the memory device 1020 can be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, a flash memory device, a phase change memory device, or any other memory device having suitable performance to serve as a process memory. In at least one embodiment, the memory device 1020 operates as a system memory for the system 1000 and can store data 1022 and instructions 1021 for use when one or more processors 1002 execute an application or process. In at least one embodiment, the memory controller 1016 is also coupled to an optional external graphics processor 1012, which may communicate with one or more graphics processors 1008 within the processor 1002 to perform graphics and media operations. In at least one embodiment, the display device 1011 can be connected to the processor 1002. In at least one embodiment, the display device 1011 can include one or more of an internal display device such as a mobile electronic device or a laptop device, or an external display device attached via a display interface (e.g., a display port, etc.). In at least one embodiment, the display device 1011 can include a head-mounted display (HMD) such as a stereoscopic display device for use in a virtual reality (VR) application or an augmented reality (AR) application.

[0050] In at least one embodiment, the platform controller hub 1030 enables peripheral devices to be connected to the memory device 1020 and the processor 1002 via a high-speed I / O bus. In at least one embodiment, the I / O peripheral devices include, but are not limited to, an audio controller 1046, a network controller 1034, a firmware interface 1028, a wireless transceiver 1026, a touch sensor 1025, and a data storage device 1024 (e.g., a hard disk drive, flash memory, etc.). In at least one embodiment, the data storage device 1024 can be connected via a storage interface (e.g., SATA) or via a peripheral bus such as a Peripheral Component Interconnect bus (e.g., PCI, PCI Express). In at least one embodiment, the touch sensor 1025 can include a touch screen sensor, a pressure sensor, or a fingerprint sensor. In at least one embodiment, the wireless transceiver 1026 can be a WiFi transceiver, a Bluetooth transceiver, or a mobile network transceiver such as a 3G, 4G, or Long Term Evolution (LTE) transceiver. In at least one embodiment, the firmware interface 1028 enables communication with system firmware and can be, for example, a Unified Extensible Firmware Interface (UEFI). In at least one embodiment, the network controller 1034 can enable a network connection to a wired network. In at least one embodiment, a high-performance network controller (not shown) is coupled to the interface bus 1010. In at least one embodiment, the audio controller 1046 is a multi-channel high-definition audio controller. In at least one embodiment, the system 1000 includes an optional legacy I / O controller 1040 for coupling legacy (e.g., Personal System 2 (PS / 2)) devices to the system.In at least one embodiment, the platform controller hub 1030 can also be connected to connection input devices of one or more universal serial bus (USB) controllers 1042, such as a combination of a keyboard and a mouse 1043, a camera 1044, or other USB input devices.

[0051] In at least one embodiment, instances of the memory controller 1016 and the platform controller hub 1030 may be integrated into an individual external graphics processor, such as the external graphics processor 1012. In at least one embodiment, the platform controller hub 1030 and / or the memory controller 1016 may be external to one or more processors 1002. For example, in at least one embodiment, the system 1000 can include an external memory controller 1016 and a platform controller hub 1030, which may be configured as a memory controller hub and a peripheral device controller hub within a system chipset that communicates with the processor 1002.

[0052] Such components can be used for zero-touch registration of devices via a secure token-based approach by a related manager system.

[0053] FIG. 11 is a block diagram of a processor 1100 having one or more processor cores 1102A-1102N, an integrated memory controller 1114, and an integrated graphics processor 1108, according to at least one embodiment. In at least one embodiment, the processor 1100 can include a lesser number of additional cores, including the additional core 1102N represented by the dashed rectangle. In at least one embodiment, each of the processor cores 1102A-1102N includes one or more internal cache units 1104A-1104N. In at least one embodiment, each processor core can also access one or more shared cache units 1106.

[0054] In at least one embodiment, the internal cache units 1104A - 1104N and the shared cache unit 1106 represent a cache memory hierarchy within the processor 1100. In at least one embodiment, the cache memory units 1104A - 1104N may include at least one level of cache for instructions and data within each processor core, as well as one or more levels of shared intermediate - level caches such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, where the highest - level cache before external memory is classified as the LLC. In at least one embodiment, cache coherence logic maintains coherence among the various cache units 1106 and 1104A - 1104N.

[0055] In at least one embodiment, the processor 1100 may also include a set of one or more bus controller units 1116 and a system agent core 1110. In at least one embodiment, the one or more bus controller units 1116 manage a set of peripheral buses such as one or more PCI or PCI Express buses. In at least one embodiment, the system agent core 1110 provides management functions for various processor components. In at least one embodiment, the system agent core 1110 includes one or more integrated memory controllers 1114 for managing access to various external memory devices (not shown).

[0056] In at least one embodiment, one or more of the processor cores 1102A - 1102N include support for simultaneous multithreading. In at least one embodiment, the system agent core 1110 includes components for coordinating and operating cores 1102A - 1102N during multithreaded processing. In at least one embodiment, the system agent core 1110 may further include a power control unit (PCU), which includes logic and components for adjusting the power state of one or more of the processor cores 1102A - 1102N and the graphics processor 1108.

[0057] In at least one embodiment, the processor 1100 further includes a graphics processor 1108 for performing graphics processing operations. In at least one embodiment, the graphics processor 1108 is coupled to a shared cache unit 1106 and a system agent core 1110 that includes one or more integrated memory controllers 1114. In at least one embodiment, the system agent core 1110 also includes a display controller 1111 for causing the output of the graphics processor to be provided to one or more attached displays. In at least one embodiment, the display controller 1111 may also be a separate module coupled to the graphics processor 1108 via at least one interconnect, or may be integrated within the graphics processor 1108.

[0058] In at least one embodiment, a ring - based interconnect unit 1112 is used to couple the internal components of the processor 1100. In at least one embodiment, alternative interconnect units such as point - to - point interconnects, switch interconnects, or other techniques may be used. In at least one embodiment, the graphics processor 1108 is coupled to the ring interconnect 1112 via an I / O link 1113.

[0059] In at least one embodiment, I / O link 1113 represents at least one of a variety of I / O interconnects, including an on-package I / O interconnect that facilitates communication between various processor components and a high-performance embedded memory module 1118 such as an eDRAM module. In at least one embodiment, each of processor cores 1102A - 1102N and graphics processor 1108 uses embedded memory module 1118 as a shared last-level cache.

[0060] In at least one embodiment, processor cores 1102A - 1102N are homogeneous cores that execute a common instruction set architecture. In at least one embodiment, processor cores 1102A - 1102N are heterogeneous from the perspective of an instruction set architecture (ISA), where one or more of processor cores 1102A - 1102N execute a common instruction set, but one or more of the other cores of processor cores 1102A - 1102N execute a subset of the common instruction set, or a different instruction set. In at least one embodiment, processor cores 1102A - 1102N are heterogeneous from the perspective of a microarchitecture, where one or more cores with relatively high power consumption are coupled with one or more cores with lower power consumption. In at least one embodiment, processor 1100 can be implemented on one or more chips or as a SoC integrated circuit.

[0061] Such components can be used for zero-touch registration of devices via a secure token-based approach by a related manager system.

[0062] Other variations are within the scope of the present disclosure. Thus, while the disclosed techniques allow for various modifications and alternative configurations, certain exemplary embodiments among them have been shown in the drawings and described in detail above. However, there is no intention to limit the present disclosure to the specific one or more disclosed forms, and on the contrary, it is intended to cover all modifications, alternative configurations, and equivalents that fall within the spirit and scope of the disclosure as defined by the appended claims.

[0063] In the context of describing the disclosed embodiments (particularly, in the context of the following claims), the terms "a," "an," "the," and similar indicatives are to be construed to cover both the singular and the plural unless otherwise stated herein or clearly contradicted by the context, and are not to be construed as defining terms. The terms "comprising," "having," "including," "containing" are to be construed as open-ended terms (meaning "including, but not limited to") unless otherwise stated. The term "connected" is to be construed as being partially or fully enclosed within, attached to, or joined to one another, even if there is something intervening, when it refers to a physical connection without modification. Reciting a range of values herein is merely intended to serve as a concise way of referring individually to each separate value that falls within the range, unless otherwise stated herein or each separate value is incorporated into the specification as if it were individually recited therein. The use of the term "set" (e.g., "a set of items") or "subset" is to be construed as a non-empty collection comprising one or more members, unless otherwise stated or contradicted by the context. Further, unless otherwise stated or contradicted by the context, the term "subset" of a corresponding set does not necessarily refer to a strict subset of the corresponding set, and the subset and the corresponding set may be equal.

[0064] Conjunctive terms such as "at least one of A, B, and C" or phrases in the form of "at least one of A, B, and C" are understood in the context generally used to indicate that an item, term, etc. is A, or B, or C, or a non-empty subset of any of the sets of A, B, and C, unless there is a specific description to the contrary or it is not clearly negated by the context. For example, in an illustrative example of a set having three members, the conjunctive phrases "at least one of A, B, and C" and "at least one of A, B, and C" refer to any of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus, such conjunctive terms do not generally imply that a given embodiment requires the presence of at least one of each of A, at least one of B, and at least one of C. Further, unless otherwise stated or not clearly negated by the context, the term "a plurality of" indicates a plural state (e.g., "a plurality of items" indicates multiple items). A plurality means at least two items, but may be more if explicitly stated or indicated by the context. Further, unless otherwise stated or not apparent from the context to the contrary, the phrase "based on" means "at least partially based on" and does not mean "based only on".

[0065] The operations of the processes described herein can be executed in any suitable order, unless otherwise stated herein or clearly precluded by context. In at least one embodiment, a process, such as a process described herein (or a variation and / or combination thereof), is executed under the control of one or more computer systems configured with executable instructions and is implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executed collectively on one or more processors, by hardware, or by a combination thereof. In at least one embodiment, the code is stored in a computer-readable storage medium in the form of a computer program comprising a plurality of instructions executable, for example, by one or more processors. In at least one embodiment, the computer-readable storage medium excludes a transient signal (e.g., a propagating transient electrical or electromagnetic transmission), but includes a non-transitory computer-readable storage medium including a non-transitory data storage circuit (e.g., a buffer, cache, and queue) within a transceiver of the transient signal. In at least one embodiment, the code (e.g., executable code or source code) is stored in a set of one or more non-transitory computer-readable storage mediums, the storage mediums storing executable instructions that, when executed by one or more processors of a computer system (i.e., as a result of execution), cause the computer system to perform the operations described herein (or have other memory for storing the executable instructions). The set of non-transitory computer-readable storage mediums, in at least one embodiment, comprises a plurality of non-transitory computer-readable storage mediums, where one or more of the individual non-transitory storage mediums of the plurality of non-transitory computer-readable storage mediums do not have all the code, but the plurality of non-transitory computer-readable storage mediums collectively store all the code.In at least one embodiment, executable instructions are executed such that different instructions are executed by different processors. For example, a non-transitory computer-readable storage medium stores the instructions, a main central processing unit (“CPU”) executes some of the instructions, and a graphics processing unit (“GPU”) executes other instructions. In at least one embodiment, different components of a computer system have separate processors, and the different processors execute different subsets of instructions.

[0066] Accordingly, in at least one embodiment, a computer system is configured to implement one or more services that perform the operations of the processes described herein, either alone or in combination, and such computer systems are composed of applicable hardware and / or software that enable the execution of the operations. Further, a computer system implementing at least one embodiment of the present disclosure is a single device, and in another embodiment, is a distributed computer system comprising multiple devices operating in different ways, such that the distributed computer system performs the operations described herein without a single device performing all of the operations.

[0067] Any examples provided herein, or the use of exemplary language (e.g., “such as”) are intended merely to clarify the embodiments of the present disclosure and, unless otherwise claimed, do not limit the scope of the present disclosure. No language in this specification should be construed as indicating any non-claimed element as essential to the practice of the present disclosure.

[0068] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference had been individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

[0069] In the specification and claims, the terms "coupled" and "connected" may be used along with their derivatives. It should be understood that these terms may not be intended as synonyms for each other. Rather, in certain instances, "connected" or "coupled" may be used to indicate that two or more elements are in direct or indirect physical or electrical contact with each other. Also, "coupled" may mean that two or more elements are not in direct contact with each other but still co - act or interact with each other.

[0070] Unless otherwise specifically stated, throughout the specification, terms such as "process", "compute", "calculate", or "determine" refer to the act and / or process of a computer or computing system, or similar electronic computing device, that manipulates and / or transforms data represented as physical quantities, such as electronic, within the registers and / or memory of a computing system into other data similarly represented as physical quantities within the memory, registers, or other such information storage devices, transmission devices, or display devices of the computing system.

[0071] Similarly, the term "processor" may refer to any device, or portion of a device, that processes electronic data from registers and / or memory and can transform that electronic data into other electronic data storable in registers and / or memory. By way of non-limiting example, a "processor" may be a CPU or GPU. A "computing platform" may include one or more processors. As used herein, a "software" process may include software and / or hardware entities that perform work over time, such as tasks, threads, and intelligent agents. Also, each process may refer to a plurality of processes for executing instructions serially or in parallel, continuously or intermittently. The terms "system" and "method" are used interchangeably herein only insofar as a system can embody one or more methods and a method can be considered a system.

[0072] In this specification, it is possible to refer to obtaining, acquiring, receiving, or inputting analog data or digital data into a subsystem, computer system, or computer-implemented machine. Obtaining, acquiring, receiving, or inputting analog data or digital data can be realized in various ways, such as receiving data as a parameter of a function call or a call to an application programming interface. In some implementations, the process of obtaining, acquiring, receiving, or inputting analog data or digital data can be realized by transferring data via a serial or parallel interface. In another implementation, the process of obtaining, acquiring, receiving, or inputting analog data or digital data can be realized by transferring data via a computer network from the entity providing the data to the entity acquiring it. It is also possible to refer to providing, outputting, transmitting, sending, or presenting analog data or digital data. In various examples, the process of providing, outputting, transmitting, sending, or presenting analog data or digital data can be realized by transferring data as a parameter of the input or output of a function call, an application programming interface, or an inter-process communication mechanism.

[0073] The above discussion describes exemplary implementations of the described techniques, but other architectures may be used to implement the described functions, and this other architecture is intended to be within the scope of the present disclosure. Further, for the purpose of discussion, specific assignments of roles are defined above, but various functions and roles may be assigned and divided in different ways depending on the situation.

[0074] Furthermore, although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter claimed in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as illustrative forms of implementing the claims.

Claims

1. In the device, receiving a challenge token having one or more encryption layers in response to a first request; accessing, by the device, information including at least a destination obtained by decrypting the challenge token; converting, by the device, the decrypted challenge token into a bearer token protected using a secure key of the device; transmitting, by the device, a second request including the bearer token to the destination specified by the challenge token, wherein the bearer token enables the recipient of the request to authenticate the device and provides the device with configuration information that enables the device to operate for a desired purpose; comprising; The challenge token is received from a trusted agency storing contact information of a plurality of devices, and the contact information specifies the addresses and identification information of one or more recipients including one or more manager systems associated with a subset of the plurality of devices. Method.

2. The method according to claim 1, wherein the trusted agency can authenticate the device using a device identifier included in the first request, and the device identifier is mapped to one of the manager systems corresponding to the destination.

3. The method according to claim 1, wherein the challenge token includes one or more of a device identifier for the device, address information of a manager system, an identifier of a manager system, an expiration date of the token, the secure key for the device, and a randomly generated nonce.

4. The method according to claim 1, wherein the one or more encryption layers of the challenge token include at least one of a digital signature of a trusted agency that generates the challenge token, encryption using a self-generated secure key for the device, or encryption using a persistent secure key for the device.

5. The method according to claim 1, wherein the bearer token includes the decrypted challenge token having an attached nonce included in the decrypted challenge token, and the bearer token is signed using a self-generated secure key for the device.

6. The method according to claim 1, wherein the recipient is a manager system associated with the device, and the manager system identifies the configuration information by the bearer token and provides the configuration information to the device, including the step of the device operating for the intended purpose.

7. The method according to claim 6, wherein the manager system can verify the authentication of the device by the trusted institution that generated the challenge token without directly communicating with the trusted institution.

8. The method according to claim 7, wherein the device is authenticated with respect to the manager system, uses only a single request to the manager system, and receives only a single response from the manager system to receive the configuration information.

9. The method according to claim 1, further including the step of the device transmitting the first request at the initial startup of the device when the configuration information is not stored in the device.

10. A device, a processor, when executed by the processor, causes the device to receive, in response to a registration request, a challenge token having one or more encryption layers; access information regarding a manager system obtained by decrypting the challenge token; convert the decrypted challenge token into a bearer token protected by a secure key of the device; and transmit to the manager system a second request for configuration information that enables the device to operate for an intended purpose, the second request including the bearer token for the manager system to authenticate the device and provide the configuration information. a memory including instructions to cause the above to be performed, and wherein the challenge token is received from a trusted institution storing contact information of a plurality of devices, and the contact information specifies addresses and identification information of one or more manager systems associated with a subset of the plurality of devices.

11. The device according to claim 10, wherein the one or more encryption layers of the challenge token include at least one of a digital signature of the trusted institution that generates the challenge token, encryption using a self-generated secure key for the device, or encryption using a persistent secure key for the device.

12. The device according to claim 10, wherein the information in the bearer token enables the manager system to identify the configuration information and provide the configuration information to the device, enabling the device to operate for the intended purpose.

13. The device according to claim 10, wherein the manager system can verify the authentication of the device by the trusted institution that generated the challenge token without directly communicating with the trusted institution.

Images