JP7708599B2 - Token-based zero-touch enrollment for provisioning edge computing applications - Google Patents

Description

The present invention relates to token-based zero-touch enrollment for provisioning edge computing applications.

An increasing number of different devices are being configured to connect and exchange data with other devices or systems over a network such as the Internet. These devices are often referred to as Internet of Things ("IoT") devices and need to be able to locate or identify other devices or systems with which they are to communicate. However, because these devices may be sold to multiple entities or associated with a wide variety of external systems, these devices are not typically produced with this information already stored on them, and 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" approaches are utilized, whereby the devices can automatically obtain this information without manual intervention. However, these conventional approaches have various problems, such as the need for direct communication between a central authority and a device manager, exposing the location of the device manager to other devices or entities, creating unnecessary security risks, which may make the conventional approaches undesirable for certain systems or uses. Furthermore, conventional approaches require a multi-trip communication challenge-response between each device and a corresponding central authority, which significantly increases the traffic and complexity of these approaches.

Various embodiments of the present disclosure will be described with reference to the drawings.

FIG. 1 illustrates an architecture for identifying a device manager, according to at least one embodiment. FIG. 2 illustrates an exemplary token that may be utilized by at least one embodiment. FIG. 1 illustrates a process for identifying a manager and providing configuration information about a device, according to at least one embodiment. FIG. 1 illustrates a process for generating a challenge token for a device, according to at least one embodiment. FIG. 1 illustrates a process for converting a challenge token to a bearer token, according to at least one embodiment. FIG. 1 illustrates a process for validating a device and providing configuration information for the device using a bearer token, according to at least one embodiment. FIG. 1 illustrates an exemplary data center system, according to at least one embodiment. FIG. 1 illustrates a computer system according to at least one embodiment. FIG. 1 illustrates a computer system according to at least one embodiment. FIG. 2 illustrates at least a portion of a graphics processor in accordance with one or more embodiments. FIG. 2 illustrates at least a portion of a graphics processor in accordance with one or more embodiments.

Approaches according to various embodiments overcome these and other deficiencies by utilizing one or more token-based approaches using advantageous signature and encryption structures. In at least one embodiment, a device undergoing 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 with a particular key or digital signature) that allow 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 a 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, which can provide configuration information about the device for the device's intended task. The device manager can utilize the bearer token to verify the device and then send the device its respective configuration data. The device can then utilize this configuration information to perform its intended tasks after boot-up is complete. With such an approach, the manager can authenticate the device using information from a central authority, such as a central directory service (CDS), without any direct communication between the CDS and the various managers. In one embodiment, where there may be only one trip between the device and the CDS, the CDS can provide a response that validates the device, provides identifying information about the manager that only the validated device can access, and includes a token that the device can provide to the manager to prove that the device is legitimately intended for that manager.

1 illustrates 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 over at least one network. There may be any number of these devices and they may be of various device types. Generally, these devices include at least circuitry and software that enables them 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, through wired and/or wireless connections. In some embodiments, the devices may include embedded computer circuitry, which may include a microprocessor or microcontroller, and at least memory for storing executable instructions and configuration information. These devices may include devices such as computer peripherals, smart vehicles, or other IoT devices or network-connectable devices.

As mentioned above, a manufacturer may produce many of these devices, and these devices may be sold to various entities. Each of these entities may want each device to communicate with certain other devices, systems, or services, which may allow for management and configuration of these devices. For at least some of these entities, it may be desirable not to have 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 store and would prefer not to have to manually configure each of these cameras to communicate with its security system. In at least one embodiment, these devices may 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 the appropriate manager server. The directory service 102 may include a server or computing system or device that can receive requests or communications from any of these devices 106, 108, 110, verify information about those devices, and then send those devices information about the device manager associated with the particular device, such as a device manager that 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 be more than one) may provide a given device 104 with information about which manager 112 the device should contact for information. In at least one embodiment, the directory service 102 receiving a request from a device may 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. If so, the directory service 102 may consult a mapping database 118 or other such storage location to identify the manager 112 that corresponds (e.g., mapped) to that device. The directory service 120 may then send this information, and any other relevant information, to the device 104.

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

In at least one embodiment, token-based communications 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 contain or be protected using information specific to one or more of the device, the CDS, and the respective managers. For example, the device can have a serial number and one or more identifiers of internal components, such as a trusted platform module ("TPM"), which can store sensitive information, such as one or more private keys. The device and the 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 increase the security of these communications.

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

