Token-based zero contact registration for provisioning edge computing applications

Abstract

The invention discloses a token-based zero contact registration for provisioning edge computing applications. Methods according to various embodiments allow for zero-contact registration of devices with respective manager systems. In at least one embodiment, a device at boot-up may contact a central directory service (CDS) to obtain information about an associated manager. The CDS may authenticate the device using device information contained in the request and may send a challenge token to the device in response. The challenge token may include information of the manager that is secured by multiple layers, which can be decrypted only by the authenticated device. The device may decrypt this challenge token to determine manager information, and may convert the challenge token to a bearer token. The device may then send a request to the determined manager that includes a bearer token that may be used by the manager to authenticate the device. The manager may then send appropriate configuration information to the device.

Description

[0001] This application is a divisional application of Chinese patent application No. 202111130653.8 filed on September 26, 2021, with the invention name of “Token-based zero-contact registration for provisioning edge computing applications”. Background Art

[0002] An increasing number of devices are configured to connect and exchange data with other devices or systems over a network (e.g., the Internet). These devices, many of which are often referred to as Internet of Things (“IoT”) devices, often need to be able to locate or identify other devices or systems with which they should communicate. Since these devices may be sold to multiple entities or associated with various external systems, however, these devices are not typically produced using information already stored in these devices, and therefore these devices must obtain or be provided with information about these other devices or systems. In order to avoid having to manually program or configure these devices, which may include many devices for a particular entity, various “zero-touch” methods have been used whereby these devices can automatically obtain this information without manual intervention. However, these existing methods have various problems that may make them unsuitable for certain systems or uses, for example, existing methods require direct communication between a central authority and a device manager and expose the location of the device manager to other devices or entities, which creates unnecessary security risks. In addition, previous methods require multiple communication challenge-responses between each device and the corresponding central authority, which significantly increases the traffic and complexity of these methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Various embodiments according to the present disclosure will be described with reference to the accompanying drawings, in which:

[0004] Figure 1 An architecture for identifying a device manager according to at least one embodiment is shown;

[0005] Figure 2 illustrates an example token that may be used in accordance with at least one embodiment;

[0006] Figure 3 A process for identifying a manager to provide device configuration information according to at least one embodiment is shown;

[0007] Figure 4 A process for generating a challenge token for a device according to at least one embodiment is shown;

[0008] Figure 5 A process for converting a challenge token to a bearer token is shown in accordance with at least one embodiment;

[0009] Figure 6A process for using a bearer token to authenticate a device and provide device configuration information is shown in accordance with at least one embodiment;

[0010] Figure 7 An example data center system is shown in accordance with at least one embodiment;

[0011] Figure 8 A computer system according to at least one embodiment is shown;

[0012] Fig. 9 A computer system according to at least one embodiment is shown;

[0013] Fig.10 illustrates at least a portion of a graphics processor according to one or more embodiments; and

[0014] Fig.11 At least a portion of a graphics processor is shown in accordance with one or more embodiments. DETAILED DESCRIPTION

