Patent Publication Number: US-11664994-B2

Title: Secure unlock systems for locked devices

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a divisional (and claims the benefit of and priority under 35 U.S.C. § 120 and § 121) of U.S. application Ser. No. 15/640,439, filed Jun. 30, 2017 and entitled SECURE UNLOCK SYSTEMS FOR LOCKED DEVICES. The disclosure of the prior application is considered part of and is incorporated by reference in the disclosure of this Application. 
    
    
     TECHNICAL FIELD 
     This disclosure relates in general to the field of computer system architecture features and, more particularly, to secure unlock systems for locked devices. 
     BACKGROUND 
     Protection of intellectual property and other proprietary information embodied in system on chips (SoCs) and other devices is required by the device manufacturers and original equipment manufacturers (OEMs) who make systems that incorporate those devices. Devices, such as an SoC, are typically locked during the manufacturing process to prevent unauthorized access to the device by third parties, such as an OEM, a sub-component vendor, or others who attempt to gain access to the intellectual property and other proprietary information embodied in the device. Certain third parties, however, may need at least some access to privileged features of a device to implement the device into a final product or provide additional functionality to the device during the device lifecycle, for example. Privileged features may include, but are not necessarily limited to, debugging, provisioning, testing, validation, prototyping, and/or analyzing features that enable access to certain proprietary code or information in the device. Effective techniques are needed to allow authorized users to unlock devices and access privileged features on the devices, while simultaneously protecting against devices being unlocked by unauthorized users. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       To provide a more complete understanding of the present disclosure and features and advantages thereof, reference is made to the following description, taken in conjunction with the accompanying figures, where like reference numerals represent like parts, in which: 
         FIG.  1    is a simplified block diagram illustrating a first secure unlock system based on encrypted passwords according to at least one embodiment of the present disclosure; 
         FIG.  2    is a simplified interaction diagram of a first secure unlock system according to at least one embodiment of the present disclosure; 
         FIG.  3    is a simplified flow chart illustrating example operations that may be associated with at least one embodiment of the present disclosure; 
         FIG.  4    is a simplified flow chart illustrating further example operations that may be associated with at least one embodiment of the present disclosure; 
         FIG.  5    is a simplified flow chart illustrating yet further example operations that may be associated with at least one embodiment of the present disclosure; 
         FIG.  6    is a simplified block diagram illustrating a second secure unlock system based on signed tokens according to at least one embodiment of the present disclosure; 
         FIG.  7    is a simplified block diagram illustrating example parameters for creating a token device identifier according to at least one embodiment of the present disclosure; 
         FIG.  8    is a simplified block diagram illustrating an example structure of a token according to at least one embodiment of the present disclosure; 
         FIG.  9    is a simplified interaction diagram illustrating example interactions that may be associated with at least one embodiment of the present disclosure; 
         FIGS.  10 A- 10 B  provide a simplified interaction diagram illustrating example interactions that may be associated with at least one embodiment of the present disclosure; 
         FIG.  11    is a simplified flowchart illustrating example operations that may be associated with at least one embodiment of the present disclosure; 
         FIG.  12    is a simplified flow chart illustrating further example operations that may be associated with at least one embodiment of the present disclosure; 
         FIG.  13    is a block diagram of a register architecture according to one embodiment of the invention; 
         FIG.  14 A  is a block diagram illustrating both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue/execution pipeline according to embodiments of the present disclosure. 
         FIG.  14 B  is a block diagram illustrating both an exemplary embodiment of an in-order architecture core and an exemplary register renaming, out-of-order issue/execution architecture core to be included in a processor according to embodiments of the present disclosure; 
         FIGS.  15 A- 15 B  illustrate a block diagram of a more specific exemplary in-order core architecture, which core would be one of several logic blocks (including other cores of the same type and/or different types) in a chip; 
         FIG.  16    is a block diagram of a processor that may have more than one core, may have an integrated memory controller, and may have integrated graphics according to embodiments of the present disclosure; 
         FIGS.  17 - 20    are block diagrams of exemplary computer architectures; and 
         FIG.  21    is a block diagram contrasting the use of a software instruction converter to convert binary instructions in a source instruction set to binary instructions in a target instruction set according to embodiments of the present disclosure. 
     
    
    
     DETAILED DESCRIPTION OF EMBODIMENTS 
     The following disclosure provides various possible embodiments, or examples, for implementing a secure unlock system for locked devices. A device can be a system that includes multiple components. Examples of devices in which teachings of the present disclosure may apply include, but are not necessarily limited to, central processing units (CPUs), system on chips (SoCs), devices products, microprocessors, chips and microchips (e.g., Platform Controller Hub (PCH)), integrated circuits (ICs), graphical processing units (GPUs), and processing systems. A device may be locked to prevent unauthorized access to proprietary information and computing blocks on the device via privileged features. Privileged features can include, but are not limited to debugging, validating, provisioning, testing, prototyping, and analyzing performance features for accessing proprietary computing blocks (or “intellectual property (IP) blocks” or “blocks”) and/or proprietary information on the device. Privileged features can also include particular output messages that provide proprietary information or data, and that are disabled during normal use of the device. Other privileged features can include code associated with security or authentication that can be disabled to allow unrestricted or less-restricted access to certain proprietary computing blocks and information. 
     For purposes of illustrating the several embodiments of a secure unlock system for locked devices, it is important to first understand the lifecycle and configuration of locked devices and the privileged features available on those devices. Accordingly, the following foundational information may be viewed as a basis from which the present disclosure may be properly explained. 
     A device, such as a system on a chip (SOC) and other processing systems, generally moves through various stages of a device lifecycle that may include fabrication, provisioning, testing, debugging, validation, etc. before transitioning to a final product. Even after entering the marketplace, devices can be tested and debugged, such as when devices are returned for debugging to their manufacturer or the customer that implemented the device in a final product. As a device moves through these stages, various assets are added to the device, either by the device manufacturer, a sub-component vendor, or the customer (e.g., the OEM for whom the device is made and who implements the device in their own products, etc.). Assets can include any type of proprietary information or data such as secrets, keys (e.g., enhanced privacy identification key, content protection keys, encryption keys), certificates, and other data to which access is generally restricted. Assets can further include other sensitive digital assets including executable code provisioned on a component or computing block within the device, among other examples. 
     A variety of entities can be involved in the development and lifecycle of a device. Assets, including sensitive data and intellectual property, of the respective entities can be provisioned on the device as it progresses through its lifecycle. For instance, assets can be provisioned as computing blocks added to the device, as secret and proprietary logic and code added to the computing blocks, among other examples. The owners or providers of these assets may desire, or require, that these assets remain private and/or protected from access by unauthorized users. However, certain types of accesses may risk exposing the assets to the user(s) performing the task, as the user inspects various components, data, registers, memory, and operations of the device and various computing blocks present and interoperating on the device. 
     Accordingly, it can be desirable in some instances to limit access to particular assets and components during certain types of use sessions (e.g., debugging, testing, validating, etc.) performed on the device. For instance, security logic can be provided to define and enforce modes at particular blocks of the device, such that assets associated with the particular blocks are protected from access by particular users during particular use sessions such as debugging or testing, for example. The level of access can be based on the identity of the session user, as some users may be authorized to access assets of the device while other users may not be authorized to access the assets. Indeed, in some cases unauthorized access to some assets (e.g., encryption keys, secrets, CPU firmware, power management algorithms, control over execution flow of some logic blocks, etc.) can compromise or threaten the value of the assets. Further, the level of debug access (and other types of access) can also vary based on the lifecycle stage of the device. For instance, the level of desired debug access (by each respective entity) to the device can vary as the lifecycle progresses and various assets are provisioned. For example, in the beginning, the device may comprise a bare system chassis with no secret or proprietary data or components and unfettered debug access can be provided at least to the verified users associated with the manufacturer of the device chassis. However, once secrets such as content keys are provisioned, access to these assets may be disallowed, even to the engineers manufacturing or debugging the device or its sub-components and other users who once previously enjoyed access to these components during a previous lifecycle stage. 
     While it may be desirable to limit access to particular assets and components as the device progresses through the lifecycle, certain entities may have a legitimate need to use various privileged features for limited, extended, or indefinite time periods. For example, an OEM may receive a locked device (e.g., SoC), which was made by the manufacturer for the OEM to implement in its own product (e.g., a smartphone). The OEM is likely to need at least some privileged features to effectively test and/or debug the device, among other examples, as it is transitioned into the final product. Without the ability to use privileged features during debug, testing, or validation sessions, for example, the OEM may only receive messages permitted by a mode that applies the highest level of protection to the IP blocks on the device. Consequently, timely and efficient completion of the final product could be negatively impacted. 
     Although OEMs generally need the ability to use at least some privileged features of devices they are implementing in their own products, OEMs may also desire and indeed, often require, protection of the IP blocks in the device. In some scenarios, password or key lists may be provided to a third party to unlock a device to allow the use of one or more privileged features on the device. Storing keys or passwords on a device and providing a list of the keys/passwords to an OEM, however, does not adequately protect the IP blocks and other proprietary information. Sharing such lists can weaken control and protection of the keys or passwords on those lists, as this unsecured information is at risk of inadvertent or intentional distribution to unauthorized individuals or entities. 
     Furthermore, unprotected passwords or keys stored within the device may be vulnerable to attacks, and thus, could potentially enable unauthorized access to proprietary assets on the device by a malicious entity. The threat of unauthorized access to privileged features of a device could undercut any competitive advantage sought by an OEM that uses the device in its product. 
     Secure Fuse Passwords to Unlock a Device 
     Turning to  FIG.  1   , a secure unlock system  100  resolves many of the aforementioned issues (and more). The simplified block diagram illustrates an example of secure unlock system  100 , which includes a database infrastructure  110 , a fusing station  120 , a device  150 , an unlock host  130 , and a network  105 . A user  140  interacts with unlock host  130  to be authenticated to unlock and use privileged features on device  150 . Device  150  comprises a policy generator  152 , one or more computing blocks such as IP block  160 , a fuse controller  170  including a fuse bank  175  of multiple fuses, an aggregator  180  including a security engine  185 , and a test access port (TAP) controller  155 . Fusing station  120  includes a security engine  125 , which can perform the same security function as security engine  185  of aggregator  180 . Database infrastructure  110  can include a key generator  112  for generating unique identifiers (“unique IDs”) and provisioning passwords for devices. Database infrastructure can also include a password/ID store  114  for storing unique IDs and passwords for unlocking devices, such as device  150 . Unlock host  130  can include access logic  132  and an access adapter  134  for accessing device  150 . Access logic  122  can also facilitate communication with database infrastructure  110  via network  105 . Elements of  FIG.  1    also contain appropriate hardware such as memory elements (e.g.,  117 ,  127 ,  137 ,  157 ) and processors (e.g.,  119 ,  129 ,  139 ,  159 ), which may be realized in numerous different embodiments, at least a few of which will be further described herein. 
     In secure unlock system  100 , a per part secret is secured using a security function such as a cryptographic hash function that maintains pre-image resistance or other suitable function providing protection such as an encryption algorithm or other cryptographic or obfuscation function. A password and unique identifier for device  150  is obtained from the manufacturer&#39;s database, a security function is applied to the password by security engine  125  of fusing station  120  to obtain a secured value (e.g., hashed value, obfuscated value, encrypted value, etc.), and the secured value and unique identifier are stored in fuses of fuse bank  175  by fusing station  120 . Unlock host  130  can be used to unlock the device by querying the device for its unique identifier in fuse bank  175 , establishing a communication session via network  105  to database infrastructure  110 , querying the database for the password associated with the unique identifier of the device, and providing the received password to the device for verification. Device  150  uses security engine  185  to apply the same security function (e.g., cryptographic hash function, encryption algorithm, obfuscation function, etc.) to the password received from unlock host  130 . If the secured value derived from applying the security function to the received password corresponds to the secured value stored in the device fuse bank  175 , then one or more privileged features can be unlocked based on the particular policies associated with the unique identifier and/or password. Otherwise, the privileged features remain locked, thus preventing access to the proprietary data and components in the device. 
     This solution provides several significant advantages. Because the secured value of the password is stored in the fuse bank of the device, there is no dependency on the confidentiality of the fuses to maintain a locked state of the device. The property of the security function removes the need for fuse-based secrets because it is nearly impossible to find the pre-image even if the digest and all of the details of the security algorithm are known. Therefore, even if an attacker could obtain the contents of the fuses, including the secured value of the password, the attacker would be unable to use them to unlock the device&#39;s privileged features, and therefore would be unable to access the proprietary data and components that could otherwise be accessed by the privileged features. Additionally, although secure unlock system  100  is shown with a single device, it should be appreciated that the system is scalable and capable of application to any number of devices and different types of devices. Furthermore, implementation of secure unlock system  100  would have limited impact on regular manufacturing lifecycles and no impact on the actual components of the devices. 
     With reference to  FIG.  1   , a brief description is now provided about some of the possible infrastructure that may be included in secure unlock system  100 . Secure unlock system  100  may span multiple, possibly discrete, network environments. Generally, secure unlock system  100  can include any type or topology of networks, indicated by network  105 . Network  105  represents a series of points or nodes of interconnected communication paths for receiving and sending network communications that propagate through secure unlock system  100 . Network  105  offers a communicative interface between nodes, and may be configured as any local area network (LAN), virtual local area network (VLAN), wide area network (WAN) such as the Internet, wireless local area network (WLAN), metropolitan area network (MAN), Intranet, Extranet, virtual private network (VPN), any other appropriate architecture or system that facilitates communications in a network environment, or any suitable combination thereof. Network  105  can use any suitable technologies for communication including wireless (e.g., 3G/4G/5G/nG network, WiFi, Institute of Electrical and Electronics Engineers (IEEE) Std 802.11™-2012, published Mar. 29, 2012, WiMax, IEEE Std 802.16™-2012, published Aug. 17, 2012, Radio-frequency Identification (RFID), Near Field Communication (NFC), Bluetooth™, etc.) and/or wired (e.g., Ethernet, etc.) communication. Generally, any suitable means of communication may be used such as electric, sound, light, infrared, and/or radio (e.g., WiFi, Bluetooth or NFC). 
     Database infrastructure  110  can be provisioned in any suitable network environment capable of network access (e.g., via network  105 ) to fusing station  120  and unlock host  130 . For example, database infrastructure  110  could be provisioned in a manufacturer&#39;s network with access to a wide area network (e.g., Internet) to communicate with test houses (e.g., unlock host  130 ) of customers, such as OEMs that receive the manufacturer&#39;s devices (e.g., device  150 ) to be incorporated in their products. In another example, database infrastructure  110  could include a distributed database across multiple physical locations. The database infrastructure could potentially reside in a cloud network and be accessed via any suitable network or networks (e.g., Internet, VPN, etc.) by fusing station  120  and unlock host  130 . The cloud network could be a private, public, or hybrid cloud computing infrastructure platform. Fusing station  120  may be provisioned in a network associated with a manufacturer of device  150 , and unlock host  130  may be provisioned in a network associated with an entity that receives the manufactured device, such as a testing house of an OEM that incorporates the device in the production of its own product. 
     During the manufacturing process, device  150  can be connected to fusing station  120  to enable storage of data in the fuse bank  175  of the device. Once fabrication of the device is complete, device  150  can be physically provided to a customer, such as an OEM, and communicatively coupled to an unlock host (e.g.,  130 ). In some scenarios, during manufacturing, device  150  may be provided to, or otherwise accessed by, sub-component vendors or other providers of computing blocks, data, software, and/or firmware to be included on the device. One way of accessing device  150  is the Joint Test Action Group (JTAG) standard, which is formally referred to as the Institute of Electrical and Electronics Engineers 1149.1-2001 Standard Test Access Port and Boundary-Scan Architecture, Jul. 23, 2001. Access adapter  134  of unlock host  130  can be a JTAG adapter, and can be connected to device  150  via any suitable interface including, but are not limited to, Ethernet, peripheral component interconnect (PCI), and universal serial bus (USB). 
     The JTAG standard defines a generic external test access port (TAP), which is represented by test access port (TAP) controller  155  in device  150 . This TAP controller can provide an interface to aggregator  180  when unlock host  130  communicates with device  150 , for example, when a user attempts to unlock the device using unlock host  130 . JTAG can be used in secure unlock system  100  to obtain unique identifiers from the aggregator  180  and to provide data, such as a password, to the aggregator. Although JTAG is one example industry standard that could be used to exchange information (e.g., passwords and unique identifiers) between devices and an unlock host, other standards could be implemented as well. 
     Although  FIG.  1    shows database infrastructure  110  in communication with a single fusing station  120  and a single unlock host  130 , it should be appreciated that any number of fusing stations in one or more manufacturing facilities may be in communication with the database infrastructure as different devices progress through the manufacturing process. Similarly, any number of unlock hosts in one or multiple test houses may be in communication with database infrastructure  110  to unlock devices as needed during production and/or post-production (e.g., repairs, recalls, etc.). Also, a single device (e.g.,  150 ) is shown to be communicatively coupled to fusing station  120  in  FIG.  1   . It should be noted that fusing station  120  could provision numerous devices with secured values during the manufacturing flow to enable unlocking the devices. Furthermore, although a single device (e.g.,  150 ) is shown coupled to unlock host  130 , it should be appreciated that unlock host  130  could be communicatively coupled to any number of other devices as they are debugged, tested, validated, prototyped, provisioned, analyzed, etc. 
     Database infrastructure  110  can be embodied in one or more network elements and storage elements. As used in this specification, ‘network elements’ are meant to encompass routers, switches, gateways, bridges, load balancers, firewalls, inline service nodes, proxies, servers, processors, processing systems, modules, or any other suitable device, component, element, proprietary appliance, or object operable to exchange information in a network environment. This network element may include any suitable hardware, software, components, modules, interfaces, or objects that facilitate the operations thereof. This may be inclusive of appropriate algorithms and communication protocols that allow for the effective exchange of data or information. As used herein, ‘storage elements’ are meant to encompass any type of non-volatile memory capable of storing data and information, and should be construed as encompassing any database management system (DBMS), relational database management system (RDBMS), repository, register, queue, table, cache, or other storage structure, all of which can be referenced at any suitable timeframe. 
     In at least one embodiment, database infrastructure  110  generates, stores, and responds to queries for unique identifiers and passwords of devices. Database infrastructure  110  generates a respective unique identifier (“unique ID”) for each device being manufactured. The database infrastructure also generates one or more passwords for each device. The passwords can indicate a particular unlock mode in which a current use session is allowed to run. Different unlock modes specify different combinations of privileged features that can be unlocked to provide access to proprietary data and/or code in a device. For example, one password could be associated with a ‘green mode,’ in which a limited number of privileged features are unlocked. Another password could be associated with a ‘yellow mode,’ in which a greater number of privileged features are unlocked than the orange mode, but not all privileged features are unlocked. Another password could be associated with an ‘orange mode,’ in which unrestricted use of privileged features is enabled on the device. In at least one embodiment, devices are configured to permit the provisioning of a maximum of seven passwords to enable seven levels of access to the device based on various privileged features. It should be apparent, however, that devices could be configured to enable the provisioning of any number of passwords indicating various levels of access based on particular implementations and needs. 
     It should also be noted that a particular password or particular set of passwords assigned to a device may also be assigned to other devices of the same type. For example, a device having a certain specification and requirements may be ordered in bulk by a customer. Every device in the order may be provisioned with the same password or set of passwords in at least one example. In another example, a device associated with a particular project (internal or external) or manufacturing flow may be provisioned with the same password or set of passwords. 
     A password or set of passwords for a particular device can be stored in database infrastructure  110  and mapped to the unique ID of the device. Passwords and unique identifiers are stored in the database infrastructure for future consumption by fusing stations (e.g., fusing station  120 ) and unlock hosts (e.g., unlock host  130 ). In some scenarios, for example, when a device includes a set of passwords and a user attempts to access the device via an unlock host, database infrastructure may also maintain a mapping of user credentials to passwords for the device in order to differentiate which device passwords are to be provided to the unlock host for which users authenticated at the unlock host. 
     Fusing station  120  is part of the manufacturing flow for devices, such as device  150 . In at least one embodiment, fusing station  120  can be provisioned in a high-volume manufacturing (HVM) process. During the manufacturing process of device  150 , fusing station  120  is communicatively coupled to database infrastructure  110  to receive passwords and unique identifiers of the device. Fusing station  120  is also operably connected to the device during manufacturing to burn data into the device, for example, into fuses of fuse bank  175 . Security engine  125  of fusing station  120  may be configured to perform a security function on a password to produce a secured value that is not feasible to invert to the original password. This secured value, along with the un-altered unique identifier for the device, can be burned into the device (e.g., into fuses of fuse bank  175 ). If multiple passwords are associated with the unique identifier, then the security function can be applied to each password to generate multiple secured values, and each secured value can be burned into the device. 
     In one example, the security engine performs a cryptographic hash function on a password to produce a digest (i.e., a hash value resulting from applying a hash function to a string of data). The hash function is a mathematical algorithm that maps data of any size to a bit string of a fixed size, which is referred to herein as a “hash value.” The hash function is designed to be a one-way function in which it is not feasible to invert the hash value to the original data. Although several one-way hash functions are available, they often comprise complex logic with blocks having many gates. Chips with a high gate count have a higher likelihood of random defects that prevent the device from being unlocked. Thus, a hash function with a reduced gate count may be desirable in at least some embodiments. 
     Secure Hash Algorithms (SHA) is a family of cryptographic hash functions published by the National Institute of Standards and Technology (NIST) as a U.S. Federal Information Processing Standard (FIPS). SHA-2 and SHA-3 are examples of hash functions that may be used as security engine  125  in fusing station  120 . It should be appreciated, however, that the particular hash function employed by embodiments described herein may vary and alternative hash functions having greater or smaller blocks of logic than SHA-2 or SHA-3, including other hash functions within the SHA family, may be used according to particular implementations and needs. Encryptions, protection and obfuscation techniques can be used as well. 
     Possible embodiments of device  150  can include, but are not necessarily limited to, a processing system, a central processing unit (CPU), system on chip (SoC), devices product, microprocessor, chip and microchip (e.g., Platform Controller Hub (PCH)), integrated circuit (IC), and/or graphical processing units (GPU). One or more computing blocks (e.g., IP block  160 ) are provisioned in device  150 , one or more of which contain proprietary data and/or code. For ease of illustration, a single IP block is shown in  FIG.  1   . However, devices typically contain multiple computing blocks. These computing blocks can be interconnected through one or more links and interconnect architecture. For instance, a general purpose or specialized interconnect architecture can be used to facilitate communication and memory operations between the computing blocks. One or more interconnect protocols, such as Peripheral Component Interconnect (PCI), Peripheral Component Interconnect (PCI) Express (PCIe), Quick Path Interconnect (QPI), High Performance Interconnect (HPI) (e.g., a serial point-to-point differential protocol with embedded clock), and Advanced Microcontroller Bus Architecture (AMBA) AXI architectures, Quick Path Interconnect (QPI), Mobile Industry Processor Interface (MIPI) M-PHY (e.g., multimedia and chip-to-chip/interprocessor communications), etc. can be employed on the interconnect. In some examples, a device chassis is provided by a first entity and one or more of the computing blocks (e.g.,  160 ) are provided by one or more other entities (although the same entity can provide both the chassis and some or all of the component computing blocks in other examples). 
     In the example of  FIG.  1   , policy generator  152  is a computing block provided to manage debug and testing policies for all (or some set of) computing blocks of device  150 . Other policies including, but not limited to, validating, provisioning, prototyping, and/or analyzing, may also be managed by policy generator  152 . A set of blocks (e.g.,  160 ) can be configured to operate with policy generator  152  and can include policy enforcer logic  162  to enforce block-specific responses to various debug/testing/etc. policies. For instance, sideband links  153  can be used to facilitate communication between the respective policy enforcer logic  162  and the policy generator  152 . In some cases, sideband links can be dedicated sideband links and can ensure secure trusted communication between the policy enforcers, such as policy enforcer  162 , and the central policy generator  152 . 
     In some implementations, policy generator  152  can be configured with hardware, firmware, and/or software logic to authenticate and determine an unlock mode associated with the password used to unlock the device, the identity of a particular user seeking access to device  150 , and the lifecycle stage of the device. A user may be attempting any number of privileged activities on the device including, but not necessarily limited to debugging, testing, validating, provisioning, prototyping, and/or analyzing performance. Various policies can be defined based on the unlock mode of the password used to unlock the device, the user&#39;s identity, the lifecycle of the device, or any combination thereof. The level of debug access (and other privileged feature access) to be applied at each respective block (e.g.,  160  and any others not shown) can be based on the policy and can be block-specific. The respective policy enforcer logic (e.g.,  162 ) can dictate how the corresponding block&#39;s debug access (and other privileged feature access) is affected by the policy. In some implementations, the policy generator  152  is provided in connection with a defined device chassis framework, with each component, or block, configured for the framework. In some examples, compatibility with the framework can dictate the inclusion of policy enforcer logic (e.g.,  162 ) on each component within device  150 , such that debug access (and other privileged feature access) of every block on the device is managed with the assistance of a central policy generator (e.g.,  152 ) provided in accordance with the defined framework, among other example implementations. 
     In at least one embodiment, policy generator  152  can compute an access policy to be applied to device  150  based on an unlock mode associated with the password used to unlock the device, lifecycle information, and/or a particular user identity or user classification. Lifecycle information can be received by policy generator  152  and a lifecycle stage of the device can be determined. Further, user authentication information can be received by policy generator  152  from unlock host  130  via TAP controller  155  to map the user to a particular identity or user classification. In other embodiments, the user authentication information can be used by database infrastructure  110  to determine which password associated with the unique identifier is to be returned to unlock system  130  to attempt to unlock the device. The password used to unlock the device can be used by policy generator  152  to determine an unlock mode in which the current use session is allowed to run. In other embodiments, the unlock mode can be received by policy generator  152  from unlock host  130  or some other storage element. The policy generator  152  can compute access policies based on the unlock mode. For example, policy generator  152  can compute an access policy to be applied to device  150  based, at least in part, on the privileged features specified by the unlock mode to be enabled or disabled (e.g., enable debug access for a particular component, enable privileged output messages, disable security or authentication code, etc.). In other implementations, the device or some other storage element to which the device is coupled could contain a mapping of the unlock mode to specific privileged features to be unlocked on the device. 
     The computed access policy can then be broadcast (e.g., over secure sideband channels  153 ) to all IP block endpoints (e.g.,  160 ) to alert the respective policy enforcers (e.g.,  162 ) of the policy to be applied for a duration of activities (e.g., debugging, testing, validating, provisioning, prototyping, analyzing performance, etc.) during a use session by the particular user corresponding to the user authentication from unlock host  130 . Each policy enforcer (e.g.,  162 ) can decode the policy signal received from policy generator  152  to identify the policy and determine what activities and/or access to allow at the corresponding IP block (e.g.,  160 ) during the use session. In some cases, a policy enforcer can define a plurality of unlock modes for its corresponding IP block, such that various activities at the IP block are allowed or denied depending on the unlock mode applied at the IP block. Such activities can include, access to protected assets, access to scan modes within the IP block (e.g., that allow the user to shift out the data and gain access to the protected asset), among other examples. For instance, the policy enforcer can manage the unlock mode of the IP block to control access and activity at the block. The policy enforcer can cause the corresponding IP block to enter a particular one of its defined modes based on the policy that is broadcast for device  150  during a given use session for debugging, testing, validating, provisioning, prototyping, analyzing performance, etc. 
     Any given computing block (e.g., IP block  160 ) may support any number of features or capabilities that might be leveraged or used during a particular use session (e.g., for debugging, testing, etc.). For instance, such features (or “privileged features”) of the IP block (e.g.,  160 ) can include multiple potential features (e.g.,  164 ,  166 ,  168 ) that might be enabled or disabled during the use session by policy enforcer  162  based upon the particular policy or unlock mode determined by policy generator  152  and applied during the use session. For instance, when some debug policies are declared for a device, one or more of debug features  0 - n  (e.g.,  164 ,  166 ,  168 ) may be disabled, for instance, to protect access to various sensitive assets. In some implementations, policy enforcer  162  can maintain and consult a mapping of defined debug policies (i.e., defined for the device) and debug features (e.g.,  164 ,  166 ,  168 ). For instance, policy enforcer  162  can receive a policy signal broadcast to IP blocks (e.g.,  160 ) using a secure bus of the device, decode the signal to identify a debug policy to apply during a corresponding debug session, and determine which debug features (e.g.,  164 ,  166   168 ) of the block to enable or disable to enforce the particular debug policy based on a consultation of policy-to-debug feature mapping. 
     In this example of device  150 , fuse controller  170  includes fuse bank  175 , which comprises multiple fuses for storing a unique identifier of the device and for storing secured values generated by fusing station  120  for one or more passwords associated with the device. Fuse controller  170  can include non-volatile memory including, but not necessarily limited to programmable read-only memory (PROM), field programmable read-only memory (FPROM), or one-time non-volatile memory (OTP NVM). Fuse bank  175  includes multiple fuses in which each bit is locked by a fuse and cannot be changed. Data, such as a unique identifier of device  150  or a secured value of a password associated with the unique identifier, can be stored using multiple fuses in fuse bank  175 . The data is burned into fuse bank  175  by fusing station  120  and, in at least some scenarios, is performed after other manufacturing processes for the device have been successfully completed. The fuse controller  170  is also communicatively coupled to aggregator  180  and sends the unique identifier and secured values stored in its fuse bank  175  to aggregator  180  whenever device  150  boots (e.g., runs a boot process to initialize hardware of the device and load an operating system in the device). 
     In this example, aggregator  180  is an IP block of device  150  and is provided with logic that determines whether to grant an unlock request for the device. In one example, aggregator  180  functions as a gate to the device. The unique identifier of the device and its associated secured values, which are stored in fuse bank  175 , are downloaded to aggregator  180  when the device boots. Aggregator  180  caches or otherwise temporarily stores the unique ID and secured values until a password is received from unlock host  130 . Upon receiving a password from unlock host  130 , security engine  185  of aggregator  180  applies a security function to the password received from the unlock host to produce a secured value. Security engine  185  is configured to perform the same security function that is performed by security engine  125  of fusing station  120 . If one of the secured values from fuse controller  170  corresponds to the secured value computed by the aggregator, then aggregator  180  grants the unlock request and unlocks one or more privileged features of the device. Accordingly, policy generator  152  can receive an indication from aggregator  180  to unlock the device. In one example, the indication can include the password (or secured value of the password) used to unlock the device, an unlock mode associated with the password, user authentication information, and/or lifecycle data. Policy generator  152  can manage access to particular features based on a determined policy or unlock mode, as previously described herein. In at least one embodiment, policy generator  152  may also be incorporated in aggregator  180  in at least one implementation. 
     In the example of  FIG.  1   , unlock host  130  is a computing system that can be configured with hardware, firmware, and/or software logic to enable authentication of a user attempting to unlock privileged features of a device (e.g.,  150 ). As used in this specification ‘computing systems’ are intended to encompass servers, appliances, personal computers, laptops, mobile devices, processors, modules, processing systems, or any other suitable device, component, element, proprietary appliance, or object operable to exchange information in a network environment. Unlock host  130  is provided with access adapter  134  for communicating with a device (e.g.,  150 ), and access logic  132  that enables authenticating credentials of a user that is attempting to access the device. The credentials of a user can indicate an access level of the device to which that user is permitted, if the unlock request is granted by aggregator  180 . Users can include, but are not limited to, authorized users of the device manufacturer, authorized users of a customer that receives the device (e.g., OEM), or authorized users of a sub-component vendor. These entities may each run an unlock host (e.g.,  130 ) at their facilities and use the unlock host to unlock privileged features of the device. 
     A user can attempt to unlock a device (e.g.,  150 ) when the device is communicatively coupled to the unlock host, for example, via JTAG access adapter  134  of the unlock host  130  and TAP controller  155  of device  150 . Unlock host  130  is provided with access logic  132  to communicate with the device (e.g.,  150 ) and a database infrastructure (e.g.,  110 ), to which access may be provided by the manufacturer (e.g., in a manufacturer&#39;s cloud or other accessible network). Once a user is authenticated, unlock host  130  can read out the unique identifier of the device from the aggregator (e.g.,  180 ) of the device. Unlock host  130  can establish a network connection to the database infrastructure, such as database infrastructure  110 , and query the database infrastructure based on the unique identifier for a corresponding per part password. The database infrastructure can identify a password (i.e., unaltered) corresponding to the unique identifier and can send the password back to the unlock host. In at least one embodiment, the authentication information associated with credentials of the user, which were provided to unlock host  130 , can be provided to the database infrastructure along with the unique identifier. In this embodiment, the database infrastructure can then determine, based on the authentication information, which password corresponds to the unique identifier. 
     The database infrastructure (e.g.,  110 ) can send the identified password to unlock host  130 , and unlock host  130  can transmit the identified password to the device (e.g.,  150 ) using a TAP command. Data, such as the identified password, can be transmitted to the device via access adapter  134  and TAP controller  155 . 
     Turning to  FIG.  2   ,  FIG.  2    is a simplified interaction diagram of secure unlock system  100 , according to at least one embodiment.  FIG.  2    illustrates potential communications between components in the system including database infrastructure  110 , fusing station  120 , fuse controller  170  of device  150 , aggregator  180  of device  150 , and unlock host  130 . In at least one embodiment, one or more sets of operations correspond to the activities and interactions of  FIG.  2   . Each of the components of secure unlock system  100 , or a portion thereof, may utilize at least one set of operations. Each of the components may comprise means including, for example, processors  119 ,  129 ,  139 ,  159 , for performing such operations. The interactions of  FIG.  2    follow device  150  through at least a portion of a manufacturing flow.  FIG.  2    illustrates interactions that may occur when users of the manufacturer attempt to unlock the device or when the device is provided to another entity (e.g., OEM, sub-component vendor, etc.) and a user associated with the other entity attempts to access the device. 
     Initially, database infrastructure  110  can generate a unique identifier (“unique ID”)  205  for device  150 , along with one or more random passwords, such as password  210 , based on how many levels of access are to be made possible for a use session. The unique ID and one or more random passwords are stored by database infrastructure  110  for future consumption by fusing station  120  and unlock host  130 . Although multiple access levels with corresponding multiple random passwords may be provisioned in device  150 , for ease of illustration, a single password (e.g.,  210 ) is shown in  FIG.  2   . 
     At  200 ( 1 ), unique ID  205  for device  150  and the corresponding password  210  are provided to fusing station  120  by database infrastructure  110 . Fusing station  120  receives unique ID  205  and password  210 . Security engine  125  applies a security function to password  210  to generate secured value  220 . At  200 ( 2 ), fusing station can burn unique ID  205  and secured value  220  into the fuse bank  175  of device  150 . Multiple fuses  177  (e.g., F1, F2, F3, . . . Fx) may be used to store a single data item, such as unique ID  205  or secured value  220 . In at least one embodiment, the same number of fuses may be used to store the secured value as a corresponding unaltered password. 
     When device  150  boots up, at  200 ( 3 ), fuse controller  170  downloads unique ID  205  and secured value  220  from fuses  177  to aggregator  180 . Aggregator  180  can temporarily store the data while waiting for a communication from unlock host  130 . A user may initiate unlock host  130  and provide credentials to the unlock host for authentication. If the user is authenticated by unlock host  130 , then at  200 ( 4 ), unlock host  130  can read the unique ID  205  from aggregator  180 . 
     At  200 ( 5 ), unlock host  130  can query database infrastructure  110  for a password corresponding to the unique ID. Database infrastructure  110  can search its stored data for a match using unique ID  205 . If unique ID  205  is found, then one or more corresponding passwords can be identified. If multiple passwords correspond to unique ID  205 , then database infrastructure  110  can determine which password enables an authorized unlock mode for the user. In at least one embodiment, this determination can be made based on authentication information associated with one or more credentials of the user (e.g., credentials used to authenticate to unlock host  130 ). 
     At  220 ( 6 ), database infrastructure  110  sends the identified password  210  back to unlock host  130 . It should be apparent that if a malicious user attempted to guess a valid unique ID to send to database infrastructure  110 , then a different password (or no password if the guessed unique ID was not a valid ID for any part) would be sent back to unlock host  130  from database infrastructure  110 . Unlock host  130  may use a TAP command to communicate, at  200 ( 7 ), the identified password  210  to aggregator  180 . 
     Upon receiving password  210 , aggregator  180  uses security engine  185  to apply a security function to the password to produce a new secured value. This new secured value produced by the aggregator is compared to secured value  220  from fuses  177  to determine whether there is a correspondence. In at least one embodiment, where security engines  125  and  185  apply the same security function, there is a correspondence if the secured values match. If a correspondence is confirmed, then the unlock request is granted by aggregator  180 . In other embodiments, homomorphic encryption techniques may be used to gain additional properties. In such embodiments, a correspondence between the secured values may be based, at least in part, on the additional properties rather than a full match of secured values, such as hash values. 
       FIGS.  3 - 5    are simplified flowcharts of possible operations that may be associated with an embodiment of secure unlock system  100 .  FIG.  3    is an example flowchart illustrating a possible flow  300  of operations that may be associated with embodiments described herein. In at least one embodiment, a set of operations corresponds to activities of  FIG.  3   . Fusing station  120 , or a portion thereof, may utilize the set of operations. Fusing station  120  may comprise means such as processor  129 , for performing the operations. 
     At  302 , fusing station  120  sends a request to database infrastructure  110  for a unique ID and one or more passwords for a device. At  304 , fusing station  120  receives the unique ID and password from database infrastructure  110 . At  306 , security engine  125  performs a security function on the password to produce a secured value. At  308 , the fusing station accesses the fuse controller of the device to store the secured value and unique ID into fuses  177 . If the fusing station receives multiple passwords for the device, the security function is applied to each password, and each resulting secured value is stored in fuses  177  of the device. At  310 , a message is sent to database infrastructure  110  confirming that the unique ID and secured value of the password were successfully stored in the fuses of the device. A message that confirms the fusing happened successfully can cause the database infrastructure to store the unique ID and password combination. If fusing is not successful, then the part may be destroyed. Therefore, if the message is not received by database infrastructure  110 , or if an error message is sent to the database infrastructure indicating the fusing was unsuccessful, then the database infrastructure does not keep a record of the unique ID/password combination. 
       FIG.  4    is an example flowchart illustrating a possible flow  400  of operations that may be associated with embodiments described herein. In at least one embodiment, a set of operations corresponds to activities of  FIG.  4   . Unlock host  130 , or a portion thereof, may utilize the set of operations. Unlock host  130  may comprise means such as processor  139 , for performing the operations. In an embodiment, one or more operations of flow  400  may be performed by access logic  132 . 
     Flow  400  begins at  402 , where the unlock host authenticates a user based on one or more credentials. At  404 , the unlock host obtains a unique ID from the aggregator in the device. At  406 , the unlock host queries the password/ID store  114  of database infrastructure  110  for a password corresponding to the unique ID. At  408 , the unlock host receives the password and at  410 , forwards the password to the aggregator using a TAP command in one example. 
       FIG.  5    is an example flowchart illustrating a possible flow  500  of operations that may be associated with embodiments described herein. In at least one embodiment, a set of operations corresponds to activities of  FIG.  5   . Aggregator  180  of device  150 , or a portion thereof, may utilize the set of operations. Device  150  may comprise means such as processor  159 , for performing the operations. In an embodiment, one or more operations of flow  500  may be performed by aggregator  180  and security engine  185 . 
     At  502 , the aggregator receives a unique ID of the device and one or more secured values of one or more passwords associated with the unique ID. In one example, downloading the secured values and unique ID to the aggregator may be part of a boot process of the device. Generally, a boot process initializes hardware of the device and loads an operating system into memory. The aggregator can cache or otherwise temporarily store the secured values and then idle or wait until it is invoked. A user may attempt to unlock the device via unlock host  130 . In at least one embodiment, unlock host  130  does not attempt to unlock device  150  unless one or more credentials of the user are successfully authenticated, for example, by an access permission system. An access permission system may be managed by the entity in possession of the device (e.g., manufacturer, OEM, etc.). When a user authenticates to unlock host  130 , at  504 , the aggregator receives a request from the unlock host to unlock the device. In at least one embodiment, unlock system  130  performs TAP commands to read out the unique ID from aggregator  180 . At  506 , in response to receiving the request to unlock the device, aggregator  180  sends the unique ID, which was cached or otherwise temporarily stored by the aggregator during the boot process of the device, to the unlock host. 
     At  508 , the aggregator receives a password from the unlock host. If there are no errors and the correct unique ID (e.g.,  205 ) for the device was used to query database infrastructure  110 , then a password associated with the device is received by aggregator  180 . Otherwise, a different password may be received by the aggregator at  508 . At  510 , aggregator  180  uses security engine  185  to apply a security function to the received password to create a new secured value. As previously described herein, in at least one embodiment, the same security function can be applied by the security engines in aggregator  180  and fusing station  120 . 
     At  512 , the new secured value is compared to the secured value received from the fuses of the device. At  514 , a determination is made as to whether the secured value from the fuses corresponds to the new secured value. If multiple secured values were downloaded, then the cached secured values are searched to determine whether any one of them corresponds to the new secured value. A correspondence can be determined to exist if the new secured value matches, or otherwise corresponds to (e.g., when homomorphic encryption techniques are used), the secured value from the fuses. If there is a correspondence, then at  516 , the unlock request is allowed. Unlocking the request can be accomplished by providing an indication to a policy generator (e.g.,  152 ) of the device that the device is to be unlocked. The indication can include the password (or secured value of the password) used to unlock the device, authentication information associated with the user, and/or lifecycle information of the device, to be used to determine what level of access or unlock mode is permitted. In some scenarios, the aggregator determines the unlock mode that is to be applied and provides the unlock mode to the policy generator and the fuse controller. If at  514 , no correspondence is determined to exist between the new secured value and the secured value from the fuses, then at  518 , the unlock request can be blocked. Future unlock requests are also blocked, as indicated at  520 , until the device is reset. 
     Signed Token to Unlock a Device 
     Turning to  FIG.  6   , a secure unlock system  600  is another embodiment that for enabling authorized users to unlock privileged features in the device. The simplified block diagram illustrates an example of secure unlock system  600 , which includes a signing server  610 , an unlock host  630 , a device  650 , and a network  605 . Device  650  can be a system that includes multiple components. A user  640  interacts with unlock host  630  to generate a token specifying particular privileged features on device  650  to be unlocked. Once a signed token is injected into device  650 , user  640  can be authenticated to unlock and use privileged features on device  650 . These privileged features may be related to debugging, testing, validating, provisioning, prototyping, analyzing, etc. features for accessing proprietary computing blocks and/or proprietary information on the device. Privileged features can also include certain output messages containing or indicating proprietary information and code associated with security or authentication. 
     In secure unlock system  600 , an authorized entity (e.g., manufacturer, customer) can control the right to use privileged features on a device (e.g.,  650 ), where the control is independent of the manufacturer or any other entity. This control is managed using signing server  610  to sign the token generated for the device by the unlock host, injecting the signed token into the device, and verifying the signed token when the device boots for a use session. Unlock host  630  can generate a token based on information from the device and communicate with signing server  610  to request the token to be signed. Signing server  610  hosts a private key for signing tokens. The signed token can then be injected into the device, for example, by unlock host  630 . An authorized user can use unlock host  630  to unlock one or more privileged features (e.g., debugging, testing, validation, prototyping, analyzing performance, etc.) of the device. When the user initiates a use session and is authenticated by unlock host  630 , an embedded security engine (e.g.,  690 ) in the device verifies the authenticity and integrity of the signed token. Additionally, the security engine determines whether the token is applicable to the device being accessed and optionally, whether the token has expired. If all of the checks pass, then the device is unlocked by the security engine in a particular unlock mode, based on unlock data in the token. Privileged features specified by the unlock data in the token can be used during the session. Thus, the authorized entity can obtain additional information from the device useful for their development, debug, or validation, among other examples. 
     Secure unlock system  600  provides several advantages for unlocking privileged features on a device. For authorized entities of a device, such as OEMs, sub-component vendors, etc., the signed token solution of secure unlock system  600  eliminates the need for the manufacturer of the device to be involved in the unlocking process. Instead, the authorized entity can control who can unlock the device, how much access is given to those authorized users who can unlock the device, and how the signing server is implemented and managed, among other examples. The verification of the token is performed without the need of an external server under the control of the manufacturer. During the manufacturing flow of an OEM, where connection to external networks and servers may be unavailable, if access is needed to the device, for example to debug or test the device, a token can be used to unlock the device without dependency on a successful connection to an external server. Also, as the token scheme is a cryptographically secure method for enabling privileged features instead of obscure methods, only if the user consents to a certain use session (e.g., debug, test, etc.) by providing the device for the use session can the privileged features in the device be used. Thus, the user&#39;s privacy is protected. 
     Secure unlock system  600  also enables an authorized entity to choose which privileged features can be unlocked and which privileged features remain locked or otherwise restricted. For example, an OEM may be working with a third-party vendor for development of features on their platform. The OEM can provide tokens to the third-party vendor only for the devices that the OEM has provided to the third-party vendor. This ensures that third-party vendors cannot release tokens to unauthorized entities or individuals that work for all platforms owned by the OEM. 
     Another advantageous aspect of secure unlock system  600  involves expiry detection for a token, multiple device unlocking based on a token, granular control of privileged features, and protection against replay attacks. Expiry properties can be configured (e.g., by a manufacturer, an OEM, etc.) to enable administrators to control how long a token is to remain valid for a specific target device. Also, a user can generate one token for multiple devices, thus easing the deployment troubles for system validation setup, for example. Additionally, administrators can provide granular control on which privileged features in a device can be unlocked per user, per device. For example, an OEM can enable a third-party vendor to conduct debugging of an OEM system that the third-party vendor is using for development, but can restrict the kinds of messages the vendor can see when the vendor unlocks the device. Finally, replay attacks can be prevented due to an ephemeral nonce incorporated in the token that makes a valid token ephemeral based on the OEM policy. Thus, recording the token during the unlock would not benefit a malicious user. 
     With reference to  FIG.  6   , a description is now provided about some of the possible infrastructure that may be included in an embodiment of secure unlock system  600 . Device  650  can include a policy generator  652 , one or more computing blocks such as IP block  660 , a fuse controller  670  including a fuse bank  675  with multiple fuses, an aggregator  680 , a real-time clock  654 , a test access port (TAP) controller  655 , and a security engine  690 . Computing blocks, such as IP block  660 , can each include a policy enforcer (e.g.,  662 ) and multiple privileged features (e.g.,  664 ,  666 ,  668 ), as previously described herein. Security engine  690  can include hardware (HW)  692 , read only memory (ROM)  694 , and firmware (FW)  696  for verifying a token and determining if the token is applicable to the device. In the example of  FIG.  6   , unlock host  630  includes access logic  632  for authenticating a user (e.g.,  640 ) and performing use sessions that can include debugging, testing, validating, provisioning, prototyping, analyzing, etc. Unlock host  630  also includes an access adapter  634  for communicating with devices (e.g.,  650 ). Unlock host  630  further includes a token generator  636  and a token injector  638  for generating a token for unlocking privileged features of a device (e.g.,  650 ) and injecting the token, or causing the token to be injected into, the device. Signing server  610  includes a private key store  611  and a token signing engine  612  to secure tokens by signing the tokens with a private key from the private key store. Elements of  FIG.  6    also contain appropriate hardware such as memory elements (e.g.,  617 ,  637 ,  657 ) and processors (e.g.,  619 ,  639 ,  659 ), which may be realized in numerous different embodiments, at least a few of which will be further described herein. 
     Secure unlock system  600  may span multiple, possibly discrete network environments. Generally, secure unlock system  600  can include any type or topology of networks, at least partially indicated by network  605 . Possible examples of network  605  are described herein at least with reference to network  105  of  FIG.  1   . 
     Signing server  610  can be provisioned in any suitable network environment(s) capable of network access (e.g., via network  605 ) to unlock host  630 . In at least one embodiment, signing server  610  and unlock host  630  may be provisioned, managed, used, and/or otherwise under control of an authorized entity that uses unlock host  630  to access device  650 . For example, a manufacturer could use an unlock host (e.g.,  630 ) to unlock device  650  during or after the manufacturing flow for the device. An OEM could use its own unlock host to unlock device  650  once the OEM has received the device to be implemented in its own product. These entities may use their own signing server to sign tokens to manage access to devices when those devices are under their control, such as for manufacturing or production. Signing server  610  may be provisioned in a local area network with unlock host  630 , in a remote network that unlock host  630  can access, or in a cloud network, among other examples. In another example, a third-party vendor of the manufacturer or an OEM, may not be given the authorization or ability to provision its own tokens. Instead, devices injected with a signed token, or devices with a separate firmware image including the signed token, may be provided to the vendor to unlock privileged features specified in the token. The token may also specify an expiration parameter that specifies the amount of time during which the token is to remain valid. 
     Unlock host  630  can be communicatively coupled to device  650  when the entity accessing the unlock host has physical possession of the device. For example, during the manufacturing process, an unlock host of the manufacturer may be coupled to device  650 . Once the device is delivered to an OEM, an unlock host of the OEM may be coupled to device  650 . If device  650  is provided to a sub-component vendor for additional functionality, an unlock host of the sub-component vendor may be coupled to the device. One common way of accessing device  650  is the Joint Test Action Group (JTAG) standard, which was previously described herein with reference to device  150  and unlock host  130  in  FIG.  1   . Access adapter  634  of unlock host  630  can be a JTAG adapter, and can be connected to device  650  via any suitable interface including, but not limited to, Ethernet, peripheral component interconnect (PCI), and universal serial bus (USB). 
     The JTAG standard defines a generic external test access port (TAP), which is represented by test access port (TAP) controller  655  in device  650 . This TAP controller can provide an interface to aggregator  680  when unlock host  630  communicates with device  650 , such as when a user generates and provisions a token or attempts to unlock the device after the token is injected into the device. JTAG can be used in unlock host  630  to request and receive a device identifier from the device, and to inject the token back into the device after the token has been signed. JTAG may also be used by access logic  632  to enable use sessions for the device that include debugging, testing, validating, provisioning, prototyping, and analyzing. Although JTAG is one example industry standard that could be used to obtain the needed information from the device (e.g., device identifier, nonce, timestamp, etc.), other standards could be implemented as well. 
     Although  FIG.  6    shows signing server  610  in communication with a single unlock host  630 , it should be appreciated that any number of unlock hosts provisioned, managed, used, and/or otherwise controlled by the same authorized entity may be capable of communicating with signing server  610  to unlock devices as needed during production and/or post-production (e.g., repairs, recalls, etc.) of devices. Furthermore, although a single device is shown coupled to unlock host  630 , it should be appreciated that unlock host  630  could be communicatively coupled to any number of other devices as they are debugged, tested, validated, provisioned, prototyped, analyzed, etc. 
     Signing server  610  can be embodied in one or more network elements and possibly one or more storage elements, which have been previously described herein this specification. Signing server  610  can be configured with hardware, firmware, and/or software logic to perform operations described herein related to receiving tokens from an unlock host (e.g.,  630 ), using private keys to sign the tokens, and sending the signed tokens back to the unlock host. Signing server  610  can include private key store  611 , which contains private keys that are used to sign tokens generated by unlock host  630  and provided to the signing server to be signed. The private key store may be provided in signing server  610 , as shown, or may be communicatively coupled to signing server  610  via some network. 
     Signing server  610  is configured with token signing engine  612 , which includes an algorithm used to sign a token provided by unlock host  630 . In at least one embodiment, token signing engine  612  may use a digital signing process involving an asymmetric key pair that includes a private key and an associated public key. In this example, the token signing engine applies a one-way hash function to at least some of the contents of the token to produce a hash value. Then, a cryptographic algorithm uses the private key of the key pair to sign (or encrypt) the hash value to create a signature. The signature can then be inserted into the token header of the token. In one implementation, token signing engine  612  also inserts the public key of the key pair into the token header. In such an implementation, the signature created by the private key can be reverted (or decrypted) to the data that was signed (e.g., the hash value) by using the public key of the key pair. In another implementation, the private key could be a symmetric key, in which the signature created by the private key can be inverted (or decrypted) to the pre-signed data by using the same private key. 
     In the example of  FIG.  6   , unlock host  630  is a processing system that can be configured with hardware, firmware, and/or software logic to enable generating and provisioning tokens for devices with privileged features. A user can attempt to access a device (e.g.,  650 ) when the device is communicatively coupled to the unlock host, for example, via JTAG access adapter  634  of the unlock host and TAP controller  655  of the device. Unlock host  630  is provided with access logic  132 , token generator  636 , and token injector  636  to communicate with the device (e.g.,  650 ) and signing server  610 . Once a user is authenticated, unlock host  630  can receive, from the device, a device identifier and other information, such as a nonce and a timestamp, among other examples. At least some of this information comes from the aggregator (e.g.,  680 ) of the device. Token generator  636  can generate a token based, at least in part, on the device ID and other information. After the token is signed by signing server  610 , token injector  638  injects the signed token into a boot partition (e.g.,  620 ) of the device, as indicated by signed token  625 . 
     In at least one implementation, unlock host  630  can also enable authentication of a user (e.g.,  640 ) attempting to access a device (e.g.,  650 ) for a use session that may invoke one or more privileged features, if unlocked. Unlock host  630  is provided with access adapter  634  for communicating with a device (e.g.,  650 ), and access logic  632  for authenticating credentials of a user. Users can include, but are not limited to, authorized users of the device manufacturer, authorized users of a customer that receives the device (e.g., OEM), or authorized users of a sub-component vendor. Manufacturers and customers such as OEMs may each run an unlock host (e.g.,  630 ) at their facilities to generate and provision signed tokens for devices. When verified, the signed tokens enable authorized users to conduct various use sessions in which one or more privileged features on the device are unlocked. Such privileged features could include, for example, debugging, testing, validating, provisioning, prototyping, or analyzing features for accessing proprietary computing blocks and/or proprietary information in the device. Sub-component vendors or other third-party vendors may run an unlock host (or similar system), but without the authority to generate and provision tokens. For example, a manufacturer or OEM may generate and provision tokens in a group of devices to be provided to a vendor, where the tokens specify particular privileged features that may be unlocked during a debug (or other) use session on any of the devices. 
     Possible embodiments of device  650  can include, but are not necessarily limited to, a processing system, a central processing unit (CPU), system on chip (SoC), devices product, microprocessor, chip and microchip (e.g., Platform Controller Hub (PCH)), integrated circuit (IC), and/or graphical processing units (GPU). One or more computing blocks (e.g., IP block  160 ) are provisioned in device  650 , one or more of which contain proprietary data and/or code. For ease of illustration, a single IP block is shown in  FIG.  1   . However, devices typically contain multiple IP blocks. In device  600 , the configuration of IP blocks, such as IP block  660 , and policy generator  652  may be similar to IP block  150  and policy generator  152 , respectively, which were previously described herein with reference to  FIG.  1   . In at least one embodiment of secure unlock system  600 , however, policy generator  652  can compute access policies based on the unlock mode, which may be specified in the token. For example, the token may specify which privileged features to unlock (e.g., by enabling or disabling depending on the feature). The policy generator  652  can compute access policies based on the privileged features specified in the token. 
     In this example of device  650 , fuse controller  670  includes fuse bank  675 , which comprises multiple fuses for storing a device identifier of the device and, in at least some implementations, for storing a secured value (e.g., hashed or other secured value) of the public key of the key pair used to sign and verify tokens. Fuse controller  670  can include non-volatile memory including, but not necessarily limited to programmable read-only memory (PROM), field programmable read-only memory (FPROM), or one-time non-volatile memory (OTP NVM). Fuse bank  675  includes multiple fuses in which each bit is locked by a fuse and cannot be changed. Data, such as a device identifier of device  650  or a hashed public key of a key pair, can be stored using multiple fuses in fuse bank  675 . The fuse controller is also communicatively coupled to aggregator  680  and sends the device identifier and hashed public key stored in its fuse bank  675  to aggregator  680  whenever device  650  boots. 
     Aggregator  680  of device  650  is an IP block and is provided with logic that enables access to the device. In one example, aggregator  680  functions as a gate to the device. The device identifier and hashed public key, which are stored in fuse bank  675 , are downloaded to aggregator  680  when the device boots. Aggregator  680  caches or otherwise temporarily stores the device ID and hashed public key and provides the data to security engine  690  when requested. When a token has been verified by security engine  690 , it can send a request to aggregator to unlock the device based on the verified token. Aggregator  690  can use unlock data provided in the token to unlock privileged features on the device (e.g., via policy generator  652 ). Aggregator  690  can also unlock the fuse controller based on the unlock mode indicated by the verified token. 
     Boot partition  620  may be configured in device  650  to enable the device to boot when power is applied to it. Boot partition  620  can be a primary partition that contains a boot loader to load the operating system. In at least one embodiment, boot partition  620  can be injected with a signed token  625  by unlock host  630 , which can be used to determine whether to unlock the device. 
     In the example shown in  FIG.  6   , embedded security engine  690  can be configured with hardware, firmware, and/or software logic to enable authentication and verification of a token. In at least one embodiment, security engine hardware  692 , ROM  694 , and firmware  696  provide information needed to generate a token and verify a signed token obtained from the boot partition (or a firmware file used to boot the device) when device  650  boots under a use session of an authorized user. During a process to generate a token for a device, security engine FW  696  gets a device ID and a timestamp, and generates a nonce when requested by unlock host  630 . Real-time clock  654  of device  650  can be used to generate the timestamp. Security engine FW  696  provides this information to unlock host  630  to enable the unlock host to generate a token. Security engine FW  696  can also store a signed token in the boot partition of the device. During a process to unlock the device, security engine HW  692 , security engine ROM  694 , and security engine FW  696  coordinate to verify the signed token, and scrub the hardware to hide secrets that are not to be accessible even with the token. 
     It should be noted that numerous variations and configurations of device  650 , unlock host  630 , and signing server  610  are possible. In particular, the operations and functions described with reference to security engine FW  696  could be implemented in entirely in hardware, entirely in software, entirely in firmware, or any suitable combination thereof. Furthermore, in at least one embodiment, security engine  690  can be implemented based on virtualization technologies. Generally, as long as the security engine&#39;s root of trust is provided by hardware, the verification technique used to verify the token cannot be attacked and, therefore, may be implemented in any suitable configuration (e.g., hardware, software, firmware, virtualization, etc., and any combinations thereof). 
     In  FIGS.  7 - 8   , additional possible details related to a token used in secure unlock system  600  are illustrated.  FIG.  7    illustrates how a token device identifier (ID) can be created. In at least one embodiment, a token device ID  710  is derived from a unique value stored on a device (e.g.,  650 ) and two other parameters  704  and  706 . The unique value is unique per device and may be an aggregator device identifier (ID)  702 . Keyword  704  is a parameter that is different for each project and is a constant value in a device. For example, a keyword for one project could be ABC v1.0 and a keyword for another project could be XYZ v1.0. A nonce  706  is a value generated randomly at every device ID request by the embedded security engine firmware. The value can be generated using a hardware based random number generator in the device. In an embodiment, the nonce can be 32 bits. The nonce can be used to make the token “fresh” such that a replay of previous token is not possible if the nonce has been erased on the device. In some embodiments, the token device ID may be created without the keyword. 
     A derivation function  708  can be applied to the combination of aggregator device ID  702 , keyword  704 , and nonce  706 , to generate token device ID  710 . The derivation function can be any suitable function (e.g., hash function, encryption algorithm, other cryptographic or obfuscation function, etc.) to create a combined secured value representing the unique value and parameters. For ease of description, the derivation function used to create the token device ID may be further referenced herein as a “hash function” and the token device ID may be further referenced herein as a “hashed value.” In one example, aggregator device ID  702  is a 64-bit unique value relative to other device IDs of other devices, and nonce  706  is a 32-bit value. The resulting token device ID may be truncated to 96 bits. Although particular values and bit sizes are disclosed, numerous other possible values, combinations of values, bit sizes of values and/or combinations of the values, and methods of generating or otherwise obtaining those values could be implemented to achieve the objectives of one or more embodiments describe herein based on particular needs and implementations. 
       FIG.  8    illustrates an example structure  800  of a token that may be used in one or more embodiments described herein. The example token structure  800  includes three sections: a token header  810 , token properties  820 , and a token payload  830 . In this example, token header  810  includes a first segment  812  with a token version, size, and security version number (SVN), and a second segment  814  with a signature of the token and a public key that is the asymmetric pair to a private key used by (and possibly stored in) signing server  610 . The signature of the token can be generated by signing server  610  using data in token properties  820 , token payload  830 , and/or first segment  812  of token header  810 , as indicated by  840   a  and  840   b . In one example, a private key stored or accessed by signing server  610  can be used to sign the data indicated by  840   a  and  840   b  in token  800 . In at least one embodiment, signing the data may include, but is not limited to, applying a one-way hash function to certain data in the token (e.g.,  840   a  and  840   b ) to produce a hash value, and encrypting or otherwise generating a signature based on the hash value. 
     Token properties  820  contains information related to the token and to the particular device that was used to create the token. Information related to the token can include, for example, the token payload type, token payload size, and an expiration parameter (e.g., expiration seconds, minutes, hours, etc.). Information related to the particular device that was used to create the token can include, for example, device ID, a nonce, and a timestamp. In one embodiment, the device ID stored in the token can be the token device ID, which is the hashed value of the aggregator device ID, the nonce, and the keyword obtained from the device. In other embodiments, the device ID can be the aggregator device ID stored in the fuses of the device. In yet other embodiments, both the token device ID and the aggregator device ID could be included in the token properties. 
     In some scenarios, a single token may be generated to unlock multiple devices. For example, if an OEM sends a group of the same type of devices to a third-party vendor to obtain some additional functionality, the OEM may generate a token to unlock all of the devices in that group. To enable a token to unlock multiple devices, token properties  820  can contain a list of device IDs of devices that can be unlocked by the token, along with the nonces and timestamps associated with each device ID. In some scenarios, token properties  820  may also contain flags that indicate whether the token can be used without device ID (aggregator device ID or token device ID) checking, among other examples. 
     It should be noted that the contents of token  800  shown in  FIG.  8    provide one possible implementation, and that variations of the contents and the ways in which token verification is performed are not limited by the broad scope of this disclosure. For example, token properties  820  may include aggregator device IDs, the token device IDs, or both. Furthermore, a token device ID may be computed using other combinations of information with the aggregator device ID. For example, either the nonce or the keyword, but not both, may be combined with aggregator device ID in one variation. In these alternatives, the process for verifying the token may be altered according to the type of contents of token properties  820 . The examples provided herein are for illustrative purposes and numerous other variations and configurations of the token may be implemented within the scope of the present disclosure. 
     Token payload  830  contains unlock data used for granular control of privileged features of computing blocks on the device. Unlock data can include configuration information to be used by the device (e.g., by policy generator  652 ) to configure access policies to be applied to the device. Granular control of privileged features can include, for example, enabling debugging, testing, validating, provisioning, prototyping, or analyzing features in a computing block, permitting or enabling messages to be output, disabling code associated with security and/or authentication processes, etc. In at least one embodiment, unlock data can specify a privileged feature (also referred to herein as ‘personality knob’) and indicate how the privileged feature is unlocked. Specific examples of granular control that can be configured based on unlock data provided in token payload  830  include, but are not limited to, enable debug of sensor hub, enable debug of audio, enable debug of image processing unit, enable debug of low power sub-systems, disable secure boot, disable FW authentication, enable CPU debug, enable messages to be output, etc. Generating the unlock data in the payload can be controlled by a token generation tool, such as token generator  636  provided in unlock host  630 . 
     The payload section of the token payload can be used by a manufacturer or OEM to customize tokens when a ‘one size fits all’ token cannot be used. For example, if an OEM is engaging a third-party vendor for feature development on the platform, then the OEM can specify in the token payload which privileged features can be unlocked by the vendor and/or which messages output by the device are permitted to be viewed by the vendor. Different vendors may be given different types of access to the same group of devices and/or to different groups of devices. Unlock data to enable this customized unlocking is stored in token payload  830 . In one example, the OEM can inject the token into each device (e.g., in boot partition) that the third-party vendor is to further develop or enhance. The OEM could also give the token to the third-party vendor to enable the vendor to stitch together a firmware image for the boot partition if the boot partition needs to be updated after changes or updates to the device are made by the vendor. In another scenario, the token may not be injected into each boot partition by the OEM. Instead, once the token is generated, the OEM may generate a firmware image with the token and a firmware image without the token and provide both firmware images to the third-party vendor. For a particular use session, the third-party vendor can boot a device with the appropriate firmware image (with or without the token) depending on whether privileged features will be needed during the particular use session. Thus, unlocking privileged features, including output messages, can be tailored to features and messages needed by the third-party vendor to efficiently complete their work on the devices, for example. 
     Turning to  FIG.  9   ,  FIG.  9    is a simplified interaction diagram of secure unlock system  600 , according to at least one embodiment.  FIG.  9    illustrates potential communications between user  640  and certain components in the system including unlock host  630 , security engine firmware (FW)  696  of device  650 , real-time clock  654  of device  650 , and signing server  610 . The interactions of  FIG.  9    show an example flow for provisioning a token in the device. The interactions may occur at a manufacturer&#39;s premises during or subsequent to the completion of the manufacturing flow. In this scenario, unlock host  630  and signing server  610  are systems controlled and/or managed by the manufacturer. The interactions may also occur when the device is provided to another entity (e.g., OEM) and that entity has a need to access the device for debug or another use that requires one or more privileged features to be unlocked. In this scenario, unlock host  630  and signing server  610  are systems controlled and/or managed by the other entity (e.g., OEM). 
     At  902 , a user accesses unlock host  630  to request unlocking of device  650 . The unlock host may require appropriate authentication using credentials provided to the user by the entity associated with the unlock host (e.g., manufacturer, OEM). In at least one scenario, the user may access the unlock host  630  via any suitable user interface such as a mouse, keyboard, touch pad, touch screen, trackball, etc. At  904 , unlock host  630  requests the device ID from security engine FW  696  of device  650 . Security engine FW  696  requests the current time from real-time clock  654  of the device, and at  908 , the real-time clock returns the current time. 
     Security engine FW  696  generates a nonce at  910 , at least partly in response to receiving the request for the device ID. Nonce  910  can be generated randomly using a hardware-based random number generator in response to the request for a device ID. Security engine FW  696  causes the nonce and current time to be saved in the device. In one example, at  912 , security engine FW  696  communicates with real-time clock  654  to save the nonce and time. At  914 , a status related to the saved data is returned to the security engine FW  696  from real-time clock  654 . 
     Security engine FW  696  can obtain a device ID of the device from an aggregator (e.g.,  680 ) in the device. In at least one embodiment, when the device boots, the aggregator device ID may be downloaded from fuses of the device to the aggregator, where the aggregator device ID is cached or otherwise temporarily stored until it is requested by unlock host  630 . At  916 , security engine FW  696  sends the aggregator device ID and other information to unlock host  630 . The aggregator device ID and at least some of the other information can be used to generate a token device ID by unlock host  630 . In at least one embodiment, the other information can include a token structure identifier, a firmware version, a platform identifier (e.g., keyword indicating a particular project, product generation, product segment, etc.), and a device ID parameter list. The device ID parameter list can include an aggregator device ID, the nonce generated by the device, and the timestamp returned from the real-time clock at  908 . In another embodiment, the token device ID can be computed by security engine FW  696  and provided to unlock host  630 . In this implementation, the token device ID may be stored on the device for future use in the token verification process further described herein with reference to  FIG.  12   . 
     At  917 , unlock host  630  generates a token. In one example, the token can have the same or similar configuration as token structure  800  of  FIG.  8   , including a token header, token properties, and a token payload. A token header (e.g.,  810 ) can include the token version, token size, and security version number (SVN). SVN indicates the correct signing keys to be used. The token properties of the token generated at  917 , includes a payload type and size, the device ID (e.g., token device ID or aggregator ID or both), the nonce, the timestamp, and an expiration parameter. If the token device ID is included in the token properties, it may be computed by unlock host  630  based on the aggregator device ID, the nonce, and the keyword, received at  916 . In other embodiments, the token device ID may have been computed by security engine FW  696  and provided to unlock host  630  at  916 . 
     The expiration parameter together with the timestamp can define how long the token may remain valid. The expiration parameter could be configured in numerous different ways including, but not necessarily limited to, a future timestamp indicating the date and time when the token is no longer valid or a number of seconds, minutes, hours, etc. indicating the amount of time after the timestamp during which the token remains valid. The expiration parameter may be desirable to avoid giving a particular user, or entity such as a third-party vendor, an unlimited amount of time for using privileged features that are unlocked by the token. 
     If the token is to be applicable to a group of devices, then unlock host  630  can add the device IDs, nonces, and timestamps for each of the other devices in the group to the token properties in the token. This information for the other devices may have been previously obtained by unlock host  630  for each device. The token properties may also indicate how many device IDs are listed in the token properties. 
     The token payload can include unlock data that indicates which privileged features can be unlocked and how they are unlocked (e.g., enabled, disabled, etc.). In one example, unlock data can be configured using a token generation tool, such as token generator  636 , which enables a user to select particular privileged features to be included in the token payload. For example, a token being generated for a first group of devices to be further developed or enhanced by Vendor A may be given a different set of unlock data than the unlock data in a token payload generated for a second group of devices to be further developed or enhanced by Vendor B. In another scenario, if the first group of devices is provided to Vendor B for additional development/enhancement after Vendor A completes its development/enhancement, then a new token can be created for the first group of devices with new unlock data specific to Vendor B. 
     Once the token is generated, at  918 , unlock host  630  sends the token to signing server  610  with a request to sign the token. At  920 , the signing server verifies user permissions for signing a token. Thus, only authorized users may be allowed to get tokens signed by signing server  610 . This authorization can be managed by whatever entity is creating the token (e.g., manufacturer, OEM, etc.). If the user permissions are not verified, then an error message can be returned and the token is not signed (not shown). 
     If the user permissions are verified, however, then at  922 , the token is signed. In at least one embodiment, the signing server securely stores (or has access to) a private key of an asymmetric key pair for signing the token. The asymmetric key pair can include a private key for signing the token and a public key for converting the signature back to its original form. In one example, the signature can be generated by using the private key to sign portions of the token (e.g.,  840   a - 840   b ). In at least some embodiments, signing the token portions with the private key can include applying a hash function to the selected token portions (e.g.,  840   a - 840   b ) to create a hash value, and encrypting the hash value with the private key to create the signature. The signature is then added to the token header, along with the public key. In another implementation, the unlock host inserts the public key into the token header. 
     After the token is signed, at  924 , signing server  610  sends the signed token back to unlock host  630 . At  926 , the unlock host can issue a command to inject the token into the boot partition. At  928 , security engine FW  696  writes the signed token to the boot partition of the device. At  930 , the security engine FW can return a status of the write operation to the unlock host. At  932 , the status can be returned to the user for example, by displaying the status on a display indicating whether the signed token was successfully injected into device  650 . 
       FIG.  9    illustrates one possible flow for token generation and injection into a device to enable the unlocking of privileged features of the device, according to at least one embodiment. As illustrated in the flow, the device has a security engine FW (e.g.,  696 ) to generate the ephemeral device ID and inject the token into the device by storing the token in the boot partition of the device. However, injection is not restricted to only the flow of  FIG.  9   . Injection can also be achieved using a host process of the device to communicate with the embedded security engine to get the device ID and request the signed token to be stored in the boot partition. A host process of the device is intended to mean a CPU/system partition running the device operating system (e.g., Windows, Android, etc.). 
     Turning to  FIGS.  10 A- 10 B , a simplified interaction diagram of secure unlock system  600  is illustrated, according to at least one embodiment.  FIGS.  10 A- 10 B  illustrate potential communications between components of device  650 , including aggregator  680 , fuse controller  670 , security engine HW  692 , security engine ROM  694 , security engine FW  696 , and real-time clock  654 . The interactions of  FIGS.  10 A- 10 B  show an example flow that may occur subsequent to device  650  being provisioned with a signed token as shown in  FIG.  9   , or subsequent to a signed token being generated and stitched into a firmware image that can be used to boot device  650 . Specifically,  FIGS.  10 A- 10 B , illustrate example interactions that may occur when a user initiates a use session for device  650 . A use session could include, but is not necessarily limited to, debugging, testing, validating, provisioning, prototyping, and/or analyzing. 
     In  FIG.  10 A , at  1002 , device  650  boots with a token present, either injected in the boot partition of the device, or included in a firmware image used by the boot partition to boot the device. At  1004 , the initial firmware is loaded from security engine ROM  694 . At  1006 , security engine FW  696  requests the current time from real-time clock  654 , which is returned by the real-time clock at  1008 . At  1010 , security engine FW  696  requests the saved timestamp and nonce from real-time clock  654 , both of which are returned by the real-time clock at  1012 . In other implementations, the device may be connected, or otherwise have access, to another system with data storage where the timestamp and nonce are stored. 
     At  1014 , the token is verified. Generally, the signature, a hash of token contents, the device ID, the nonce, and the timestamp are evaluated to determine whether the token is verified. Details of this verification process is more described in more detail with reference to  FIG.  11   . If the token is not verified at  1014 , then device  650  just continues with a normal boot. 
     If the token is verified at  1014 , operations and interactions at  1016 - 1028  offer one possible implementation in which secrets (e.g., keys such as an enhanced privacy identification key, etc.) on the platform are scrubbed, or hidden, to ensure they are not revealed when privileged features on the device are unlocked and used by a user. In this example, once the token is verified at  1014 , the security engine HW  692  is set up with breadcrumbs that are read upon reset of the device. Breadcrumbs inform the security engine  690  that the token has already been verified and the unlock mode has been determined. At  1016 , a hardware scrub of security engine ROM  694  is requested by security engine FW  696 . At  1018 , the security engine is reset by security engine FW  696 . At  1020 , in  FIG.  10 B , a reset exit indicates that fuse controller  670  is being set up. At  1022 , the security engine HW performs a hardware scrub of fuses to prevent any secrets contained in the fuses from being accessed when the device is unlocked. At  1024 , a first instruction is fetched from security engine ROM  694  by security engine HW  692 . At  1026 , breadcrumbs are found for the hardware scrub. Breadcrumbs include information inserted in the security engine ROM to mark places where modifications or other changes are to be avoided. At  1028 , a hardware scrub of the security engine ROM  694  is performed. 
     Once the fuses and security engine are scrubbed, at  1030 , security engine FW  696  sends a request to aggregator  680  to unlock the device based on the token payload. Specifically, unlock data in the token payload is applied to unlock privileged features. In one example, policy generator  652  can generate policies based on the unlock data in the token payload. At  1032 , aggregator  680  provides the unlock mode to fuse controller  670  so that fuse controller  670  knows what fuse data can be accessed. At  1034 , security engine HW  692  can request fuse data from fuse controller  670 , which may normally be locked and inaccessible to security engine  690 . Because an unlock mode has been activated in the device, at  1036 , fuse controller  670  sends fuse data back to the security engine HW  692  based on what data is indicated as being unlocked by the particular unlock mode that has been activated. Because the activated unlock mode is used to determine what fuses are sent out to the security engine  690 , this ensures that the hardware automatically takes care of the security of the secrets based on the unlock mode. 
       FIG.  11    is an example flowchart illustrating a possible flow  1100  of operations that may be associated with embodiments described herein. In at least one embodiment, a set of operations corresponds to activities of  FIG.  11   . In at least one embodiment, various components of device  650 , or portions thereof, may utilize the set of operations. Device  650  may comprise means such as processor  659 , for performing the operations. In at least one embodiment, flow  1100  is one example of the flow of device  650  during a boot process, where the device was previously injected with a signed token to enable the unlocking of one or more privileged features on the device. 
     In the example of  FIG.  11   , at  1102 , a boot process is initiated. A boot process initiates after the device is powered on. The boot process can initialize the hardware of the device and can load the operating system for the device. At  1104 , the signed token stored in the device is retrieved (e.g., read, requested and received, or otherwise obtained). At  1106 , the current time is obtained from a real-time clock on the device. At  1108 , a timestamp and nonce, which were generated and saved during a process to generate the token, are obtained. The timestamp and nonce may be stored on the device in at least one embodiment. In other embodiments, they may be stored in a separate storage element coupled to the device with a direct communication link or via some network. 
     At  1110 , an attempt is made to verify the signed token. The verification process ensures that the signed token is verified for authenticity (based on its signature), integrity (based on a hash of its contents), device specific (based on its device ID), and expiration (based on a nonce and/or time). Additional details related to the verification process for the token are shown and described herein at least with reference to  FIG.  12   . At  1112 , a determination is made as to whether the verification was successful. If the signed token was not verified, then at  1114 , the device can continue with a normal boot, and no privileged features on the device are unlocked. 
     If the signed token is determined to be verified at  1112 , then at  1116 , breadcrumbs are inserted in the hardware to inform the security engine that the signed token has already been verified and the unlock mode has been determined. At  1118 , the security engine is reset. At  1120 , secrets and confidential information (e.g., manufacturer secrets such as keys, etc.) that must not be accessible, even in an unlocked state, are scrubbed (or hidden) so that they cannot be found when unlocked privileged features are used. Once the secrets are scrubbed, one or more privileged features are unlocked at  1122 . The unlock data in the token payload of the token is applied to unlock the privileged features. At  1124 , the unlock mode indicated by the unlock data is applied to the fuses to determine which fuses can be sent to the security engine. Thus, the hardware automatically protects the security of the secrets based on the unlock mode. 
       FIG.  12    is an example flowchart illustrating a possible flow  1200  of operations that may be associated with embodiments described herein. In at least one embodiment, a set of operations corresponds to activities of  FIG.  12   . In at least one embodiment, security engine FW  696 , or a portion thereof, may utilize the set of operations. Security engine FW  696  may comprise means such as processor  659 , for performing the operations. In at least one embodiment, flow  1200  is one example of verifying a token, as shown at  1014  of  FIG.  10 A and  1110    of  FIG.  11   . 
     Generally, in flow  1200  evaluations are performed to determine the authenticity and integrity of the token. Determinations are made as to whether the signature in the token header of the token is valid (e.g.,  1204 ) and whether the contents of the token read from the device are valid (e.g.,  1206 ). A signature is determined to be valid if it is authentic (i.e., signed by the appropriate entity such as signing server  610 ). Contents of the token are determined to be valid if the contents have not been modified since the token was signed, thus maintaining their integrity. Determining the validity of a signature and contents of a token can be achieved using any number of different techniques and signature verification processes currently known or potentially developed in the future. Accordingly, the specific examples provided herein are for illustrative purposes and should not limit the scope or inhibit broad teachings of this application. 
     In the example of  FIG.  12   , at  1202 , a determination is made as to whether the public key in the token header (e.g., in second segment  814 ) is valid. In this example, a hash of the public key is stored in device  650 . The location of the hashed public key in the device may be identified. If the hashed public key is in an RoT key manifest, this indicates the key was stored by the manufacturer and the token is being used to unlock the device for a use session associated with the manufacturer. If the hashed public key is stored in a key manifest rooted with the key in IFP fuses, this indicates the hashed public key was stored by the OEM and the token is being used to unlock the device for a use session associated with the OEM. 
     To determine whether the public key in the token header is valid, a hash function is applied to the public key (e.g.,  814 ) to create a hash value, which is compared to the hashed public key stored in the device. If the hashed values do not match, however, the public key in the token header is determined to be not valid and therefore the signature in the token header cannot be verified with that public key. In this scenario, the device is not unlocked and, at  1216 , it can continue to boot normally. It should be noted that, although the public key is described as being hashed by a hash function, any suitable derivation function (e.g., hash function, encryption algorithm, other cryptographic or obfuscation function, etc.) can be used to generate a secured value of the public key. This secured value of the public key can be stored in device  650 . The same derivation function can be applied to the un-altered public key in the token header and, at  1202 , the secured values can be compared to determine whether they match or otherwise correspond. 
     If the hashed values match, however, then the public key in the token header is valid and can be used to determine whether the signature is valid at  1204 . Determining whether the signature is valid can include determining whether it is authentic (e.g., created by signing server  610  using a private key). If the signature is determined not to be authentic or if it cannot be confirmed that the signature is authentic, then the signature is not valid. In this scenario, the device is not unlocked and, at  1216 , it can continue to boot normally. 
     If it is verified that the signature was created by the signing server (e.g.,  610 ) using a private key associated with the public key in the token header, then the signature is authentic and valid. Accordingly, if the signature is determined to be valid at  1204 , then the token can be evaluated at  1206  to determine whether the token contents are valid. If the token contents are determined to have been modified since the token was signed, then the token contents are not valid. In this scenario, the device is not unlocked and, at  1216 , it can continue to boot normally. 
     If, at  1206 , a determination is made that the token contents have not been changed, then the token contents are valid and at  1208 , the device ID in the token is evaluated to determine if the token was generated for that device. Depending on the implementation, either a token device ID or an aggregator device ID may be used for this evaluation. If a token device ID is used, then a token device ID from the token properties is compared to a token device ID previously computed and stored on the device (e.g., when the nonce was generated at  910 ), or contemporaneously computed during the verification process using values stored on the device (e.g., aggregator device ID, nonce, keyword). If the token device ID from the token does not match the stored or computed token device ID from the device, then the device is not unlocked and, at  1216 , it can continue to boot normally. If the token device IDs match, however, then flow proceeds at  1210 . 
     In another implementation, aggregator device ID from the token properties is compared to the aggregator device ID obtained from fuses of the device to determine whether they match. If the aggregator device ID from the token and the aggregator device ID from the device does not match, then the device is not unlocked and, at  1216 , it can continue to boot normally. If the aggregator device IDs match, however, then flow proceeds at  1210 . It should be noted that if multiple device IDs (e.g., token device IDs or aggregator device IDs) are specified in the token properties, then those device IDs can be searched to determine whether there is a match to the particular device ID (e.g., token device ID or aggregator device ID) obtained from the device. 
     If a match is found at  1208 , then at  1210 , the previously stored nonce obtained from the device (or from storage accessible to the device) can be compared to the nonce associated with the device ID identified in the token properties to determine whether the nonces match. If the nonces are determined to not match at  1210 , then the device is not unlocked and, at  1216 , it can continue to boot normally. 
     If the nonces are determined to match at  1210 , then at  1212 , an expiration parameter can be evaluated to determine whether the token has expired. The current time obtained from the device (e.g.,  1006 ,  1106 ) can be compared to the timestamp associated with the device ID identified in the token properties. The timestamp associated with the identified device ID in the token properties and the current time obtained from the device can be used to determine the amount of time that has passed since the timestamp was generated for the device. The timestamp can be generated for a device when the token is generated, or when device IDs are obtained from other devices in the group. The resulting amount of time is compared to the expiration parameter (e.g., seconds, minutes, hours, etc.) from the token properties to determine whether the time allowed for the token has expired. For example, in one implementation, if the expiration parameter is less than or equal to the amount of time that was calculated based on the timestamp and the current time, then the token has expired. If it is determined that the token has expired based on the expiration parameter, then the device is not unlocked and, at  1216 , it can continue to boot normally. If it is determined that the token has not expired based on the expiration parameter, then at  1214  the device is unlocked. 
     With reference again to  1204  and  1206 , some specific possible examples are provided related to how a signature and token contents are determined to be valid. In a first example, the public and private keys are an asymmetric key pair. When the signing server  610  receives the token to be signed (e.g.,  918 ), the server applies a one-way hash function (e.g., SHA-3, etc.) to certain contents of the token (e.g.,  840   a  and  840   b ) to generate a hash value. The private key of the signing server can be used by an asymmetric cryptographic algorithm to sign (e.g., encrypt) the hash value to create a signature. For example, a Rivest-Shamir-Adleman (RSA) algorithm can be used, among other examples. The created signature is inserted into the token header, along with the public key of the key pair, before being passed back to the unlock host  630 . 
     After the signed token is injected into the boot partition of a device, the device may be booted. The device obtains the signed token from the boot partition. The public key is read from the token header and used to decrypt the signature to generate a first hash value. The same hash function used by the signing server is applied to certain contents of the signed token (e.g.,  840   a  and  840   b ) to obtain a second hash value. The second hash value is compared to the first hash value derived by decrypting the signature with the public key. If the first and second hash values match, then this validates that the contents of the token have not been changed since the token was signed. The signature is also validated as being authentic because the signature was created with a private key that corresponds to the public key used to decrypt the signature. If the first and second hash values do not match, then this indicates that either the contents have changed since the token was signed or the public key used to decrypt the signature does not correspond to the private key used to create the signature, or both. 
     In another possible example, the private key and public key may be symmetric. In this scenario, after the signed token has been injected into the boot partition of a device, the device may be booted. The device obtains the signed token from the boot partition. A public key is read from the token header and used to decrypt the signature to generate a first hash value. The same hash function used by the signing server is applied to parts of the signed token (e.g.,  840   a  and  840   b ) to obtain a second hash value. The second hash value is compared to the first hash value derived by decrypting the signature with the public key. If the first and second hash values match, then this validates that the contents of the token have not been changed since the token was signed. If the first and second hash values are different, then the contents of the token have changed since the token was signed. To evaluate the authenticity of the signature, the second hash value is signed (e.g., encrypted) with the public key to create a second signature. The second signature is compared with the signature in the token header. If the signatures match, then the signature is also validated as being authentic. If the signatures do not match, then the signature in the header is determined to not be valid. 
     In an alternative embodiment, secure unlock system  600  may be combined with secure unlock system  100  to provide a particular embodiment that enables a manufacturer to control unlocking privileged features with a primary mechanism of secure fuse passwords, and a backup mechanism of using signed tokens when a customer cannot access the manufacturer&#39;s key store containing passwords and unique identifiers. For example, a device may be configured with a hashed password and unique identifier in its fuse bank during the manufacturing process, as previously described herein with reference to  FIGS.  1 - 5   . The password enables particular privileged features to be unlocked when a user accesses the device with unlock host (e.g.,  130 ), establishes a network connection to the manufacturer&#39;s database with a key store (e.g.,  110 ), and obtains the appropriate password to unlock the device, as previously described herein. In some scenarios, however, a customer such as an OEM may not be able to successfully access a manufacturer&#39;s database (e.g., database is down, network connection is unavailable, customer&#39;s network is down, etc.). In these scenarios, the customer may cease the particular desired activity, such as debugging, testing, validating, provisioning, prototyping, or analyzing the device, until a network session can be established or restored. 
     In an alternative embodiment, however, the device could also be configured with a signed token containing unlock data in its token payload, as previously described herein and particularly with reference to  FIG.  9   . The token may be signed by the manufacturer and the unlock data could include unlock data (e.g., configuration information) to unlock privileged features that the customer is authorized to access during a use session. When the password authentication fails, such as when a connection cannot be established to the manufacturer&#39;s database, for example, a security engine in the device may begin to verify the signed token, as previously described herein. Accordingly, the device can be unlocked for the customer according to the unlock data in the token payload. In one example, the unlock data may enable the unlocking of a limited set of privileged features, whereas the fuse password may enable a more expansive set of privileged features to be unlocked. In other embodiments, they may enable the same set of privileged features. 
       FIGS.  13 - 21    detail exemplary architectures and systems to implement embodiments of the above (such as devices  150 ,  650 , unlock hosts  130 ,  630 , fusing station  120 , database infrastructure  110 , signing server  610 , etc.). In some embodiments, one or more hardware components and/or instructions described above are emulated as detailed below, or implemented as software modules. Other computer architecture designs known in the art for processors, mobile devices, computing systems, and components thereof may also (or alternatively) be used. Generally, suitable computer architectures for embodiments disclosed herein can include, but are not limited to, configurations illustrated in  FIGS.  13 - 21   . 
     Embodiments of the instruction(s) detailed above may be embodied in a “generic vector friendly instruction format.” In other embodiments, such a format is not utilized and another instruction format is used, however, the description below of the writemask registers, various data transformations (swizzle, broadcast, etc.), addressing, etc. is generally applicable to the description of the embodiments of the instruction(s) above. Additionally, exemplary systems, architectures, and pipelines are detailed below. Embodiments of the instruction(s) above may be executed on such systems, architectures, and pipelines, but are not limited to those detailed. 
     An instruction set may include one or more instruction formats. A given instruction format may define various fields (e.g., number of bits, location of bits) to specify, among other things, the operation to be performed (e.g., opcode) and the operand(s) on which that operation is to be performed and/or other data field(s) (e.g., mask). Some instruction formats are further broken down though the definition of instruction templates (or subformats). For example, the instruction templates of a given instruction format may be defined to have different subsets of the instruction format&#39;s fields (the included fields are typically in the same order, but at least some have different bit positions because there are less fields included) and/or defined to have a given field interpreted differently. Thus, each instruction of an ISA is expressed using a given instruction format (and, if defined, in a given one of the instruction templates of that instruction format) and includes fields for specifying the operation and the operands. For example, an exemplary ADD instruction has a specific opcode and an instruction format that includes an opcode field to specify that opcode and operand fields to select operands (source1/destination and source2); and an occurrence of this ADD instruction in an instruction stream will have specific contents in the operand fields that select specific operands. A set of SIMD extensions referred to as the Advanced Vector Extensions (AVX) (AVX1 and AVX2) and using the Vector Extensions (VEX) coding scheme has been released and/or published (e.g., see Intel® 64 and IA-32 Architectures Software Developer&#39;s Manual, September 2014; and see Intel® Advanced Vector Extensions Programming Reference, October 2014). 
       FIG.  13    is a block diagram of a register architecture  1300  according to at least one embodiment of the present disclosure. In the embodiment illustrated, there are 32 vector registers  1310  that are 512 bits wide; these registers are referenced as zmm0 through zmm31. The lower order 256 bits of the lower 16 zmm registers are overlaid on registers ymm0-15. The lower order 128 bits of the lower 16 zmm registers (the lower order 128 bits of the ymm registers) are overlaid on registers xmm0-15. 
     In other words, a vector length field selects between a maximum length and one or more other shorter lengths, where each such shorter length is half the length of the preceding length; and instructions templates without the vector length field operate on the maximum vector length. Further, in one embodiment, class B instruction templates of a specific vector friendly instruction format operate on packed or scalar single/double-precision floating point data and packed or scalar integer data. Scalar operations are operations performed on the lowest order data element position in an zmm/ymm/xmm register; the higher order data element positions are either left the same as they were prior to the instruction or zeroed depending on the embodiment. 
     Write mask registers  1315 —in the embodiment illustrated, there are 8 write mask registers (k0 through k7), each 64 bits in size. In an alternate embodiment, the write mask registers  1315  are 16 bits in size. As previously described, in one embodiment, the vector mask register k0 cannot be used as a write mask; when the encoding that would normally indicate k0 is used for a write mask, it selects a hardwired write mask of 0xFFFF, effectively disabling write masking for that instruction. 
     General-purpose registers  1325 —in the embodiment illustrated, there are sixteen 64-bit general-purpose registers that are used along with the existing x86 addressing modes to address memory operands. These registers are referenced by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15. 
     Scalar floating point stack register file (x87 stack)  1345 , on which is aliased the MMX packed integer flat register file  1350 —in the embodiment illustrated, the x87 stack is an eight-element stack used to perform scalar floating-point operations on 32/64/80-bit floating point data using the x87 instruction set extension; while the MMX registers are used to perform operations on 64-bit packed integer data, as well as to hold operands for some operations performed between the MMX and XMM registers. 
     Alternative embodiments of the present disclosure may use wider or narrower registers. Additionally, alternative embodiments of the present disclosure may use more, less, or different register files and registers. 
     Processor cores may be implemented in different ways, for different purposes, and in different processors. For instance, implementations of such cores may include: 1) a general purpose in-order core intended for general-purpose computing; 2) a high performance general purpose out-of-order core intended for general-purpose computing; 3) a special purpose core intended primarily for graphics and/or scientific (throughput) computing. Implementations of different processors may include: 1) a CPU including one or more general purpose in-order cores intended for general-purpose computing and/or one or more general purpose out-of-order cores intended for general-purpose computing; and 2) a coprocessor including one or more special purpose cores intended primarily for graphics and/or scientific (throughput). Such different processors lead to different computer system architectures, which may include: 1) the coprocessor on a separate chip from the CPU; 2) the coprocessor on a separate die in the same package as a CPU; 3) the coprocessor on the same die as a CPU (in which case, such a coprocessor is sometimes referred to as special purpose logic, such as integrated graphics and/or scientific (throughput) logic, or as special purpose cores); and 4) a system on a chip that may include on the same die the described CPU (sometimes referred to as the application core(s) or application processor(s)), the above described coprocessor, and additional functionality. Exemplary core architectures are described next, followed by descriptions of exemplary processors and computer architectures. 
       FIG.  14 A  is a block diagram illustrating both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue/execution pipeline according to one or more embodiments of this disclosure.  FIG.  14 B  is a block diagram illustrating both an exemplary embodiment of an in-order architecture core and an exemplary register renaming, out-of-order issue/execution architecture core to be included in a processor according to one or more embodiments of this disclosure. The solid lined boxes in  FIGS.  14 A-B  illustrate the in-order pipeline and in-order core, while the optional addition of the dashed lined boxes illustrates the register renaming, out-of-order issue/execution pipeline and core. Given that the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described. 
     In  FIG.  14 A , a processor pipeline  1400  includes a fetch stage  1402 , a length decode stage  1404 , a decode stage  1406 , an allocation stage  1408 , a renaming stage  1410 , a scheduling (also known as a dispatch or issue) stage  1412 , a register read/memory read stage  1414 , an execute stage  1416 , a write back/memory write stage  1418 , an exception handling stage  1422 , and a commit stage  1424 . 
       FIG.  14 B  shows processor core  1490  including a front end unit  1430  coupled to an execution engine unit  1450 , and both are coupled to a memory unit  1470 . The core  1490  may be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As yet another option, the core  1490  may be a special-purpose core, such as, for example, a network or communication core, compression engine, coprocessor core, general purpose computing graphics processing unit (GPGPU) core, graphics core, or the like. 
     The front end unit  1430  includes a branch prediction unit  1432  coupled to an instruction cache unit  1434 , which is coupled to an instruction translation lookaside buffer (TLB)  1436 , which is coupled to an instruction fetch unit  1438 , which is coupled to a decode unit  1440 . The decode unit  1440  (or decoder) may decode instructions, and generate as an output one or more micro-operations, micro-code entry points, microinstructions, other instructions, or other control signals, which are decoded from, or which otherwise reflect, or are derived from, the original instructions. The decode unit  1440  may be implemented using various different mechanisms. Examples of suitable mechanisms include, but are not limited to, look-up tables, hardware implementations, programmable logic arrays (PLAs), microcode read only memories (ROMs), etc. In one embodiment, the core  1490  includes a microcode ROM or other medium that stores microcode for certain macroinstructions (e.g., in decode unit  1440  or otherwise within the front end unit  1430 ). The decode unit  1440  is coupled to a rename/allocator unit  1452  in the execution engine unit  1450 . 
     The execution engine unit  1450  includes the rename/allocator unit  1452  coupled to a retirement unit  1454  and a set of one or more scheduler unit(s)  1456 . The scheduler unit(s)  1456  represents any number of different schedulers, including reservations stations, central instruction window, etc. The scheduler unit(s)  1456  is coupled to the physical register file(s) unit(s)  1458 . Each of the physical register file(s) units  1458  represents one or more physical register files, different ones of which store one or more different data types, such as scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point, status (e.g., an instruction pointer that is the address of the next instruction to be executed), etc. In one embodiment, the physical register file(s) unit  1458  comprises a vector registers unit, a write mask registers unit, and a scalar registers unit. These register units may provide architectural vector registers, vector mask registers, and general purpose registers. The physical register file(s) unit(s)  1458  is overlapped by the retirement unit  1454  to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using a reorder buffer(s) and a retirement register file(s); using a future file(s), a history buffer(s), and a retirement register file(s); using register maps and a pool of registers; etc.). The retirement unit  1454  and the physical register file(s) unit(s)  1458  are coupled to the execution cluster(s)  1460 . The execution cluster(s)  1460  includes a set of one or more execution units  1462  and a set of one or more memory access units  1464 . The execution units  1462  may perform various operations (e.g., shifts, addition, subtraction, multiplication) and on various types of data (e.g., scalar floating point, packed integer, packed floating point, vector integer, vector floating point). While some embodiments may include a number of execution units dedicated to specific functions or sets of functions, other embodiments may include only one execution unit or multiple execution units that all perform all functions. 
     The scheduler unit(s)  1456 , physical register file(s) unit(s)  1458 , and execution cluster(s)  1460  are shown as being possibly plural because certain embodiments create separate pipelines for certain types of data/operations (e.g., a scalar integer pipeline, a scalar floating point/packed integer/packed floating point/vector integer/vector floating point pipeline, and/or a memory access pipeline that each have their own scheduler unit, physical register file(s) unit, and/or execution cluster—and in the case of a separate memory access pipeline, certain embodiments are implemented in which only the execution cluster of this pipeline has the memory access unit(s)  1464 ). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue/execution and the rest in-order. 
     The set of memory access units  1464  is coupled to the memory unit  1470 , which includes a data TLB unit  1472  coupled to a data cache unit  1474  coupled to a level 2 (L2) cache unit  1476 . In one exemplary embodiment, the memory access units  1464  may include a load unit, a store address unit, and a store data unit, each of which is coupled to the data TLB unit  1472  in the memory unit  1470 . The instruction cache unit  1434  is further coupled to a level 2 (L2) cache unit  1476  in the memory unit  1470 . The L2 cache unit  1476  is coupled to one or more other levels of cache and eventually to a main memory. 
     By way of example, the exemplary register renaming, out-of-order issue/execution core architecture may implement the pipeline  1400  as follows: 1) the instruction fetch  1438  performs the fetch and length decode stages  1402  and  1404 ; 2) the decode unit  1440  performs the decode stage  1406 ; 3) the rename/allocator unit  1452  performs the allocation stage  1408  and renaming stage  1410 ; 4) the scheduler unit(s)  1456  performs the scheduling stage  1412 ; 5) the physical register file(s) unit(s)  1458  and the memory unit  1470  perform the register read/memory read stage  1414 ; the execution cluster  1460  perform the execute stage  1416 ; 6) the memory unit  1470  and the physical register file(s) unit(s)  1458  perform the write back/memory write stage  1418 ; 7) various units may be involved in the exception handling stage  1422 ; and 8) the retirement unit  1454  and the physical register file(s) unit(s)  1458  perform the commit stage  1424 . 
     The core  1490  may support one or more instructions sets (e.g., the x86 instruction set (with some extensions that have been added with newer versions); the MIPS instruction set of MIPS Technologies of Sunnyvale, Calif.; the ARM instruction set (with optional additional extensions such as NEON) of ARM Holdings of Sunnyvale, Calif.), including the instruction(s) described herein. In one embodiment, the core  1490  includes logic to support a packed data instruction set extension (e.g., AVX1, AVX2), thereby allowing the operations used by many multimedia applications to be performed using packed data. 
     It should be understood that the core may support multithreading (executing two or more parallel sets of operations or threads), and may do so in a variety of ways including time sliced multithreading, simultaneous multithreading (where a single physical core provides a logical core for each of the threads that physical core is simultaneously multithreading), or a combination thereof (e.g., time sliced fetching and decoding and simultaneous multithreading thereafter such as in the Intel® Hyperthreading technology). 
     While register renaming is described in the context of out-of-order execution, it should be understood that register renaming may be used in an in-order architecture. While the illustrated embodiment of the processor also includes separate instruction and data cache units  1434 / 1474  and a shared L2 cache unit  1476 , alternative embodiments may have a single internal cache for both instructions and data, such as, for example, a Level 1 (L1) internal cache, or multiple levels of internal cache. In some embodiments, the system may include a combination of an internal cache and an external cache that is external to the core and/or the processor. Alternatively, all of the cache may be external to the core and/or the processor. 
       FIGS.  15 A- 15 B  illustrate a block diagram of a more specific exemplary in-order core architecture, which core would be one of several logic blocks (including other cores of the same type and/or different types) in a chip. The logic blocks communicate through a high-bandwidth interconnect network (e.g., a ring network) with some fixed function logic, memory I/O interfaces, and other necessary I/O logic, depending on the application. 
       FIG.  15 A  is a block diagram of a single processor core, along with its connection to the on-die interconnect network  1502  and with its local subset of the Level 2 (L2) cache  1504 , according to one or more embodiments of this disclosure. In one embodiment, an instruction decoder  1500  supports the x86 instruction set with a packed data instruction set extension. An L1 cache  1506  allows low-latency accesses to cache memory into the scalar and vector units. While in one embodiment (to simplify the design), a scalar unit  1508  and a vector unit  1510  use separate register sets (respectively, scalar registers  1512  and vector registers  1514 ) and data transferred between them is written to memory and then read back in from a level 1 (L1) cache  1506 , alternative embodiments of the present disclosure may use a different approach (e.g., use a single register set or include a communication path that allows data to be transferred between the two register files without being written and read back). 
     The local subset of the L2 cache  1504  is part of a global L2 cache that is divided into separate local subsets, one per processor core. Each processor core has a direct access path to its own local subset of the L2 cache  1504 . Data read by a processor core is stored in its L2 cache subset  1504  and can be accessed quickly, in parallel with other processor cores accessing their own local L2 cache subsets. Data written by a processor core is stored in its own L2 cache subset  1504  and is flushed from other subsets, if necessary. The ring network  1502  ensures coherency for shared data. The ring network is bi-directional to allow agents such as processor cores, L2 caches and other logic blocks to communicate with each other within the chip. Each ring data-path is 1012-bits wide per direction. 
       FIG.  15 B  is an expanded view of part of the processor core in  FIG.  15 A  according to one or more embodiments this disclosure.  FIG.  15 B  includes an L1 data cache  1506 A, part of the L2 cache  1504 , as well as more detail regarding the vector unit  1510  and the vector registers  1514 . Specifically, the vector unit  1510  is a 16-wide vector processing unit (VPU) (see the 16-wide ALU  1528 ), which executes one or more of integer, single-precision float, and double-precision float instructions. The VPU supports swizzling the register inputs with swizzle unit  1520 , numeric conversion with numeric convert units  1522 A-B, and replication with replication unit  1524  on the memory input. Write mask registers  1526  allow predicating resulting vector writes. 
       FIG.  16    is a block diagram of a processor  1600  that may have more than one core, may have an integrated memory controller, and may have integrated graphics according to one or more embodiment of this disclosure. The solid lined boxes in  FIG.  16    illustrate a processor  1600  with a single core  1602 A, a system agent unit  1610 , a set of one or more bus controller units  1616 , while the optional addition of the dashed lined boxes illustrates an alternative processor  1600  with multiple cores  1602 A-N, a set of one or more integrated memory controller unit(s)  1614  in the system agent unit  1610 , and special purpose logic  1608 . 
     Thus, different implementations of the processor  1600  may include: 1) a CPU with the special purpose logic  1608  being integrated graphics and/or scientific (throughput) logic (which may include one or more cores), and the cores  1602 A-N being one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, a combination of the two); 2) a coprocessor with the cores  1602 A-N being a large number of special purpose cores intended primarily for graphics and/or scientific (throughput); and 3) a coprocessor with the cores  1602 A-N being a large number of general purpose in-order cores. Thus, the processor  1600  may be a general-purpose processor, coprocessor or special-purpose processor, such as, for example, a network or communication processor, compression engine, graphics processor, GPGPU (general purpose graphics processing unit), a high-throughput many integrated core (MIC) coprocessor (including 30 or more cores), embedded processor, or the like. The processor may be implemented on one or more chips. The processor  1600  may be a part of and/or may be implemented on one or more substrates using any of a number of process technologies, such as, for example, BiCMOS, CMOS, or NMOS. 
     The memory hierarchy includes one or more levels of cache within the cores, a set or one or more shared cache units  1606 , and external memory (not shown) coupled to the set of integrated memory controller units  1614 . The set of shared cache units  1606  may include one or more mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, a last level cache (LLC), and/or combinations thereof. While in one embodiment a ring based interconnect unit  1612  interconnects the special purpose logic  1608  (e.g., integrated graphics logic), the set of shared cache units  1606 , and the system agent unit  1610 /integrated memory controller unit(s)  1614 , alternative embodiments may use any number of well-known techniques for interconnecting such units. In one embodiment, coherency is maintained between one or more cache units  1606  and cores  1602 A-N. 
     In some embodiments, one or more of the cores  1602 A-N are capable of multi-threading. The system agent  1610  includes those components coordinating and operating cores  1602 A-N. The system agent unit  1610  may include for example a power control unit (PCU) and a display unit. The PCU may be or include logic and components needed for regulating the power state of the cores  1602 A-N and the integrated graphics logic  1608 . The display unit is for driving one or more externally connected displays. 
     The cores  1602 A-N may be homogenous or heterogeneous in terms of architecture instruction set; that is, two or more of the cores  1602 A-N may be capable of executing the same instruction set, while others may be capable of executing only a subset of that instruction set or a different instruction set. 
       FIGS.  17 - 20    are block diagrams of exemplary computer architectures. Other system designs and configurations known in the arts for laptops, desktops, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, micro controllers, cell phones, portable media players, hand held devices, and various other electronic devices, are also suitable. In general, a huge variety of systems or electronic devices capable of incorporating a processor and/or other execution logic as disclosed herein are generally suitable. 
     Referring now to  FIG.  17   , shown is a block diagram of a system  1700  in accordance with at least one embodiment of the present disclosure. The system  1700  may include one or more processors  1710 ,  1715 , which are coupled to a controller hub  1720 . In one embodiment the controller hub  1720  includes a graphics memory controller hub (GMCH)  1790  and an Input/Output Hub (IOH)  1750  (which may be on separate chips); the GMCH  1790  includes memory and graphics controllers to which are coupled memory  1740  and a coprocessor  1745 ; the IOH  1750  couples input/output (I/O) devices  1760  to the GMCH  1790 . Alternatively, one or both of the memory and graphics controllers are integrated within the processor (as described herein), the memory  1740  and the coprocessor  1745  are coupled directly to the processor  1710 , and the controller hub  1720  in a single chip with the IOH  1750 . 
     The optional nature of additional processors  1715  is denoted in  FIG.  17    with broken lines. Each processor  1710 ,  1715  may include one or more of the processing cores described herein and may be some version of the processor  1600 . 
     The memory  1740  may be, for example, dynamic random access memory (DRAM), phase change memory (PCM), or a combination of the two. For at least one embodiment, the controller hub  1720  communicates with the processor(s)  1710 ,  1715  via a multi-drop bus, such as a frontside bus (FSB), point-to-point interface such as QuickPath Interconnect (QPI), or similar connection  1795 . 
     In one embodiment, the coprocessor  1745  is a special-purpose processor, such as, for example, a high-throughput MIC processor, a network or communication processor, compression engine, graphics processor, GPGPU, embedded processor, or the like. In one embodiment, controller hub  1720  may include an integrated graphics accelerator. 
     There can be a variety of differences between the physical resources  1710 ,  1715  in terms of a spectrum of metrics of merit including architectural, microarchitectural, thermal, power consumption characteristics, and the like. 
     In one embodiment, the processor  1710  executes instructions that control data processing operations of a general type. Embedded within the instructions may be coprocessor instructions. The processor  1710  recognizes these coprocessor instructions as being of a type that should be executed by the attached coprocessor  1745 . Accordingly, the processor  1710  issues these coprocessor instructions (or control signals representing coprocessor instructions) on a coprocessor bus or other interconnect, to coprocessor  1745 . Coprocessor(s)  1745  accept and execute the received coprocessor instructions. 
     Referring now to  FIG.  18   , shown is a block diagram of a first more specific exemplary system  1800  in accordance with one or more embodiments of the present disclosure. As shown in  FIG.  18   , multiprocessor system  1800  is a point-to-point interconnect system, and includes a first processor  1870  and a second processor  1880  coupled via a point-to-point interconnect  1850 . Each of processors  1870  and  1880  may be some version of the processor  1600 . In at least one embodiment of this disclosure, processors  1870  and  1880  are respectively processors  1710  and  1715 , while coprocessor  1838  is coprocessor  1745 . In another embodiment, processors  1870  and  1880  are respectively processor  1710  coprocessor  1745 . 
     Processors  1870  and  1880  are shown including integrated memory controller (IMC) units  1872  and  1882 , respectively. Processor  1870  also includes as part of its bus controller units point-to-point (P-P) interfaces  1876  and  1878 ; similarly, second processor  1880  includes P-P interfaces  1886  and  1888 . Processors  1870 ,  1880  may exchange information via a point-to-point (P-P) interface  1850  using P-P interface circuits  1878 ,  1888 . As shown in  FIG.  18   , IMCs  1872  and  1882  couple the processors to respective memories, namely a memory  1832  and a memory  1834 , which may be portions of main memory locally attached to the respective processors. 
     Processors  1870 ,  1880  may each exchange information with a chipset  1890  via individual P-P interfaces  1852 ,  1854  using point to point interface circuits  1876 ,  1894 ,  1886 ,  1898 . Chipset  1890  may optionally exchange information with the coprocessor  1838  via a high-performance interface  1839 . In one embodiment, the coprocessor  1838  is a special-purpose processor, such as, for example, a high-throughput MIC processor, a network or communication processor, compression engine, graphics processor, GPGPU, embedded processor, or the like. 
     A shared cache (not shown) may be included in either processor or outside of both processors, yet connected with the processors via P-P interconnect, such that either or both processors&#39; local cache information may be stored in the shared cache if a processor is placed into a low power mode. 
     Chipset  1890  may be coupled to a first bus  1810  via an interface  1896 . In one embodiment, first bus  1810  may be a Peripheral Component Interconnect (PCI) bus, or a bus such as a PCI Express bus or another third generation I/O interconnect bus, although the scope of the present disclosure is not so limited. 
     As shown in  FIG.  18   , various I/O devices  1814  may be coupled to first bus  1810 , along with a bus bridge  1818  which couples first bus  1810  to a second bus  1820 . In one embodiment, one or more additional processor(s)  1815 , such as coprocessors, high-throughput MIC processors, GPGPU&#39;s, accelerators (such as, e.g., graphics accelerators or digital signal processing (DSP) units), field programmable gate arrays, or any other processor, are coupled to first bus  1810 . In one embodiment, second bus  1820  may be a low pin count (LPC) bus. Various devices may be coupled to a second bus  1820  including, for example, a keyboard and/or mouse  1822 , communication devices  1826  and a storage unit  1828  such as a disk drive or other mass storage device which may include instructions/code and data  1830 , in one embodiment. Further, an audio I/O  1824  may be coupled to the second bus  1820 . Note that other architectures are possible. For example, instead of the point-to-point architecture of  FIG.  18   , a system may implement a multi-drop bus or other such architecture. 
     Referring now to  FIG.  19   , shown is a block diagram of a second more specific exemplary system  1900  in accordance with at least one embodiment of the present disclosure. Like elements in  FIGS.  18  and  19    bear like reference numerals, and certain aspects of  FIG.  18    have been omitted from  FIG.  19    in order to avoid obscuring other aspects of  FIG.  19   . 
       FIG.  19    illustrates that the processors  1870 ,  1880  may include integrated memory and I/O control logic (“CL”)  1872  and  1882 , respectively. Thus, the CL  1872 ,  1882  include integrated memory controller units and include I/O control logic.  FIG.  19    illustrates that not only are the memories  1832 ,  1834  coupled to the CL  1872 ,  1882 , but also that I/O devices  1814  are also coupled to the control logic  1872 ,  1882 . Legacy I/O devices  1915  are coupled to the chipset  1890 . 
     Referring now to  FIG.  20   , shown is a block diagram of a SoC  2000  in accordance with at least one embodiment of the present disclosure. Similar elements in  FIG.  16    bear like reference numerals. Also, dashed lined boxes are optional features on more advanced SoCs. In  FIG.  20   , an interconnect unit(s)  2002  is coupled to: an application processor  2010  which includes a set of one or more cores  1602 A-N and shared cache unit(s)  1606 ; a system agent unit  1610 ; a bus controller unit(s)  1616 ; an integrated memory controller unit(s)  1614 ; a set or one or more coprocessors  2020  which may include integrated graphics logic, an image processor, an audio processor, and a video processor; an static random access memory (SRAM) unit  2030 ; a direct memory access (DMA) unit  2032 ; and a display unit  2040  for coupling to one or more external displays. In one embodiment, the coprocessor(s)  2020  includes a special-purpose processor, such as, for example, a network or communication processor, compression engine, GPGPU, a high-throughput MIC processor, embedded processor, or the like. 
     Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of such implementation approaches. Embodiments of this disclosure may be implemented as computer programs or program code executing on programmable systems comprising at least one processor, a storage system (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. 
     Program code, such as code  1830  illustrated in  FIG.  18   , may be applied to input instructions to perform the functions described herein and generate output information. The output information may be applied to one or more output devices, in known fashion. For purposes of this application, a processing system includes any system that has a processor, such as, for example; a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor, among other examples. 
     The program code may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. The program code may also be implemented in assembly or machine language, if desired. In fact, the mechanisms described herein are not limited in scope to any particular programming language. In any case, the language may be a compiled or interpreted language. 
     One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium which represents various logic within the processor, which when read by a machine causes the machine to fabricate logic to perform the techniques described herein. Such representations, known as “IP cores” may be stored on a tangible, machine readable medium and supplied to various customers or manufacturing facilities to load into the fabrication machines that actually make the logic or processor. 
     Such machine-readable storage media may include, without limitation, non-transitory, tangible arrangements of articles manufactured or formed by a machine or device, including storage media such as hard disks, any other type of disk including floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk rewritable&#39;s (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMS) such as dynamic random access memories (DRAMs), static random access memories (SRAMs), erasable programmable read-only memories (EPROMs), flash memories, electrically erasable programmable read-only memories (EEPROMs), phase change memory (PCM), magnetic or optical cards, or any other type of media suitable for storing electronic instructions. 
     Accordingly, embodiments of this disclosure also include non-transitory, tangible machine-readable media containing instructions or containing design data, such as Hardware Description Language (HDL), which defines structures, circuits, apparatuses, processors and/or system features described herein. Such embodiments may also be referred to as program products. 
     In some cases, an instruction converter may be used to convert an instruction from a source instruction set to a target instruction set. For example, the instruction converter may translate (e.g., using static binary translation, dynamic binary translation including dynamic compilation), morph, emulate, or otherwise convert an instruction to one or more other instructions to be processed by the core. The instruction converter may be implemented in software, hardware, firmware, or a combination thereof. The instruction converter may be on processor, off processor, or part on and part off processor. 
       FIG.  21    is a block diagram contrasting the use of a software instruction converter to convert binary instructions in a source instruction set to binary instructions in a target instruction set according to embodiments of this disclosure. In the illustrated embodiment, the instruction converter is a software instruction converter, although alternatively the instruction converter may be implemented in software, firmware, hardware, or various combinations thereof.  FIG.  21    shows a program in a high level language  2102  may be compiled using an x86 compiler  2104  to generate x86 binary code  2106  that may be natively executed by a processor with at least one x86 instruction set core  2116 . The processor with at least one x86 instruction set core  2116  represents any processor that can perform substantially the same functions as an Intel processor with at least one x86 instruction set core by compatibly executing or otherwise processing (1) a substantial portion of the instruction set of the Intel x86 instruction set core or (2) object code versions of applications or other software targeted to run on an Intel processor with at least one x86 instruction set core, in order to achieve substantially the same result as an Intel processor with at least one x86 instruction set core. The x86 compiler  2104  represents a compiler that is operable to generate x86 binary code  2106  (e.g., object code) that can, with or without additional linkage processing, be executed on the processor with at least one x86 instruction set core  2116 . Similarly,  FIG.  21    shows the program in the high level language  2102  may be compiled using an alternative instruction set compiler  2108  to generate alternative instruction set binary code  2110  that may be natively executed by a processor without at least one x86 instruction set core  2114  (e.g., a processor with cores that execute the MIPS instruction set of MIPS Technologies of Sunnyvale, Calif. and/or that execute the ARM instruction set of ARM Holdings of Sunnyvale, Calif.). The instruction converter  2112  is used to convert the x86 binary code  2106  into code that may be natively executed by the processor without an x86 instruction set core  2114 . This converted code is not likely to be the same as the alternative instruction set binary code  2110  because an instruction converter capable of this is difficult to make; however, the converted code will accomplish the general operation and be made up of instructions from the alternative instruction set. Thus, the instruction converter  2112  represents software, firmware, hardware, or a combination thereof that, through emulation, simulation or any other process, allows a processor or other electronic device that does not have an x86 instruction set processor or core to execute the x86 binary code  2106 . 
     Elements of  FIG.  1   , such as database infrastructure  110 , fusing station  120 , unlock host  130 , and device  150 , and elements of  FIG.  6   , such as signing server  610 , unlock host  630 , and device  630  may include software to achieve (or to foster) the device unlock functions, as outlined herein. Note that in one example, each of these elements can have an internal structure (e.g., processor  119 ,  129 ,  139 ,  159 ,  619 ,  639 ,  659  memory element  117 ,  127 ,  137 ,  157 ,  617 ,  637 ,  657 , etc.) to facilitate some of the operations described herein. In other embodiments, these device unlock functions may be executed externally to these elements, or included in some other network element to achieve this intended functionality. Alternatively, network elements may include this software (or reciprocating software) that can coordinate with other network elements in order to achieve the operations, as outlined herein. In still other embodiments, one or several devices, hosts, or systems may include any suitable algorithms, hardware, software, firmware, components, modules, interfaces, or objects that facilitate the operations thereof. 
     Note that with the numerous examples provided herein, interaction may be described in terms of two, three, four, or more network elements, hosts, devices, computing systems, modules, and/or other components. However, this has been done for purposes of clarity and example only. It should be appreciated that the system can be consolidated or divided (e.g., segmented, partitioned, separated, etc.) in any suitable manner. Along similar design alternatives, any of the illustrated modules, nodes, elements, hosts, devices, systems, and other components of  FIG.  1    may be combined in various possible configurations, all of which are clearly within the broad scope of this Specification. It should be appreciated that the systems of  FIGS.  1  and  6    (and their teachings) are readily scalable and can accommodate a large number of components, as well as more complicated/sophisticated arrangements and configurations. Accordingly, the examples provided should not limit the scope or inhibit the broad teachings of the systems as potentially applied to a myriad of other architectures. 
     It is also important to note that the operations described with reference to the preceding FIGURES illustrate only some of the possible scenarios that may be executed by, or within, the systems (e.g.,  100 ,  600 ). Some of these operations may be deleted or removed where appropriate, or these operations may be modified or changed considerably without departing from the scope of the discussed concepts. In addition, the timing of these operations may be altered considerably and still achieve the results taught in this disclosure. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve the desired results. In certain implementations, multitasking and parallel processing may be advantageous. The preceding operational flows have been offered for purposes of example and discussion. Substantial flexibility is provided by the system in that any suitable arrangements, chronologies, configurations, and timing mechanisms may be provided without departing from the teachings of the discussed concepts. 
     As used herein, unless expressly stated to the contrary, use of the phrase ‘at least one of’ refers to any combination of the named items, elements, conditions, or activities. For example, ‘at least one of X, Y, and Z’ is intended to mean any of the following: 1) at least one X, but not Y and not Z; 2) at least one Y, but not X and not Z; 3) at least one Z, but not X and not Y; 4) at least one X and at least one Y, but not Z; 5) at least one X and at least one Z, but not Y; 6) at least one Y and at least one Z, but not X; or 7) at least one X, at least one Y, and at least one Z. Additionally, unless expressly stated to the contrary, the numbering adjectives ‘first’, ‘second’, ‘third’, etc., are intended to distinguish the particular terms (e.g., element, condition, module, activity, operation, claim element, etc.) they precede, but are not intended to indicate any type of order, rank, importance, temporal sequence, or hierarchy of the modified term. For example, ‘first X’ and ‘second X’ are intended to designate two separate X elements that are not necessarily limited by any order, rank, importance, temporal sequence, or hierarchy of the two elements. Also, references in the specification to “one embodiment,” “an embodiment,” “some embodiments,” etc., indicate that the embodiment(s) described may include a particular feature, structure, or characteristic, but every embodiment may or may not necessarily include that particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. 
     While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any embodiments or of what may be claimed, but rather as descriptions of features specific to particular embodiments of the subject matter disclosed herein. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. For example, secure unlock system  100  and secure unlock system  600  may be combined in an alternative embodiment as previously described herein, and in other ways that may not be specifically outlined herein. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub combination or variation of a sub combination. Numerous other changes, substitutions, variations, alterations, and modifications may be ascertained to one skilled in the art and it is intended that the present disclosure encompass all such changes, substitutions, variations, alterations, and modifications as falling within the scope of the appended claims. 
     OTHER NOTES AND EXAMPLES 
     The following examples pertain to embodiments in accordance with this specification. Example T1 provides an apparatus, a system, one or more machine readable mediums, a method, and/or hardware-, firmware-, and/or software-based logic for unlocking at least a portion of a device, where the Example of T1 includes a fuse controller for storing a unique identifier of the device and a first secured value computed from a first password associated with the unique identifier; an aggregator coupled to the fuse controller to: receive the unique identifier and the first secured value from the fuse controller; send the unique identifier to an unlock host; receive a second password from the unlock host; compute a second secured value of the second password using a security function; and unlock one or more privileged features on the device based on the first secured value corresponding to the second secured value. 
     In Example T2, the subject matter of Example T1 can optionally include the first secured value corresponds to the second secured value if the first password is equivalent to the second password. 
     In Example T3, the subject matter of any one of Examples T1-T2 can optionally include the first password is randomly generated for the device and stored in a database. 
     In Example T4, the subject matter of any one of Examples T1-T3 can optionally include the aggregator is further to receive a request from the unlock host to unlock the device, where the unique identifier is sent to the unlock host in response to receiving the request at the aggregator. 
     In Example T5, the subject matter of Example T4 can optionally include the aggregator is further to block the request to unlock the device, where the request is blocked based on the first secured value not corresponding to the second secured value. 
     In Example T6, the subject matter of any one of Examples T1-T5 can optionally include the security function is equivalent to another security function used by a fusing device to compute the first secured value of the first password. 
     In Example T7, the subject matter of Example T6 can optionally include the security function is Secure Hash Algorithm  3  (SHA-3). 
     In Example T8, the subject matter of any one of Examples T1-T7 can optionally include that the first password is associated with an unlock mode of a plurality of unlock modes for the device, where the unlock mode specifies the one or more privileged features on the device to be unlocked. 
     In Example T9, the subject matter of any one of Examples T1-T8 can optionally include a fusing device to: receive the first password and the unique identifier from a database in which the first password and the unique identifier are stored; compute the first secured value of the first password using the security function; and store the first secured value and the unique identifier in the fuse controller of the device. 
     In Example T10, the subject matter of any one of Examples T1-T9 can optionally include an unlock host to: authenticate one or more credentials of a user; request the unique identifier from the aggregator based, at least in part, on the one or more credentials being authenticated; receive the unique identifier from the aggregator; query a database based on the unique identifier; receive the second password from the database; send the second password to the aggregator; and receive an indication that the one or more privileged features of the device are unlocked based on the aggregator determining the first secured value corresponds to the second secured value. 
     The following examples pertain to embodiments in accordance with this specification. Example X1 provides an apparatus, a system, one or more machine readable mediums, a method, and/or hardware-, firmware-, and/or software-based logic for unlocking at least a portion of a device, where the Example of X1 includes a security engine in the device to: receive a signed token from an unlock host; store the signed token in a boot partition of the device; subsequent to a boot process initiating, attempt to verify the signed token; send a request to unlock the device based, at least in part, on the attempt to verify the signed token being successful; and an aggregator coupled to the security engine to: receive the request from the security engine to unlock the device; and unlock one or more privileged features on the device based on unlock data in the token. 
     In Example X2, the subject matter of Example X1 can optionally include that the signed token is based, at least in part, on a device identifier (ID) of the device and a nonce generated by the security engine. 
     In Example X3, the subject matter of any one of Examples X1-X2 can optionally include that the signed token includes a timestamp and an expiration parameter, wherein the timestamp and the expiration parameter define a time period during which the signed token is valid. 
     In Example X4, the subject matter of any one of Examples X1-X3 can optionally include that at least one privileged feature is unlocked by disabling code of a computing block on the device. 
     In Example X5, the subject matter of any one of Examples X1-X4 can optionally include that at least one privileged feature is unlocked by permitting one or more messages associated with a computing block of the device to be outputted. 
     In Example X6, the subject matter of any one of Examples X1-X5 can optionally include that at least one privileged feature is unlocked by enabling a type of access for a computing block on the device. 
     In Example X7, the subject matter of Example X6 can optionally include the type of access is selected from a group of access types including debugging, testing, provisioning, prototyping, validating, and analyzing. 
     In Example X8, the subject matter of any one of Examples X1-X7 can optionally include the security engine is further to: receive, from an unlock host, a request for a device identifier (ID) of the device; generate a nonce; and send the device ID and the nonce to the unlock host. 
     In Example X9, the subject matter of any one of Examples X1-X8 can optionally include that the attempt to verify the signed token is successful based, at least in part, on verifying integrity of the signed token, and verifying authenticity of the signed token. 
     In Example X10, the subject matter of Example X9 can optionally include that a token header of the signed token includes a public key associated with a private key used to create a signature of the signed token, where the public key is used to verify the integrity of the signed token and to verify the authenticity of the signed token. 
     In Example X11, the subject matter of any one of Examples X1-X10 can optionally include that the signed token includes a plurality of device IDs and a plurality of nonces. 
     In Example X12, the subject matter of Example X11 can optionally include that the attempt to verify the token is successful based, at least in part, on determining a device ID stored in the device corresponds to one of the plurality of device IDs in the signed token, and determining a nonce stored in the device corresponds to one of the plurality of nonces associated with the one of the plurality of device IDs. 
     Example Y1 provides an apparatus for unlocking at least a portion of a device, where the apparatus comprises means for performing the method of any one of the preceding Examples. 
     In Example Y2, the subject matter of Example Y1 can optionally include that the means for performing the method comprises at least one processor and at least one memory element. 
     In Example Y3, the subject matter of Example Y2 can optionally include that the at least one memory element comprises machine readable instructions that when executed, cause the apparatus to perform the method of any one of the preceding Examples. 
     In Example Y4, the subject matter of any one of Examples Y1-Y3 can optionally include that the apparatus is one of a computing system, a processing element, or a system-on-a-chip. 
     Example Y5 provides at least one machine readable storage medium comprising instructions for unlocking at least a portion of a device, where the instructions when executed realize an apparatus or implement a method as in any one of the preceding Examples. 
     Example Z1 provides an apparatus, a system, one or more machine readable mediums, a method, and/or hardware-, firmware-, and/or software-based logic for unlocking at least a portion of a device, where the Example of Z1 comprises a fuse controller including circuitry for storing, in a plurality of fuses, a unique identifier of the device and a first secured value of a first password associated with the unique identifier, an aggregator comprising circuitry and coupled to the fuse controller, and a security engine comprising circuitry and coupled to the aggregator. The aggregator is to receive the unique identifier and the first secured value from the fuse controller, send the unique identifier to an unlock host, and receive an error message from the unlock host indicating a second password was not retrieved. The security engine is to retrieve a signed token from a boot partition of the device, attempt to verify the signed token, and send a request to unlock the device based, at least in part, on the attempt to verify the signed token being successful. The aggregator is further to receive the request from the security engine to unlock the device, and unlock one or more privileged features on the device based on unlock data in the token.