A second exemplary token is a challenge token 204 that 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 can decrypt it when the device presents itself as a valid device. This exemplary challenge token includes information that is useful for the device to identify the appropriate manager and for the manager to verify that the device is contacting the correct manager, such as the manager's URL (or other contact address or mechanism) and the manager's identifier. The challenge token may also include information that is specific to the device, such as deviceID and SRK_PUB, which helps the device and the corresponding manager to verify that this information is related to this particular device. Similarly, additional information may also be included, such as an expiration or time to live (TTL) value and a random nonce that is generated for each token, so that if a second challenge token is received with the same nonce, this may be an indication that someone or something is trying to reuse the same challenge token.

At the inner layer, the CDS private key can be used to sign this challenge token. At the middle layer, the signed key can be used to encrypt the device's persistent public key EK_PUB. This helps ensure that only the device can decrypt this challenge token with the EK_PRIV key in its TPM, regardless of the device's current owner or manager. At the outer layer, the token can then be encrypted with a self-generated public key (SRK_PUB) that should only be decryptable by the device in its current ownership state, using the device's self-generated private key (SRK_PRIV). Encrypting with both EK_PUB and SRK_PUB helps ensure that the right device is getting access (since SRK is a device-generated key that can be difficult to authenticate) and that the device is only getting information about its current operating state (since EK persists across all owners or states). At the outer-external layer, the CDS private key signature can then be used to sign this challenge token. It is understood that these layers may be in a different order and that similar, fewer, additional, or alternative layers may be used within the scope of various embodiments.

A third exemplary token is the bearer token 206, which a device that successfully decodes the challenge token 204 to identify the appropriate manager information can provide to its manager to obtain configuration information. This bearer token 206 can include a signed but decoded challenge token, which in this example can include information about the manager and device, as well as a nonce and a TTL value. The device and manager information allows the manager to determine that this request is from a specific device intended for this specific manager, while the TTL value allows the manager to determine that the bearer token is still valid, and the nonce allows the manager to determine that no reuse of the bearer token has been attempted. This bearer token can then be signed with the device's self-generated private key (SRK_PRIV), so that the manager can verify that it was sent from the correct device by decrypting it using the corresponding public key. Because a manager should only be able to decrypt data that pertains to the device in its current state or with its current ownership, and not data in other states or ownerships that may be associated with other managers, in at least some embodiments it may be important for the device to sign with a self-generated key instead of a persistent key.

3 illustrates an example process 300 for zero-touch registration of a device that may be performed by at least one embodiment. It should be understood that for this and other processes presented herein, there may be additional, fewer, or alternative steps within various embodiments, in similar or alternative orders, or at least partially in parallel, unless otherwise stated. In this example, a device undergoes an initial boot (302) as a new device or after a wipe of the device from which new configuration and manager information will be obtained. The device may generate a manager information request and send the request (304) to a central directory service (CDS) or other such entity, which may include device identification information in a request token as described with respect to FIG. 2. The CDS that receives the request may validate the device information and identify the appropriate manager for the device. A challenge token may then be received (306) from the CDS to the device, which includes information about the manager with multiple secure wrappings. The device may decode (308) the challenge token to obtain a base token (or decoded challenge token) that contains the manager information, and potentially other information as described herein, and perform any appropriate validation. The device may then generate (610) a bearer token that is digitally signed by the device and contains the decoded token, effectively converting the challenge token into a bearer token. It may then send (312) a configuration information request, including the bearer token, to the identified manager using the manager information found in the decoded token. The manager may validate the information and send the appropriate configuration (and other related) information to the device. The device may receive (314) this configuration information from the manager, and may use this received configuration information to configure the device (316). After the device is up and configured, it may operate for its intended purpose (318).

FIG. 4 illustrates 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 may receive a request from a device that includes a device identifier (ID) encrypted or signed using the device's self-generated key (402). The CDS may compare the device identifier and the information contained in the device identifier against a database of known valid devices to validate the device (404). In at least one embodiment, this comparison may include not only locating the device's serial number in the database, but also ensuring that the key information provided corresponds to that serial number in the database of devices. If the device cannot be validated, the CDS may ignore the request or send back some type of error message, among other options. If the device information can be validated, a manager 406 or other relevant system or service for the device may be identified (406), such as by referencing a set of mappings of known devices. The CDS can generate a token containing information useful for identifying the appropriate manager for this device (408), which may include a device identifier, manager information, a token expiration date, 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 a device with the appropriate security information should be able to decrypt and use the information in the challenge token.