[0015] Methods according to various embodiments overcome these and other deficiencies by utilizing one or more token-based methods and advantageous signature and encryption structures. In at least one embodiment, a device undergoing initial startup can send an information request to a central agency or other entity, system, or service, from which the device can obtain information and whose address or destination is stored in the device. Then, if the device is identified, the central agency can generate and send a challenge token specific to the device. The challenge token can include one or more security mechanisms (e.g., encrypted 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 agency into an unforgeable bearer token, such as by digitally signing a decrypted version of the challenge token. The device can then present the bearer token to a device manager, or other entities, systems, or services associated with the device, which can provide configuration information for the intended task of the device. The device manager can use the bearer token to verify the device and then send the corresponding configuration data to the device. Then, after the startup is complete, the device can use this configuration information to perform its intended task. This approach may enable managers to authenticate devices using information from a central authority, such as a central directory service (CDS), but without requiring any direct communication between the CDS and individual managers. In embodiments where there is only a single trip between the device and the CDS, the CDS may provide a response from the authenticated device, providing identity information to the manager that only authenticated devices can access, and including a token that the device can provide to the manager to prove that the device is validly directed to that manager.

[0016] Figure 1 An example architecture 100 that can be used to provide such functionality according to at least one embodiment is shown. In this example, there can be various devices 104, 108, 110 that can communicate over at least one network. There can be any number of these devices, and they can be of various device types. Typically, these devices include at least circuits and software that enable them to communicate over a network, such as the Internet, Ethernet, a local area network (LAN), a cellular network, or a peer-to-peer network, via a wired and / or wireless connection. In some embodiments, the device may include an embedded computer circuit, such as a microprocessor or microcontroller, and a memory for storing at least executable instructions and configuration information. These devices may include devices such as computer peripherals, smart vehicles, or other Internet of Things or network-connectable devices.

[0017] As described above, a manufacturer may produce many of these devices, which may be sold to various entities. Each of these entities may want their respective devices to communicate with specific other devices, systems, or services, such as to allow management and configuration of these devices. It may be desirable that at least some of these entities do not have to manually program or configure these devices for this communication, such as providing addresses for one or more device managers that can provide configuration data, updates, and other such information. For example, a retailer may purchase many cameras for its store and may prefer not to have to manually configure each camera to communicate with its security system. In at least one embodiment, these devices may alternatively be configured to contact a central directory service ("CDS") 102 or other such trusted entity, system, or service at startup. The role of the CDS in such a configuration is to authenticate the device and then redirect the device to the appropriate manager server. The directory service 102 may include a server that can receive requests or communications from any of these devices 106, 108, 110, verify information about these devices, and then provide these devices with information about device managers associated with a particular device, such as may be associated with the entity that purchased the device. There may be multiple such manager systems 112, 114, and the directory service 102 (of which there may also be multiple) may provide information to a given device 104 regarding which manager 112 the device should contact to obtain information. In at least one embodiment, the directory service 102 receiving a request from a device may check the information in the device database 116 or other such location to determine whether the information provided in the request corresponds to valid device information. If so, the directory service 102 may query the mapping database 118 or other such storage location to determine the manager 112 that corresponds to (e.g., is mapped to) the device. The directory service 120 may then send this information and any other relevant information to the device 104.

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

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

[0020] Figure 2An example token 200 is shown that can be generated for use in such a process. Each token can contain multiple security layers, using information that only the relevant entity knows. Therefore, an entity attempting to impersonate any of these devices or systems should not be able to decrypt one or more of these tokens during registration or other such processes. The first example token is a request token 202 that can be provided from a device to a CDS or other such entity during a boot process. In this example, the request token includes an identifier of the device ("device ID"). The device ID can be generated by the device based on specific information, which can include a tuple of a device serial number, a TPM identifier (TPM_ID), and a persistent endorsement key (EK) for the device. Other device identifiers can also be used, because in some embodiments, it can correspond to only a serial number. The request token 202 can be encapsulated in an outer security layer, which can include encryption using a self-generated key (SRK), which is an untrusted key in this example. In at least one embodiment, this can be a key generated by the device on behalf of the device, rather than using a persistent key EK. Both the EK and the SRK may correspond to an asymmetric key pair with a public key (PUB) and a private (PRIV) key. Self-generated keys can be used because a given device may be sold or repurposed and therefore may be associated with different managers during the device's lifetime. Using self-generated keys instead of persistent keys will prevent the device from accessing information for a different owner or task that would otherwise be accessible using only the unchanging persistent key. When a device is wiped and repurposed, it can generate a new asymmetric key pair (e.g., SRK_PRIV and SRK_PUB) for authentication so that the device can access only information for its current purpose or information associated with its current owner or manager.

[0021] A second example token is a challenge token 204, which may be generated by the CDS and sent to the requesting device. This challenge token may be protected in such a way that only a valid device (as indicated by the device itself) can decrypt it. The example challenge token includes information useful for the device to determine the appropriate manager and for the manager to verify that the device is contacting the correct manager, such as a manager URL (or other contact address or mechanism) and a manager identifier. The challenge token may also include device-specific information, such as a device ID and SRK_PUB, which may help the device and the corresponding manager verify that the information is associated with that particular device. Other information may also be included, such as an expiration date or time to live (TTL) value, and a random number generated for each token, so that if a second challenge token with the same random number is received, this may be an indication that someone or something is attempting to reuse the same challenge token, which may be handled appropriately.

[0022] The challenge token can be signed using the CDS private key in the inner layer. The signing key can be encrypted using the device's public persistent key EK_PUB in the middle layer. This helps ensure that this challenge token can only be decrypted by the device using the EK_PRIV key in its TPM, regardless of its current owner or administrator. This token can then be encrypted in the outer layer using a self-generated public key (SRK_PUB), which should only be decrypted by the device in the current ownership state using its private self-generated key (SRK_PRIV). Encrypting with EK_PUB and SRK_PUB helps ensure that the correct device obtains access (because SRK is a device-generated key and may be difficult to verify), and that the device only obtains information about its current operating state (because EK persists regardless of owner or state). This challenge token can then be signed in the outer layer using the CDS's private key signature. It should be understood that these layers can be in different orders, and similar, fewer, additional, or alternative layers can be used within the scope of various embodiments.

[0023] A third example token is a bearer token 206 that can be provided to a manager to obtain configuration information from a device that has successfully decrypted a challenge token 204 and determined the appropriate manager information. The bearer token 206 may include a signed but decrypted challenge token that includes information about the manager and the device, as well as a random number and a TTL value in this example. The information about the device and the manager enables the manager to determine that this is a request from a specific device for this specific manager, while the TTL value enables the manager to determine that the bearer token is still valid and the random number enables the manager to determine that no attempt was made to reuse the bearer token. The bearer token can then be signed using the device's self-generated private key (SRK_PRIV) so that the manager can verify that this was sent from the correct device by decrypting using the corresponding public key. It may be important, at least in some embodiments, that the device be signed using a self-generated key rather than a persistent key because the manager should only be able to decrypt data for devices that are in the current state or have the current ownership, and not for other states or ownerships that may be associated with other managers.

[0024] Figure 3An example process 300 for zero-touch registration of a device that may be performed in accordance with at least one embodiment is shown. It should be understood that for this and other processes presented herein, unless otherwise specifically stated, there may be additional, fewer, or alternative steps performed in a similar or alternative order, or at least partially in parallel, within the scope of various embodiments. In this example, a device undergoes an initial boot 302, either as a new device or after a device is wiped to obtain new configuration and manager information. The device may generate and send a request 304 to a central directory service (CDS) or other such entity for manager information, wherein the request may include device identification information, such as in a request token. Figure 2 As discussed. The CDS receiving this request can verify the device information and can determine the appropriate manager for the device. A challenge token 306 can then be received from the CDS to the device, wherein the challenge token includes information about the manager with multiple security bundles. The device can decrypt the challenge token 308 and perform any appropriate verification to obtain a basic token (or decrypted challenge token) that includes the manager information and potential other information discussed here. The device can then generate a bearer token 610, including the decrypted token and digitally signed by the device, thereby effectively converting the challenge token into a bearer token. A request for configuration information including the bearer token can then be sent to a manager 312 determined using the manager information found in the decrypted token. The administrator can verify the information and send the appropriate configuration (and other related) information to the device. The device can receive this configuration information 314 from the manager and can use this received configuration information to configure the device 316. After startup and configuration are complete, the device can operate 318 for the intended purpose.

[0025] Figure 4 An example process 400 is shown that may be performed by an entity or system such as a central directory service (CDS), such as may be related to Figure 3As part of the registration process described. In this example, the CDS may receive a request 402 from a device including a device identifier (ID) encrypted or signed using a self-generated key of the device. The CDS may compare the device identifier and any information contained therein to a database of known valid devices to verify the device 404. In at least one embodiment, this may include not only looking up the serial number of the device in the database, but also ensuring that the key information provided corresponds to the serial number in the device database. If the device cannot be verified, the CDS may ignore the request or send back some type of error message, among other such options. If the device information can be verified, the manager 406 or other related system or service 406 of the device may be determined, for example by querying a set of mappings of known devices. The CDS may generate a token 408, which includes useful information for determining a manager suitable for the device, which may include a device identifier, manager information, an expiration time of the token, and a randomly generated nonce. The token may be wrapped with one or more security bundles to generate a security challenge token 410, which may be encrypted and / or signed one or more times. The challenge token may then be sent to the device 412, where a device with appropriate security information should be able to decrypt and use the information in the challenge token.

[0026] Figure 5 An example process 500 is shown that may be performed by a device that receives a challenge token for password verification, such as in Figure 4 generated in the process of Figure 3As with other processes discussed herein, the order or inclusion of at least some of these steps may vary between embodiments. In this example, a device receives a challenge token 502 from a central directory service (CDS) or other such entity in response to a previous information request. The device can determine the integrity of the challenge token 504 by first verifying the CDS signature on the challenge token. The device can then decrypt the challenge token 506 using a self-generated key as well as the device's persistent key. As described above, using these two keys can ensure that the device only accesses information permitted by its current ownership or usage status and ensure that the device is the device it claims to be. The device that has successfully decrypted the challenge token can then use the CDS public key to verify the internal signature of the challenge token 508. Once decrypted and verified, the device can determine the manager information included in the token 510. This can include, for example, identifiers and address information, such as a uniform resource locator (URL). The device can then combine the signed but decrypted challenge token with a random number from inside the token 512 to create a bearer token, which can then be signed 514 using the self-generated device key. A self-generated key is used instead of a persistent device key because a manager should only be able to access information about a device while the manager is associated with the device and not at any other time. The device can then send a bearer token to the identified manager 516 along with a request for configuration information or other such communication. In this process, the manager does not communicate directly with the CDS because the device communicates back and forth once with the CDS and then the device communicates directly with the manager. In such a process, the identity of the manager is not revealed to the device unless the device can authenticate it through a challenge token.

[0027] Figure 6 An example process 600 is shown that may be performed by a device manager receiving a bearer token with a configuration information request, such as in Figure 5 generated during the process and can be about Figure 3604. The manager may verify that the internal portion of the bearer token is correctly signed by the CDS. In at least one embodiment, the security requirements may indicate that the manager must be able to verify that the device has been referred to the manager by the CDS, but the manager does not have to contact the CDS. The manager may also verify that the manager information contained therein is correct and that the token has not expired 606. The manager may also verify that the external or bundler is signed with the same self-generated device key embedded inside 608. The manager may also verify that the random number within the bearer token signed by the CDS matches the random number outside the CDS signature token but contained in the bearer token 610. As previously described, at least some of these steps may be performed in a different order or at least partially in parallel. Once the information is verified, the correct configuration information may be determined and sent to the device 612 so that the device can complete its startup process using the configuration so that it can perform its intended task. In at least some embodiments, the manager may provide or be associated with a console or interface that enables users or entities associated with the device and potentially other devices to manage these devices. In at least one embodiment, an entity can log into their 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) exposed by the manager system and can use the self-generated keys through these API calls.