5 illustrates an exemplary process 500 that may be performed by a device receiving a cryptographic validation challenge token, such as the challenge token generated in the process of FIG. 4, which may be part of the registration process described with respect to FIG. 3. As with 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 a pre-request for information (502). The device may determine the integrity of the challenge token by first verifying the CDS signature on the challenge token (504). The device may then decrypt the challenge token (506) using the device's self-generated key and persistent key. As previously discussed, the use of both keys may ensure that the device only accesses information authorized for the device's owner or current state of usage, ensuring that the device is the device it claims to be. A device that successfully decrypts the challenge token may then verify the internal signature of the challenge token using the CDS public key (508). Once decrypted and verified, the device may determine the manager information contained in the token (510). The manager information may include, for example, an identifier and address information such as a Uniform Resource Locator (URL). The device may then combine the signed but decrypted challenge token with a nonce from within the token to create a bearer token (512), and then sign the bearer token with a self-generated device key (514). The self-generated key is used instead of a persistent device key because the manager should only have access to information about the device while the manager is associated with the device, and not at other times. The device may then send the bearer token to the identified manager along with a configuration information request or other such communication (516). In this process, the manager does not communicate directly with the CDS, since the device communicates with the CDS in one round trip communication, 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 itself via the challenge token.

FIG. 6 illustrates an exemplary process 600 that may be performed by a device manager receiving a bearer token, such as the bearer token generated in the process of FIG. 5, along with a configuration information request, which 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 may verify that the inside of the bearer token is correctly signed by the CDS (604). In at least one embodiment, security requirements may dictate that the manager must be able to verify that the device was referred to the manager by the CDS without needing to contact the CDS. The manager may also verify that the manager information included in the bearer token is correct and that the token has not expired (606). The manager may also verify that the outside or wrapper is signed with the same self-generated device key that is embedded inside (608). The manager may also verify that the nonce in the CDS-signed bearer token matches the nonce that is outside the CDS-signed token but included in the bearer token (610). As mentioned above, at least some of these steps can be performed in a different order or at least partially in parallel. Once this information is verified, the correct configuration information can be identified and sent to the device (612), allowing the device to utilize the configuration to complete its startup procedures to enable the device to perform its intended tasks. In at least some embodiments, the manager can provide or be associated with a console or interface that allows users or entities associated with this device, and possibly other devices, to manage those devices. In at least one embodiment, entities can log into those consoles to see a list of devices that have been automatically registered and/or provisioned through such a process. The devices can also make calls using one or more application programming interfaces (APIs) exposed by the manager system, and may utilize self-generated keys through these API calls.

7 illustrates an exemplary data center 700 in which at least one embodiment may be used. For example, in at least one embodiment, a CDS or a 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.

7, in at least one embodiment, a data center infrastructure layer 710 may include a resource orchestrator 712, grouped computing resources 714, and node computing resources (“node C.R.”) 716(1)-716(N), where “N” represents any positive integer. In at least one embodiment, a node C.R. 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. In at least one embodiment, one or more of the nodes C.R. 716(1)-716(N) may be a server having one or more of the computing resources described above.

In at least one embodiment, the grouped computing resources 714 may include separate groups of nodes C.R. housed in one or more racks (not shown), or multiple racks housed in a data center in various graphical locations (also not shown). The separate groups of nodes C.R. in 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, several nodes C.R. including CPUs or processors may be grouped in one or more racks to provide compute resources to support one or more workloads. In at least one embodiment, the one or more racks may also include any number of power modules, cooling modules, and network switches in any combination.

In at least one embodiment, the resource orchestrator 712 may configure or otherwise control one or more nodes C.R. 716(1)-716(N) and/or 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.

As shown in FIG. 7, in at least one embodiment, 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, framework layer 720 may include a framework for supporting software 732 in software layer 730 and/or one or more applications 742 in application layer 740. In at least one embodiment, software 732 or applications 742 may each include web-based service software or applications, such as those offered by Amazon Web Services, Google Cloud, and Microsoft Azure. In at least one embodiment, framework layer 720 may be, but is not limited to, a type of free and open source software web application framework, such as Apache Spark® (hereinafter “Spark”), which can use distributed file system 728 for large-scale data processing (e.g., “big data”). In at least one embodiment, the job scheduler 722 may include a Spark driver to facilitate scheduling of workloads supported by various tiers of the data center 700. In at least one embodiment, the configuration manager 724 may be capable of configuring different tiers, such as the software tier 730, and the framework tier 720 including Spark and a distributed file system 728 to support large scale data processing. In at least one embodiment, the resource manager 726 may be capable of managing clustered or grouped computing resources that are 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 tier 710. In at least one embodiment, the resource manager 726 may work in conjunction with the resource orchestrator 712 to manage these mapped or allocated computing resources.

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 nodes 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 searching software, e-mail virus scanning software, database software, and streaming video content software.

In at least one embodiment, the applications 742 included in the application layer 740 may include one or more types of applications used by at least a portion of the nodes 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, cognitive compute, 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.

In at least one embodiment, any of configuration manager 724, resource manager 726, and resource orchestrator 712 may implement any number and type of self-correcting actions based on any amount and type of data obtained in any technically feasible manner. In at least one embodiment, the self-correcting actions may enable data center operators of data center 700 to avoid determining potentially bad configurations and eliminate underutilized and/or underperforming portions of the data center.

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

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

These components can be used for zero-touch registration of devices via a secure token-based approach with the associated manager system.

8 is a block diagram illustrating an exemplary computer system, which may be a system having interconnected devices and components formed with a processor that may include execution units for executing instructions, a system on a chip (SoC), or some combination of these 800, according to at least one embodiment. In at least one embodiment, computer system 800 may include components such as, without limitation, a processor 802 for using execution units that include logic to execute 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 the PENTIUM® processor family, Xeon™, Itanium®, XScale™, and/or StrongARM™, Intel® Core™, or Intel® Nervana™ microprocessors available from Intel Corporation of Santa Clara, Calif., although other systems may be used (including PCs with other microprocessors, engineering workstations, set-top boxes, etc.). In at least one embodiment, computer system 800 may run a version of the WINDOWS® operating system available from Microsoft Corporation of Redmond, Wash., although other operating systems (e.g., UNIX and Linux), embedded software, and/or graphical user interfaces may be used.

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, embedded applications may include microcontrollers, digital signal processors ("DSPs"), systems-on-chips, 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.

In at least one embodiment, computer system 800 may include, without limitation, a processor 802, which may include one or more execution units 808 for performing training and/or inference of machine learning models according to the techniques described herein. In at least one embodiment, computer system 800 is a single processor desktop or server system, while in another embodiment, computer system 800 may be a multiprocessor 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. 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 within the computer system 800.

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

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

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, without limitation, memory 820. 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.

In at least one embodiment, a system logic chip may be coupled to the processor bus 810 and 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 route 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 memory 820 via a 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.

In at least one embodiment, computer system 800 may use system I/O 822, a proprietary hub interface bus for coupling MCH 816 to I/O controller hub ("ICH") 830. In at least one embodiment, ICH 830 may provide direct connectivity to some 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 peripherals to memory 820, chipset, and processor 802. Examples may include, without limitation, an audio controller 829, a firmware hub ("Flash BIOS") 828, a wireless transceiver 826, data storage 824, a legacy 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 comprise a hard disk drive, a floppy disk drive, a CD-ROM device, a flash memory device, or other mass storage device.

In at least one embodiment, FIG. 8 illustrates a system including interconnected hardware devices or "chips," while in other embodiments, FIG. 8 may illustrate an exemplary system-on-a-chip ("SoC"). In at least one embodiment, the devices may be interconnected with 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.

These components can be used for zero-touch registration of devices via a secure token-based approach with the associated manager system.

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

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, the processor 910 may be configured to communicate with 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, and 3), or a Universal Asynchronous Receiver/Transmitter (“UART”) bus. 9 are coupled using a bus or interface, such as a PCI Express (Asynchronous Receiver/Transmitter) bus. In at least one embodiment, FIG. 9 illustrates a system including interconnected hardware devices or "chips," while in other embodiments, FIG. 9 may illustrate an exemplary system-on-a-chip ("SoC"). In at least one embodiment, the devices illustrated in FIG. 9 may be interconnected with a proprietary interconnect, a standard interconnect (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.

In at least one embodiment, FIG. 9 illustrates 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 Solid State Disk ("SSD") or a Hard Disk Drive ("HDD") 970, and/or a USB 2.0 port 980. 9, a drive 920, such as a USB 3.0 Disk Drive, 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 ("USB 3.0 camera") 954, such as a USB 3.0 camera, and/or a low power double data rate ("LPDDR") technology implemented, for example, in the LPDDR3 standard. A low-rate memory unit ("LPDDR3") 915 may also be included. Each of these components may be implemented in any suitable manner.

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") 942, 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, a headphone 964, and a microphone ("mic") 965 may be communicatively coupled to an audio unit (audio codec and class d amplifier) 962, which may be communicatively coupled to the DSP 960. In at least one embodiment, the audio unit 964 may include, for example, 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").