[0028] Data Center

[0029] Figure 7 An example data center 700 is shown in which at least one embodiment may be used. For example, in at least one embodiment, the data center may include a CDS or a device manager. 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.

[0030] In at least one embodiment, Figure 7As shown, the data center infrastructure layer 710 may include a resource coordinator 712, grouped computing resources 714, and node computing resources ("node CRs") 716(1)-716(N), where "N" represents any complete positive integer. In at least one embodiment, the node CRs 716(1)-716(N) may include, but are not limited to, 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., solid-state drives or disk drives), network input / output ("NW I / O") devices, network switches, virtual machines ("VMs"), power modules and cooling modules, etc. In at least one embodiment, one or more of the node CRs 716(1)-716(N) may be a server having one or more of the above computing resources.

[0031] In at least one embodiment, the grouped computing resources 714 may include a separate grouping of node CRs housed in one or more racks (not shown), or many racks (also not shown) housed in data centers at various geographic locations. The separate grouping of node CRs within the grouped computing resources 714 may include computing, network, memory or storage resources that can be configured or allocated to support groupings of one or more workloads. In at least one embodiment, several node CRs including a CPU or processor may be grouped in one or more racks to provide computing resources to support one or more workloads. In at least one embodiment, one or more racks may also include any number of power modules, cooling modules and network switches in any combination.

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