These components can be used for zero-touch registration of devices via a secure token-based approach with the associated manager system.

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

In at least one embodiment, the system 1000 may include or be incorporated into a server-based gaming platform, a game console including a game and media console, a mobile gaming console, a handheld game console, or an online game console. In at least one embodiment, the system 1000 is a mobile phone, a smart phone, a tablet computing device, or a mobile Internet device. In at least one embodiment, the 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 eyewear device, an augmented reality device, or a virtual reality device. In at least one embodiment, the 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.

In at least one embodiment, the one or more processors 1002 each include 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 the one or more processor cores 1007 is configured to process a particular instruction set 1009. In at least one embodiment, the instruction set 1009 may facilitate complex instruction set computing (CISC), reduced instruction set computing (RISC), or computing via very long instruction words (VLIW). In at least one embodiment, the processor cores 1007 each may process a different instruction set 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 digital signal processors (DSPs).

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 among 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 may be shared among the processor cores 1007 using known cache coherence techniques. In at least one embodiment, the processor 1002 further includes a register file 1006, which may include different types of registers (e.g., integer registers, floating point registers, status registers, and an instruction pointer register) for storing different types of data. In at least one embodiment, the register file 1006 may include general purpose registers or other registers.

In at least one embodiment, the 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 processors 1002 and other components in the system 1000. In at least one embodiment, the interface bus 1010 may 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 a DMI bus, but 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 connectivity to I/O devices via a local I/O bus.

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 any other memory device with suitable performance to serve as process memory. In at least one embodiment, the memory device 1020 may operate as a system memory for the system 1000 to store data 1022 and instructions 1021 for use when the one or more processors 1002 execute applications or processes. 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 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 of an internal display device, such as a mobile electronic device or 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 may include a head mounted display (HMD), such as a stereoscopic display device for use in virtual reality (VR) or augmented reality (AR) applications.

In at least one embodiment, the platform controller hub 1030 allows peripherals to connect 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, and a data storage device 1024 (e.g., 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, wireless transceiver 1026 may 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, firmware interface 1028 enables communication with system firmware and may be, for example, a Unified Extensible Firmware Interface (UEFI). In at least one embodiment, network controller 1034 may enable network connectivity to a wired network. In at least one embodiment, a high performance network controller (not shown) couples to interface bus 1010. In at least one embodiment, audio controller 1046 is a multi-channel high definition audio controller. In at least one embodiment, 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, platform controller hub 1030 can also connect to one or more universal serial bus (USB) controllers 1042 connected input devices, such as a keyboard and mouse 1043 combination, a camera 1044, or other USB input devices.

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

These components can be used for zero-touch registration of devices via a secure token-based approach with the associated manager system.

Figure 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 may include a smaller number of additional cores, including additional core 1102N, represented by a 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 also has access to one or more shared cache units 1106.

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 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 of cache before external memory is classified as an LLC. In at least one embodiment, cache coherence logic maintains coherency between the various cache units 1106 and 1104A-1104N.

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

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 the 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 coordinating the power state of one or more of the processor cores 1102A-1102N and the graphics processor 1108.

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 couples to a shared cache unit 1106 and to 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 directing the output of the graphics processor to one or more coupled 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.

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

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 use embedded memory module 1118 as a shared last-level cache.

In at least one embodiment, the processor cores 1102A-1102N are homogenous 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), where one or more of the processor cores 1102A-1102N execute a common instruction set, while one or more other of the processor cores 1102A-1102N execute a subset of the common instruction set, or a different instruction set. In at least one embodiment, the processor cores 1102A-1102N are heterogeneous in terms of micro-architecture, where one or more cores with relatively higher power consumption are combined 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.

These components can be used for zero-touch registration of devices via a secure token-based approach with the associated manager system.