[0033] In at least one embodiment, Figure 7As shown, 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 that supports 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 include web-based service software or applications, such as those provided by Amazon Web Services, Google Cloud, and Microsoft Azure. In at least one embodiment, the framework layer 720 may be, but is not limited to, a free and open source software web application framework, such as Apache Spark, which may utilize the distributed file system 728 for large-scale data processing (e.g., "big data"). TM (hereinafter referred to as "Spark"). In at least one embodiment, the job scheduler 722 may include a Spark driver to facilitate 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 a distributed file system 728 for supporting large-scale data processing. In at least one embodiment, the resource manager 726 can manage cluster or group computing resources mapped to or allocated to support the distributed file system 728 and the job scheduler 722. In at least one embodiment, the cluster or group computing resources may include grouped computing resources 714 on the data center infrastructure layer 710. In at least one embodiment, the resource manager 726 may coordinate with the resource coordinator 712 to manage these mapped or allocated computing resources.

[0034] In at least one embodiment, software 732 included in software layer 730 may include software used by at least a portion of node CRs 716(1)-716(N), grouped computing resources 714, and / or distributed file system 728 of framework layer 720. 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.

[0035] In at least one embodiment, one or more applications 742 included in the application layer 740 may include one or more types of applications used by at least a portion of the node CRs 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, cognitive computing, and machine learning applications, including training or inference software, machine learning framework software (e.g., PyTorch, TensorFlow, Caffe, etc.), or other machine learning applications used in conjunction with one or more embodiments.

[0036] In at least one embodiment, any of the configuration manager 724, resource manager 726, and resource coordinator 712 can implement any number and type of self-modification actions based on any number and type of data acquired in any technically feasible manner. In at least one embodiment, the self-modification actions can relieve a data center operator of the data center 700 from making potentially bad configuration decisions and can avoid underutilized and / or poorly performing portions of the data center.

[0037] In at least one embodiment, the data center 700 may include tools, services, software, or other resources to train one or more machine learning models or use one or more machine learning models to predict or infer information 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 the data center 700. In at least one embodiment, by using weight parameters calculated by one or more training techniques described herein, information may be inferred or predicted using trained machine learning models corresponding to one or more neural networks using the resources described above with respect to the data center 700.

[0038] In at least one embodiment, the data center can use a CPU, an application-specific integrated circuit (ASIC), a GPU, an FPGA, or other hardware to use the above resources to perform training and / or reasoning. In addition, one or more of the above software and / or hardware resources can be configured as a service to allow users to train or perform information reasoning, such as image recognition, speech recognition, or other artificial intelligence services.

[0039] Such a component can be used for zero-touch registration of devices with an associated manager system via a secure token-based approach.

[0040] Computer Systems

[0041] According to at least one embodiment, Figure 8 is a block diagram illustrating an exemplary computer system, which may be a system, a system on a chip (SOC), or some combination thereof 800, having interconnected devices and components that form a processor, which may include execution units to execute instructions. In at least one embodiment, the computer system 800 may include, but is not limited to, components such as those described in the embodiments described herein, such as a processor 802, to employ execution units including logic to execute algorithms for process data. In at least one embodiment, the computer system 800 may include a processor, such as Processor series, Xeon TM , XScale TM and / or StrongARM TM , Core TM , or from Intel Corporation in Santa Clara, California Nervana TM microprocessor, although other systems (including PCs with other microprocessors, engineering workstations, set-top boxes, etc.) may also 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 also be used.

[0042] Embodiments may be used in other devices, such as handheld devices and embedded applications. Some examples of handheld devices include cellular phones, Internet protocol devices, digital cameras, personal digital assistants ("PDAs"), and handheld PCs. In at least one embodiment, the embedded application may include a microcontroller, a digital signal processor ("DSP"), a single chip system, a network computer ("NetPC"), a set-top box, a network hub, a wide area network ("WAN") switch, or any other system that can execute one or more instructions according to at least one embodiment.

[0043] In at least one embodiment, the computer system 800 may include, but is not limited to, a processor 802, which may include, but is not limited to, one or more execution units 808 to perform machine learning model training and / or reasoning according to the techniques described herein. In at least one embodiment, the computer system 800 is a single-processor desktop or server system, but in another embodiment, the computer system 800 may be a multi-processor system. In at least one embodiment, the processor 802 may include, but is not limited to, a complex instruction set computer ("CISC") microprocessor, a reduced instruction set computing ("RISC") microprocessor, a very long instruction word ("VLIW") microprocessor, a processor that implements an instruction set combination, or any other processor device, such as a digital signal processor. In at least one embodiment, the processor 802 may be coupled to a processor bus 810, which may transmit data signals between the processor 802 and other components in the computer system 800.

[0044] In at least one embodiment, processor 802 may include, but is not limited to, 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 cache. In at least one embodiment, cache memory may reside external to processor 802. Other embodiments may also include a combination of 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 but not limited to integer registers, floating point registers, status registers, and instruction pointer registers.

[0045] In at least one embodiment, an execution unit 808, including but not limited to logic to perform integer and floating point operations, also resides in the processor 802. In at least one embodiment, the processor 802 may also include a microcode ("ucode") read-only memory ("ROM") for storing microcode for certain macroinstructions. In at least one embodiment, the execution unit 808 may include logic to process a 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 802, along with associated circuitry to execute the instructions, operations used by many multimedia applications may be performed using packed data in the general purpose processor 802. In one or more embodiments, many multimedia applications may be executed faster and more efficiently by using the full width of the processor's data bus to perform operations on packed data, which may eliminate the need to transfer smaller units of data over the processor's data bus to perform one or more operations one data element at a time.

[0046] In at least one embodiment, execution unit 808 may also be used in microcontrollers, embedded processors, graphics devices, data signal processing, and other types of logic circuits. In at least one embodiment, computer system 800 may include, but is not limited to, memory 820. In at least one embodiment, 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 storage device. In at least one embodiment, memory 820 may store instructions 819 and / or data 821 represented by data signals that may be executed by processor 802.