Other variations are within the scope of the present disclosure. Thus, the disclosed techniques are susceptible to various modifications and alternative constructions, certain illustrative examples of which are shown in the drawings and have been described in detail above. However, there is no intention to limit the disclosure to the particular disclosed form or forms, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the disclosure as defined by the appended claims.

The use of the terms "a," "an," and "the," and similar referents in the context of describing the disclosed embodiments (particularly in the context of the claims below) should be construed to encompass both the singular and the plural, and should not be construed as defining the terms, unless otherwise stated herein or clearly contradicted by context. The terms "comprising," "having," "including," and "containing" are to be construed as open-ended terms (meaning "including, but not limited to"), unless otherwise stated. The term "connected," when referring to a physical connection without modification, is to be construed as being partially or completely contained within, attached to, or joined to one another, even if there is something intervening. The recitation of ranges of values herein is merely intended to serve as a shorthand method of individually referring to each separate value falling within the range, unless otherwise stated herein and unless each separate value is incorporated into the specification as if it were individually recited herein. Use of the term "set" (e.g., "set of items") or "subset" should be construed as a non-empty collection with one or more members, unless otherwise stated or denied by context. Furthermore, unless otherwise stated or denied by context, the term "subset" of a corresponding set does not necessarily refer to a strict subset of the corresponding set, and a subset and a corresponding set may be equivalent.

Conjunctions such as phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C" are understood in the context in which they are generally used to indicate that an item, term, etc. is A, B, or C, or a non-empty subset of any of the sets A, B, and C, unless specifically stated otherwise or clearly contradicted by the context. For example, in the 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 conjunctives do not generally imply that a given embodiment requires the presence of at least one A, at least one B, and at least one C, respectively. Further, unless otherwise stated or negated by context, the term "plurality" refers to a plurality (e.g., "a plurality of items" refers to multiple items). A plurality is at least two items, but may be more if indicated explicitly or by context. Further, unless otherwise stated or negated by context, the phrase "based on" means "based at least in part on" and not "based only on."

The operations of the processes described herein may be performed in any suitable order unless otherwise stated herein or clearly contradicted by context. In at least one embodiment, a process such as the processes described herein (or variations and/or combinations thereof) is implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed under the control of one or more computer systems configured with executable instructions and collectively executed by hardware on one or more processors, or by a combination thereof. In at least one embodiment, the code is stored on a computer-readable storage medium, e.g., in the form of a computer program comprising a plurality of instructions executable by one or more processors. In at least one embodiment, the computer-readable storage medium is a non-transitory computer-readable storage medium that excludes transitory signals (e.g., propagating transitory electrical or electromagnetic transmissions), but includes non-transitory data storage circuitry (e.g., buffers, caches, and queues) in a transceiver of a transitory signal. In at least one embodiment, code (e.g., executable code or source code) is stored in a set of one or more non-transitory computer readable storage media that store executable instructions (or have other memory for storing executable instructions) that, when executed by (i.e., as a result of being executed by) one or more processors of a computer system, cause the computer system to perform the operations described herein. The set of non-transitory computer readable storage media, in at least one embodiment, comprises a plurality of non-transitory computer readable storage media, where one or more of the individual non-transitory storage media of the plurality of non-transitory computer readable storage media do not contain all the code, but the plurality of non-transitory computer readable storage media collectively store all the code. In at least one embodiment, the executable instructions are executed such that different instructions are executed by different processors, e.g., the non-transitory computer readable storage media store the instructions, a main central processing unit ("CPU") executes some 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.

Thus, in at least one embodiment, a computer system is configured to implement one or more services that, singly or collectively, perform the operations of the processes described herein, and such computer system is configured with applicable hardware and/or software that enables the operations to be performed. Furthermore, 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 with multiple devices that operate in different ways, such that the distributed computer system performs the operations described herein such that no single device performs all the operations.

Any examples provided herein, or the use of exemplary language (e.g., "such as"), are intended only to better illuminate embodiments of the disclosure and do not limit the scope of the disclosure unless otherwise asserted. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

All references cited in this specification, including publications, patent applications, and patents, are hereby incorporated by reference to the same extent as if each reference was individually and specifically indicated to be incorporated by reference and set forth in its entirety herein.

In the specification and claims, the terms "coupled" and "connected," along with their derivatives, may be used. 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. "Coupled" may also mean that two or more elements are not in direct contact with each other, but still interlock or interact with each other.