[0047] In at least one embodiment, the system logic chip can be coupled to the processor bus 810 and the memory 820. In at least one embodiment, the system logic chip can include, but is not limited to, a memory controller hub ("MCH") 816, and the processor 802 can communicate with the MCH 816 via the processor bus 810. In at least one embodiment, the MCH 816 can provide a high-bandwidth memory path 818 to the memory 820 for instruction and data storage and for storage of graphics commands, data, and textures. In at least one embodiment, the MCH 816 can direct data signals between the processor 802, the memory 820, and other components in the computer system 800 and bridge data signals between the processor bus 810, the memory 820, and the system I / O 822. In at least one embodiment, the system logic chip can provide a graphics port for coupling to a graphics controller. In at least one embodiment, the MCH 816 can be coupled to the memory 820 via the high-bandwidth memory path 818 and the graphics / video card 812 can be coupled to the MCH 816 via an accelerated graphics port ("AGP") interconnect 814.

[0048] In at least one embodiment, the computer system 800 may use a system I / O 822 that is a proprietary hub interface bus to couple the MCH 816 to an I / O controller hub ("ICH") 830. In at least one embodiment, the ICH 830 may provide direct connections to certain I / O devices through a local I / O bus. In at least one embodiment, the local I / O bus may include, but is not limited to, a high-speed I / O bus used to connect peripheral devices to the memory 820, the chipset, and the processor 802. Examples may include, but are not limited to, an audio controller 829, a firmware hub ("flash BIOS") 828, a wireless transceiver 826, a data memory 824, a traditional I / O controller 823 including a user input and keyboard interface 825, a serial expansion port 827, such as a universal serial bus ("USB"), and a network controller 834. Data storage 824 may include a hard drive, a floppy drive, a CD-ROM device, a flash memory device, or other mass storage device.

[0049] In at least one embodiment, Figure 8 A system comprising interconnected hardware devices or "chips" is shown, while in other embodiments, Figure 8 An exemplary system on a chip ("SoC") is shown. In at least one embodiment, the devices can be interconnected with a proprietary interconnect, a standardized interconnect (e.g., PCIe), or some combination thereof. In at least one embodiment, one or more components of computer system 800 are interconnected using a Compute Express Link (CXL) interconnect.

[0050] ]Such components can be used to enable zero-touch registration of devices with relevant management systems through a secure token-based method.

[0051] Fig. 9 is a block diagram illustrating 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, but not limited to, 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.

[0052] In at least one embodiment, system 900 may include, but is not limited to, processor 910, which is communicatively coupled to any suitable number or kind of components, peripherals, modules, or devices. In at least one embodiment, processor 910 is coupled using a bus or interface, such as a Ic bus, a system management bus ("SMBus"), a low pin interface (LPC) bus, a serial peripheral interface ("SPI"), a high definition audio ("HDA") bus, a serial advanced 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 A system is shown that includes interconnected hardware devices or "chips", while in other embodiments, Fig. 9 An exemplary system on a chip ("SoC") may be shown. In at least one embodiment, Fig. 9 The devices shown in can be interconnected with a proprietary interconnect, a standardized interconnect (e.g., PCIe), or some combination thereof. In at least one embodiment, Fig. 9 One or more components of the system are interconnected by one or more components using a Compute Express Link (CXL) interconnect.

[0053] In at least one embodiment, Fig. 9The display 924, touch screen 925, touch pad 930, near field communication unit ("NFC") 945, sensor hub 940, thermal sensor 946, high-speed chipset ("EC") 935, trusted platform module ("TPM") 938, BIOS / firmware / flash ("BIOS, FW flash") 922, DSP 960, drive 920 such as solid state disk ("SSD") or hard disk drive ("HDD"), wireless local area network unit ("WLAN") 950, Bluetooth unit 952, wireless wide area network unit ("WWAN") 956, global positioning system (GPS) 955, camera ("USB 3.0 camera") 954 (e.g., USB 3.0 camera) and / or low power double data rate ("LPDDR") storage unit ("LPDDR3") 915, for example, LPDDR3 standard may be included. Each of these components may be implemented in any suitable manner.

[0054] In at least one embodiment, other components may be communicatively coupled to the processor 910 through the components discussed above. In at least one embodiment, the accelerometer 941, ambient light sensor (“ALS”) 942, compass 943, and gyroscope 944 may be communicatively coupled to the sensor hub 940. In at least one embodiment, the thermal sensor 939, fan 937, keyboard 946, and touchpad 930 may be communicatively coupled to the EC 935. In at least one embodiment, the speaker 963, earphone 964, and microphone (“mic”) 965 may be communicatively coupled to the audio unit (“audio codec and class-d amplifier”) 962, which in turn may be communicatively coupled to the DSP 960. In at least one embodiment, the audio unit 964 may include, for example, but not limited to, an audio encoder / decoder (“codec”) and a class-D amplifier. In at least one embodiment, the 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 and the WWAN unit 956 may be coupled to a Next Generation Form Factor connector ("NGFF").

[0055] Such components can be used to enable zero-touch registration of devices with relevant management systems through a secure token-based method.

[0056] Fig.10is a block diagram of a processing system according to at least one embodiment. 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 with a large number of processors 1002 or processor cores 1007. In at least one embodiment, system 1000 is a processing platform integrated in a system-on-chip (SoC) integrated circuit for use in a mobile, handheld, or embedded device.

[0057] In at least one embodiment, system 1000 may include or be incorporated into a server-based gaming platform, and gaming consoles include gaming and media consoles, mobile gaming consoles, handheld gaming consoles, or online gaming consoles. In at least one embodiment, system 1000 is a mobile phone, a smart phone, a tablet device, or a mobile internet device. In at least one embodiment, processing system 1000 may also include, be coupled to, or be integrated into a wearable device, such as a smart watch wearable device, a smart glasses device, an augmented reality device, or a virtual reality device. 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.

[0058] In at least one embodiment, one or more processors 1002 each include one or more processor cores 1007 to process instructions, which, when executed, perform operations of the system and user software. In at least one embodiment, each of the one or more processor cores 1007 is configured to process a specific instruction set 1009. In at least one embodiment, the instruction set 1309 can facilitate a complex instruction set computer (CISC), a reduced instruction set computer (RISC), or calculations by very long instruction words (VLIW). In at least one embodiment, the processor cores 1007 can each process different instruction sets 1009, which may include instructions that facilitate emulation of other instruction sets. In at least one embodiment, the processor cores 1007 may also include other processing devices, such as a digital signal processor (DSP).

[0059] In at least one embodiment, the processor 1002 includes a cache memory 1004. In at least one embodiment, the processor 1002 may have a single internal cache or multiple levels of internal cache. In at least one embodiment, the cache memory is shared between various components of the processor 1002. In at least one embodiment, the processor 1002 also uses an external cache (e.g., a level 3 (L3) cache or a last level cache (LLC)) (not shown), which can be shared between the processor cores 1007 using known cache coherence techniques. In at least one embodiment, the processor 1002 additionally includes a register file 1006, which 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, the register file 1006 may include general registers or other registers.

[0060] 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 addresses, data, or control signals between the processors 1002 and other components in the system 1000. In at least one embodiment, the interface bus 1010 may be a processor bus in one embodiment, such as a version of a direct media interface (DMI) bus. In at least one embodiment, the interface 1010 is not limited to a DMI bus, and may include one or more peripheral component interconnect buses (e.g., PCI, PCI Express), memory buses, 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 memory devices and other components of the system 1000, while the platform controller hub (PCH) 1030 provides connections to I / O devices through a local I / O bus.

[0061] In at least one embodiment, the memory device 1020 may 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 other memory device with appropriate performance as process memory. In at least one embodiment, the memory device 1020 may operate as system memory of the system 1000 to store data 1022 and instructions 1021 for use when one or more processors 1002 execute applications or processes. In at least one embodiment, the integrated memory controller 1016 is also coupled to an optional external graphics processor 1012, which may communicate with one or more graphics processors 1008 in the processor 1002 to perform graphics and media operations. In at least one embodiment, a display device 1011 may be connected to the processor 1002. In at least one embodiment, the display device 1011 may include one or more internal display devices, such as in a mobile electronic device or laptop device, or an external display device connected via a display interface (e.g., DisplayPort, etc.). In at least one embodiment, the display device 1011 may include a head mounted display (HMD), such as a stereoscopic display device used in virtual reality (VR) applications or augmented reality (AR) applications.