Unless specifically stated otherwise, terms such as "processing," "computing," "calculating," or "determining" throughout the specification refer to the acts and/or processes of a computer or computing system, or similar electronic computing device, that manipulate and/or transform data represented as physical quantities, such as electronic quantities, in the registers and/or memory of the computing system into other data similarly represented as physical quantities in the memory, registers, or other such information storage, transmission, or display device of the computing system.

Similarly, 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 comprise 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 multiple processes for serially or in parallel, continuously or intermittently executing instructions. The terms "system" and "method" are used interchangeably herein to the extent that a system may embody one or more methods and a method may be considered a system.

As used herein, reference may be made to obtaining, acquiring, receiving, or inputting analog or digital data into a subsystem, computer system, or computer-implemented machine. Obtaining, acquiring, receiving, or inputting analog or digital data may 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 or digital data may be realized by transferring data over a serial or parallel interface. In another implementation, the process of obtaining, acquiring, receiving, or inputting analog or digital data may be realized by transferring data over a computer network from a providing entity to an acquiring entity. 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 realized by transferring data as an input or output parameter of a function call, a parameter of an application programming interface, or an inter-process communication mechanism.

Although the above discussion describes an example implementation of the described techniques, other architectures may be used to implement the described functionality, and are intended to be within the scope of this disclosure. Additionally, while a specific distribution of roles is defined above for purposes of discussion, the various functions and roles may be distributed and divided in different ways depending on the circumstances.

Additionally, 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 example forms of implementing the claims.

Claims (13)

receiving, at the device in response to the first request, a challenge token having one or more layers of encryption;
accessing, by the device , information obtained by decrypting the challenge token, the information including at least the destination ;
converting, by the device, the decrypted challenge token into a bearer token protected using a secure key of the device;
sending , by the device, a second request including the bearer token to the destination specified in the challenge token, the bearer token enabling a recipient of the request to authenticate the device and provide the device with configuration information that enables the device to operate for its intended purpose ;
The method, wherein the challenge token is received from a trusted authority that stores contact information for a plurality of devices, the contact information specifying addresses and identification information of one or more recipients including one or more manager systems associated with a subset of the plurality of devices . 2. The method of claim 1, wherein the trusted authority is capable of authenticating the device using a device identifier included in the first request, the device identifier being mapped to one of the manager systems corresponding to the destination . The method of 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. The method of claim 1, wherein the one or more layers of encryption of the challenge token include at least one of a digital signature of a trusted authority 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. The method of claim 1, wherein the bearer token includes the decrypted challenge token with an attached nonce that was included in the decrypted challenge token, and the bearer token is signed with a self-generated secure key for the device. 2. The method of claim 1, further comprising: the recipient being a manager system associated with the device; and the manager system identifying the configuration information by the bearer token and providing the configuration information to the device so that the device operates for the intended purpose. The method of claim 6 , wherein the manager system is capable of verifying authentication of the device by the trusted authority that generated the challenge token without directly communicating with the trusted authority. 8. The method of claim 7, wherein the device is authenticated to the manager system and can receive the configuration information using only a single request to the manager system and receiving only a single response from the manager system. The method of claim 1 , further comprising the step of the device sending the first request upon initial start-up of the device if the configuration information is not stored on the device. A device, comprising:
A processor;
When executed by the processor, the device
receiving a challenge token having one or more layers of encryption in response to the registration request;
decrypting the challenge token to access information about the manager system;
converting the decrypted challenge token into a bearer token protected using a secure key of the device; and
and a memory including instructions for causing the device to transmit a second request to the manager system for configuration information that enables the device to operate for an intended purpose , the second request including the bearer token for enabling the manager system to authenticate the device and provide the configuration information ;
A device, wherein the challenge token is received from a trusted authority that stores contact information for a plurality of devices, the contact information specifying addresses and identification information of one or more manager systems associated with a subset of the plurality of devices . 11. The device of claim 10, wherein the one or more layers of encryption of the challenge token include at least one of a digital signature of the trusted authority generating the challenge token, encryption using a self-generated secure key for the device, or encryption using a persistent secure key for the device. 11. The device of claim 10, wherein information in the bearer token enables the manager system to identify and provide the configuration information to the device to enable the device to operate for its intended purpose. The device of claim 10 , wherein the manager system is capable of verifying authentication of the device by the trusted authority that generated the challenge token without directly communicating with the trusted authority.