[0062] 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 peripherals 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, a data storage device 1024 (e.g., a hard 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 Wi-Fi 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 implements communication with the system firmware, such as a unified extensible firmware interface (UEFI). In at least one embodiment, the network controller 1034 can implement 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 traditional I / O controller 1040 for coupling traditional (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 one or more universal serial bus (USB) controllers 1042 to connect input devices, such as a keyboard and mouse 1043 combination, a camera 1044, or other USB input devices.

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

[0064] Such components can be used to enable zero-touch registration of devices with relevant management systems through a secure token-based method.

[0065] Fig.111 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 may include additional cores, up to and including the additional core 1102N represented by the dashed box. 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 may also have access to one or more shared cache units 1106.

[0066] 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 instruction and data cache in each processor core and one or more shared mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, with external memory being classified as the highest level of cache before the LLC. In at least one embodiment, cache coherence logic maintains coherence between the various cache units 1106 and 1104A-1104N.

[0067] 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 to manage access to various external memory devices (not shown).

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

[0069] In at least one embodiment, the processor 1100 additionally includes a graphics processor 1108 to perform graphics processing operations. In at least one embodiment, the graphics processor 1108 is coupled to the shared cache unit 1106 and the system agent core 1110, including one or more integrated memory controllers 1114. In at least one embodiment, the system agent core 1110 also includes a display controller 1111 to drive the graphics processor output to one or more coupled displays. In at least one embodiment, the display controller 1111 can also be a separate module coupled to the graphics processor 1108 via at least one interconnect, or can be integrated within the graphics processor 1108.

[0070] 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 may be used, such as point-to-point interconnects, switched interconnects, or other technologies. In at least one embodiment, the graphics processor 1108 is coupled to the ring interconnect 1112 via an I / O link 1113.

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

[0072] In at least one embodiment, the processor cores 1102A-1102N are isomorphic cores that execute a common instruction set architecture. In at least one embodiment, the processor cores 1102A-1102N are heterogeneous in terms of instruction set architecture (ISA), wherein one or more processor cores 1102A-1102N execute a common instruction set, and one or more other processor cores 1102A-1102N execute a subset of a common instruction set or a different instruction set. In at least one embodiment, the processor cores 1102A-1102N are heterogeneous in terms of microarchitecture, wherein 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, the processor 1100 can be implemented on one or more chips or as a SoC integrated circuit.

[0073] Such components can be used to enable zero-touch registration of devices with relevant management systems through a secure token-based method.

[0074] Other variations are within the spirit of the present disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described in detail above. However, it should be understood that there is no intention to limit the disclosure to one or more specific forms disclosed, but on the contrary, it is intended to cover all modifications, alternative constructions, and equivalents that fall within the spirit and scope of the disclosure as defined by the appended claims.

[0075] Unless otherwise noted, unless otherwise noted or clearly contradicted by context, the use of the terms "a", "an" and "the" and similar references in the context of describing the disclosed embodiments (particularly in the context of the appended claims) should be interpreted as covering the singular and the plural, rather than as a definition of a term. The terms "comprising", "having", "including" and "containing" should be interpreted as open-ended terms (meaning "including but not limited to"). The term "connected" when unmodified refers to a physical connection and should be understood as part or all of being contained in, connected to or connected together, even if there are any intervening. Unless otherwise noted herein, the reference to numerical ranges herein is intended only to be used as a shorthand method of referring to each individual value falling within the range individually, and each individual value is incorporated into the specification as if it were recited individually herein. Unless otherwise indicated or contradicted by context, the use of the term "set" (e.g., "a set of items") or "subset" should be interpreted as a non-empty set including one or more members. In addition, unless otherwise indicated or contradicted by context, the term "subset" of a corresponding set does not necessarily mean a proper subset of the corresponding set, but a subset and a corresponding set may be equal.

[0076] Unless otherwise expressly indicated or clearly contradicted by context, conjunction language such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C" is understood in context to be generally used to refer to items, and the term etc. can be A or B or C, or any non-empty subset of the set A and B and C. For example, in a set having three members, the conjunction 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}. Therefore, such conjunction language is not generally intended to imply that certain embodiments require the presence of at least one of A, at least one of B, and at least one of C. In addition, unless otherwise indicated or contradicted by context, the term "plurality" refers to a plural state (e.g., "plurality of items" means a plurality of items). The number of items in the plural is at least two, but can be plural when expressly or by context indicates. Further, the phrase "based on" means "based at least in part on" rather than "based solely on" unless stated otherwise or clear from the context.

[0077] Unless otherwise noted herein or clearly contradictory to the environment, the operations of the processes described herein may be performed in any suitable sequence. In at least one embodiment, processes such as those described herein (or their variations and / or combinations thereof) are performed under the control of one or more computer systems configured with executable instructions, and are implemented as codes (e.g., executable instructions, one or more computer programs, or one or more applications) that are jointly executed on one or more processors by hardware or a combination thereof. In at least one embodiment, the code is stored on a computer-readable storage medium, for example, in the form of a computer program, which includes a plurality of instructions that can be executed by one or more processors. In at least one embodiment, the computer-readable storage medium is a non-transitory computer-readable storage medium that does not include a transient signal (e.g., a transient electrical or electromagnetic transmission of a propagation), but includes a non-transitory data storage circuit (e.g., a buffer, a cache, and a queue) in a transceiver of a transient signal. In at least one embodiment, code (e.g., executable code or source code) is stored on a set of one or more non-transitory computer-readable storage media (or other memory for storing executable instructions) on which executable instructions are stored, and when executed (i.e., due to being executed) by one or more processors of a computer system, the computer system performs the operations described herein. In at least one embodiment, a set of non-transitory computer-readable storage media includes a plurality of non-transitory computer-readable storage media and one or more single non-transitory storage media of the plurality of non-transitory computer-readable storage media lacking all codes, while the plurality of non-transitory computer-readable storage media collectively store all codes. In at least one embodiment, the executable instructions are executed so that different instructions are executed by different processors, for example, a non-transitory computer-readable storage medium stores instructions, and a main central processing unit ("CPU") executes some instructions, while a graphics processing unit ("GPU") executes other instructions. In at least one embodiment, different components of the computer system have separate processors, and different processors execute different subsets of instructions.

[0078] Thus, in at least one embodiment, a computer system is configured to implement one or more services that individually or collectively perform the operations of the processes described herein, and such a computer system is configured with applicable hardware and / or software capable of implementing the operations. In addition, a computer system that implements at least one embodiment of the present disclosure is a single device, and in another embodiment, is a distributed computer system that includes multiple devices that operate in different ways, so that the distributed computer system performs the operations described herein, and so that a single device does not perform all operations.

[0079] The use of any and all examples or exemplary language (e.g., "such as") provided herein is intended only to better illustrate embodiments of the present disclosure and does not limit the scope of the disclosure unless otherwise stated. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0080] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference.

[0081] In the description and claims, the terms "coupled" and "connected" and their derivatives may be used. It should be understood that these terms may not be intended as synonyms for each other. On the contrary, in specific examples, "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. "Coupled" may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0082] Unless otherwise specifically stated, it is understood that throughout the specification, terms such as "processing", "calculating", "computing", "determining", etc. refer to the actions and / or processes of a computer or computing system or similar electronic computing device to process and / or convert data represented as physical quantities (e.g., electronic) in registers and / or memories of the computing system into other data similarly represented as physical quantities in the memory, registers or other such information storage, transmission or display devices of the computing system.

[0083] In a similar manner, the term "processor" may refer to any device or part of a device that processes electronic data from registers and / or memory and converts the electronic data into other electronic data that can be stored in registers and / or memory. As a non-limiting example, a "processor" may be a CPU or a GPU. A "computing platform" may include one or more processors. As used herein, a "software" process may include, for example, software and / or hardware entities that perform work over time, such as tasks, threads, and intelligent agents. Moreover, each process may refer to multiple processes to execute instructions continuously or intermittently, sequentially or in parallel. Because a system may embody one or more methods and a method may be considered a system, the terms "system" and "method" are used interchangeably herein.

[0084] In this document, reference may be made to obtaining, acquiring, receiving or inputting analog or digital data into a subsystem, a computer system or a computer-implemented machine. The process of obtaining, acquiring, receiving or inputting analog and digital data may be accomplished in a variety of ways, such as by receiving data as a parameter of a function call or a call to an application programming interface. In some embodiments, the process of obtaining, acquiring, receiving or inputting analog or digital data may be accomplished by transmitting data via a serial or parallel interface. In another embodiment, the process of obtaining, acquiring, receiving or inputting analog or digital data may be accomplished by transmitting data from a providing entity to an acquiring entity via a computer network. Reference may also be made to providing, outputting, transmitting, sending or presenting analog or digital data. In various examples, the process of providing, outputting, transmitting, sending or presenting analog or digital data may be accomplished by transmitting data as an input or output parameter of a function call, an application programming interface or an inter-process communication mechanism.

[0085] Although the above discussion sets forth example implementations of the described techniques, other architectures may be used to implement the described functionality and are intended to be within the scope of the present disclosure. In addition, although specific responsibility allocations are defined above for discussion purposes, various functions and responsibilities may be allocated and divided in different ways depending on the circumstances.

[0086] Furthermore, although the subject matter has been described in language specific to structural features and / or methodological acts, it should 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 exemplary forms of implementing the claims.

Claims

1. A method comprising: receiving, using a device, a challenge token issued by a trusted authority that stores information of one or more manager systems associated with a plurality of devices; generating a bearer token protected with a security key of the device based at least in part on the challenge token; as well as A request including the bearer token is sent to a destination specified by the challenge token, wherein a recipient of the request is able to authenticate the device based at least on a device identifier in the challenge token, the device identifier being mapped to a manager system of the one or more manager systems corresponding to the destination.

2. The method of claim 1, wherein the stored information specifies address and identification information of one or more recipients, the one or more recipients comprising the one or more manager systems associated with the plurality of devices.

3. The method according to claim 1, further comprising: decrypting, by the device, the challenge token to access the destination specified by the challenge token; as well as The decrypted challenge token is converted into the bearer token.

4. The method of claim 1, wherein the challenge token comprises one or more of a device identifier of the device, manager system address information, a manager system identifier, a token expiration time, the security key of the device, and a randomly generated nonce.

5. A method according to claim 1, wherein the challenge token includes one or more layers of encryption, the one or more layers of encryption including at least one of a digital signature of the trusted authority that generated the challenge token, encryption using a self-generated security key of the device, or encryption using a persistent security key of the device.

6. The method of claim 1, wherein the bearer token comprises a decrypted challenge token to which is appended a random number included in the decrypted challenge token, the bearer token being signed with a self-generated security key of the device.

7. The method according to claim 1, further comprising: Configuration information is provided to the device, wherein the bearer token enables the manager system to determine and provide the configuration information to the device to enable the device to operate for an intended purpose.

8. The method of claim 7, wherein the manager system is enabled to verify the authentication of the device by the trusted authority that generated the challenge token without directly communicating with the trusted authority.

9. The method according to claim 8, further comprising: Configuration information is provided to the device, wherein the device is capable of being authenticated by the manager system and is capable of receiving the configuration information using only a single request to the manager system and receiving only a single response from the manager system.

10. The method according to claim 1, further comprising: providing configuration information to the device; as well as The challenge token is received when the configuration information is not stored on the device during initial boot-up of the device.

11. A device comprising: processor; and a memory comprising instructions that, when executed by the processor, cause the device to: receiving, with a device, a challenge token having one or more layers of encryption, wherein the challenge token is received from a trusted authority that stores information of one or more manager systems associated with a plurality of devices; generating a bearer token protected with a security key of the device based at least on the challenge token; as well as A request including the bearer token is sent to a manager system to enable the manager system to verify the authentication of the device by the trusted authority without directly communicating with the trusted authority.

12. The device of claim 11, wherein the stored information specifies address and identification information of the one or more manager systems associated with the plurality of devices.

13. A device according to claim 12, wherein the one or more layers of encryption of the challenge token include at least one of a digital signature of the trusted authority that generated the challenge token, encryption using a self-generated security key of the device, or encryption using a persistent security key of the device.

14. The apparatus of claim 11, wherein the instructions, when executed by the processor, further cause the apparatus to: Configuration information is provided to the device, wherein information in the bearer token enables the manager system to determine the configuration information and provide the configuration information to the device to enable the device to operate for an intended purpose.

15. The apparatus of claim 11, wherein the instructions, when executed by the processor, further cause the apparatus to: Configuration information is provided to the device, wherein the device is capable of being authenticated by the manager system and is capable of receiving the configuration information using only a single request to the manager system and receiving only a single response from the manager system.

16. A processor comprising one or more processing units, wherein the one or more processing units are configured to: receiving, with a device, a challenge token having one or more layers of encryption, wherein the challenge token is received from a trusted authority that stores information of one or more manager systems associated with a plurality of devices; generating a bearer token protected with a security key of the device based at least on the challenge token; as well as A request including the bearer token is sent to a manager system to enable the manager system to verify the authentication of the device by the trusted authority without directly communicating with the trusted authority.

17. The processor of claim 16, wherein at least one of the one or more processing units is further configured to: providing configuration information to the device; and Additional identification information of the manager system is verified based on the bearer token before sending the configuration information to the device.

18. The processor of claim 16, wherein the digital signature on the bearer token corresponds to a self-generated security key of the device, the self-generated security key being different from a persistent key of the device used to encrypt the challenge token.

19. The processor of claim 16, wherein the bearer token enables the manager system to verify authentication of the device by the trusted authority that generated the challenge token without directly communicating with the trusted authority.

20. The processor of claim 17, wherein the bearer token enables the manager system to provide the configuration information to the device to enable the device to operate for an intended purpose.

Images