Patent Description:
Reference is made to<NPL> which provides an arrangement that allows a user to exceptionally access a resource not normally accessible to that user for example in an emergency situation, the method described is performed by different entities namely the application service and the BTG-RBAC. The application service external to the user device interacts with an authentication service and the access control, BTG-RBAC, for elevating user credentials in case the user is not authorised to access a certain resource. Reference is made also to <NPL>; and to <CIT>.

The scope is in accordance with the appended claims.

Accordingly, a first aspect of the present teaching provides a method implemented by an integrated circuit of a computing device, comprising: validating a first request for elevated user privileges with respect to a network- based resource, the first request received from a central processing unit communicatively coupled to the integrated circuit; providing a second request for the elevated privileges to a network-based service; receiving a response from the network-based service, the response indicating that the second request for elevated credentials is granted; responsive to receiving the response, retrieving a private key stored in a memory communicatively coupled to the integrated circuit; digitally signing a third request, to access the network-based resource in accordance with the elevated privileges, using the retrieved private key; and providing the digitally-signed request to the network-based service to access the network-based resource. Preferably, said validating comprises: requesting a user to provide credentials; validating the provided credentials; and responsive to validating the provided credentials, validating the first request.

Preferably, the credentials comprise at least one of: biometric information; environmental information; a passcode; a username; or a password.

Preferably, the second request comprises at least one of: an identifier of the computing device; the provided credentials; an identifier of the network-based resource; voltage characteristics of the computing device; temperature characteristics of the computing device; or a location of the computing device.

Preferably, said validating comprises: determining a location in which the computing device is located; determining at least one of voltage characteristics or temperature characteristics associated with the computing device; determining that the location is one from a plurality of predetermined locations; determining that at least one of: the voltage characteristics are below a predetermined threshold, or the temperature characteristics are below a predetermined threshold; and responsive to determining that the location is one from the plurality of predetermined locations and determining that at least one of the voltage characteristics are below a predetermined threshold or the temperature characteristics are below a predetermined threshold, validating the first request.

Preferably, the integrated circuit comprises a configuration register that maintains a number of first requests received from the central processing unit.

Preferably, said validating further comprises: determining whether the number of first requests has a predetermined relationship with a predetermined threshold; in response to determining that the number of first requests has the predetermined relationship with the predetermined threshold, validating the first request; and in response to determining that the number of first requests does not have the predetermined relationship with the predetermined threshold, denying the first request.

According to a second aspect of the present teaching, there is provided a computing device comprising: at least one processor circuit; an integrated circuit communicatively coupled to the at least one processor circuit; and a memory communicatively coupled to the integrated circuit that stores a private key, the integrated circuit configured to: validate a first request for elevated user privileges with respect to a network-based resource, the first request received from the at least one processor circuit; provide a second request for the elevated privileges to a network-based service; receive a response from the network-based service, the response indicating that the second request for elevated credentials is granted; responsive to receiving the response, retrieve the private key from the memory; digitally sign a third request, to access the network-based resource in accordance with the elevated privileges, using the retrieved private key; and provide the digitally-signed request to the network-based service to access the network-based resource. Preferably, the integrated circuit is further configured to: request a user to provide credentials; validate the provided credentials; and responsive to validating the provided credentials, validate the first request.

Preferably, the integrated circuit is further configured to: determine a location in which the computing device is located; determine at least one of voltage characteristics or temperature characteristics associated with the computing device; determine that the location is one from a plurality of predetermined locations; determine that at least one of the voltage characteristics or temperature characteristics are below a predetermined threshold; and responsive to a determination that the location is one from the plurality of predetermined locations and a determination that at least one of the voltage characteristics or temperature characteristics are below a predetermined threshold, validate the first request.

Preferably, the integrated circuit is further configured to: determine whether the number of first requests has a predetermined relationship with a predetermined threshold; in response to a determination that the number of first requests has the predetermined relationship with the predetermined threshold, validate the first request; and in response to a determination that the number of first requests does not have the predetermined relationship with the predetermined threshold, deny the first request.

According to a third aspect of the present teaching, there is provided a method implemented by an integrated circuit of a computing device, comprising: validating a first request for elevated user privileges with respect to a network- based resource, the first request received from a central processing unit communicatively coupled to the integrated circuit; providing a second request for the elevated privileges to a network-based service; receiving a response from the network-based service, the response indicating that the second request for elevated credentials is granted and comprising a private key; digitally signing a third request, to access the network-based resource in accordance with the elevated privileges, using the private key; and providing the digitally-signed request to the network-based service to access the network-based resource.

Methods, systems, and apparatuses are disclosed directed to an integrated circuit for obtaining elevated credentials and performing actions with respect to a network- based resource in accordance with the elevated credentials. For instance, in certain situations (e.g., in an emergency), a user may be required to access a resource that the user is normally not to able to access. In such a scenario, a user, using their client device, may request their privileges with respect to that resource to be elevated, for example, using an application utilized to access the resource. Responsive to submitting the request, the client device's main central processing unit (CPU) may send a request to a specialized integrated circuit included in the client device. The specialized integrated circuit performs one or more forms of validation to determine whether the user making the request is authorized to do so, to determine whether the computing device has been tampered with, etc. If validation is successful, the specialized integrated circuit sends a request for elevated privileges to a network-based service, which determines whether or not the user is authorized to obtain elevated credentials. If the network-based service determines that the user is authorized to obtain elevated credentials, the network-based service provides a response granting the elevated credentials. Responsive to receiving the response, the specialized integrated circuit is given access to credentials for performing the action. The credentials may comprise a private key the circuit utilizes to digitally sign an action request to perform the desired action in accordance with the elevated privileges. The private key may be received via the response sent by the network-based service. Alternatively, the private key may be stored in a memory maintained by the specialized integrated circuit, which is made available to the circuit upon receiving the response from the network-based service. In the latter scenario, the specialized integrated circuit acts as a vault for the private key that is unlocked upon receiving the response from the network-based service. After digitally signing the action request, the specialized integrated circuit provides the signed request to the network-based service, which verifies the identity of the originator of the action request. Upon successful verification, the network-based service performs the desired action with respect to the resource in accordance with the elevated privileges.

Further features and advantages of the disclosed embodiments, as well as the structure and operation of various embodiments, are described in detail below with reference to the accompanying drawings. It is noted that the disclosed embodiments are not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.

The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments and, together with the description, further serve to explain the principles of the embodiments and to enable a person skilled in the pertinent art to make and use the embodiments.

The features and advantages of the disclosed embodiments will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like reference characters identify corresponding elements throughout.

The following detailed description discloses numerous example embodiments.

Embodiments described herein are directed to an integrated circuit for obtaining elevated credentials and performing actions with respect to a network-based resource in accordance with the elevated credentials. For instance, in certain situations (e.g., in an emergency), a user may be required to access a resource that the user is normally not to able to access. In such a scenario, a user, using his client device, may request his privileges with respect to that resource to be elevated, for example, using an application utilized to access the resource. Responsive to submitting the request, the client device's main central processing unit (CPU) may send a request to a specialized integrated circuit included in the client device. The specialized integrated circuit performs various forms of validation to determine whether the user making the request is authorized to do so, to determine whether the computing device has been tampered with, etc. If validation is successful, the specialized integrated circuit sends a request for elevated privileges to a network-based service, which determines whether or not the user is authorized to obtain elevated credentials. If the network-based service determines that the user is authorized to obtain elevated credentials, the network-based service provides a response granting the elevated credentials. Responsive to receiving the response, the specialized integrated circuit is given access to credentials for performing the action. The credentials may comprise private key that the circuit utilizes to digitally sign an action request to perform the desired action in accordance with the elevated privileges. The private key may be received via the response sent by the network-based service. Alternatively, the private key may be stored in a memory maintained by the specialized integrated circuit, which is made available to the circuit upon receiving the response from the network-based service. In the latter scenario, the specialized integrated circuit acts as a vault for the private key that is unlocked upon receiving the response from the network-based service. After digitally signing the action request, the specialized integrated circuit provides the signed request to the network-based service, which verifies the identity of the originator of the action request. Upon successful verification, the network-based service performs the desired action with respect to the resource in accordance with the elevated privileges.

The techniques described herein improve the strength in security for computing systems. For instance, as described herein, the credentials (e.g., the private key) may be stored in a secure, access-restricted memory, and the specialized integrated circuit is protected with various anti-tamper techniques. Such techniques advantageously prevent the credentials from being hacked (i.e., unauthorized access to the credentials is prevented) and prevent unauthorized elevated privilege requests for enabling a user to perform break glass operations. Not only is the device on which the credentials are stored protected, but also the resources accessible via the credentials stored on other computing devices.

Moreover, the anti-tamper techniques implemented by the specialized integrated circuit occur before elevated privilege requests are transmitted to the network-based service. Any privilege request that is deemed to be unauthorized is not transmitted to the network-based resource, thereby conserving network bandwidth.

The techniques described herein provide several advantages over conventional techniques. For instance, conventional techniques require significant administrative overhead. In particular, a user may be required to use a computing device that is intended for break glass-usage only, which requires significant software-based security measures to be implemented, for example, by an administrator. The functionality of such a device is heavily restricted, and therefore, does not make such a device ideal for performing other work-related tasks. This requires the user to utilize multiple computing devices, one to perform typical work-related tasks, and another specifically configured to perform break glass operations.

As described herein, the specialized integrated circuit is communicatively coupled to the client device's main CPU and is utilized when performing certain actions, such as break glass operations to perform an action with respect to a user in an emergency situation. Such a solution advantageously enables a user to maintain a single device for both typical work usage and for break glass operations, as opposed to conventional techniques that require the usage of a separate computing device specifically configured for break glass operations.

For instance, <FIG> depicts a block diagram of a system <NUM> for obtaining elevated privileges for access to a resource in accordance with an example embodiment. As shown in <FIG>, system <NUM> includes a cloud services platform <NUM> and a computing device <NUM> that are communicatively coupled via a network <NUM>. Network <NUM> may comprise one or more networks such as local area networks (LANs), wide area networks (WANs), enterprise networks, the Internet, etc., and may include one or more of wired and/or wireless portions. Computing device <NUM> may comprise, for example and without limitation, a desktop computer, a laptop computer, a server, a tablet computer, a netbook, a smartphone, or the like. Additional examples of computing device <NUM> are described below with reference to <FIG> and <FIG>.

In accordance with at least one embodiment, cloud services platform <NUM> comprises part of the Microsoft® Azure® cloud computing platform, owned by Microsoft Corporation of Redmond, Washington, although this is only an example and not intended to be limiting. Cloud services platform <NUM> may include one or more of any commercially available cloud computing platform and/or any other network-based server and storage system. As shown in <FIG>, cloud services platform <NUM> comprises a management service <NUM> and one or more resources <NUM>. Access management service <NUM> is configured to grant or deny requests for elevated privileges to a user. The elevated privileges grant the user the authorization to manage resource(s) <NUM> that they are normally not allowed to manage and/or perform an action with respect to resource(s) <NUM> that they are normally not authorized to perform. Examples of resource(s) <NUM> include a user or storage account, a directory, a file, a virtual machine, a database, a cloud-based subscription, etc..

Computing device <NUM> comprises at least a main processor <NUM> and an emergency access circuit <NUM> that is communicatively coupled to main processor <NUM>. Computing device <NUM> further comprises a main memory <NUM>. Processor <NUM> is an electrical and/or optical circuit implemented in one or more physical hardware electrical circuit device elements and/or integrated circuit devices (semiconductor material chips or dies) as a central processing unit (CPU), a microcontroller, a microprocessor, and/or other physical hardware processor circuit. Processor <NUM> may execute program code (e.g., application <NUM>) stored in a computer readable medium (e.g., main memory <NUM>), such as program code of an operating system installed on computing device <NUM> or application programs (e.g., application <NUM>) installed on computing device <NUM>. Examples of main memory <NUM> include a random access memory (RAM) (e.g., dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-data rate RAM (DDRRAM), etc.).

Emergency access circuit <NUM> is an electrical and/or optical circuit implemented in one or more physical hardware electrical circuit device elements and/or integrated circuit devices (semiconductor material chips or dies) as a microcontroller, a custom, specialized or application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) device, and/or the like. Emergency access circuit <NUM> is a separate circuit than processor circuit <NUM> and is not integrated with main processor <NUM>. Each of processor <NUM> and emergency access circuit <NUM> may be attached to the same motherboard included in computing device <NUM>. However, the embodiments described herein are not so limited. For instance, emergency access circuit <NUM> may be attached to a daughterboard that is communicatively coupled to the motherboard.

In certain embodiments, emergency access circuit <NUM> may be implemented as an emergency access unit that is implemented via software (e.g., comprising logic or program code) in a security coprocessor (e.g., a secured enclave) that is communicatively coupled to main processor <NUM>.

As shown in <FIG>, main memory <NUM> stores an application <NUM>, which is executable by main processor <NUM>. Application <NUM> may be any software application that enables a user to access, manage, and/or utilize resource(s) <NUM> in accordance with permissions or privileges (e.g., create, read, update, and/or delete (CRUD) permissions) assigned thereto. Examples of application <NUM>, include, but are not limited to, a portal application that enables the user to access, manage, and/or utilize a user account, a storage account and/or a cloud-based subscription, a database application, a file storage application, etc. In certain circumstances, such as in an emergency, a user may require that their privileges be elevated. The elevated privileges grant the user the authorization to access, manage, and/or utilize resource(s) <NUM> that they are normally not allowed to access, manage, and/or utilize and/or perform an action with respect to resource(s) <NUM> that they are normally not authorized to perform. Examples of such actions include, but are not limited to, accessing a root (or admin) account of an operating system or database system, accessing a file that is normally only accessible by an admin, accessing a user account, a storage account, and/or a cloud-based subscription of another user (e.g., an admin), restarting a resource of resource(s) <NUM> (e.g., a virtual machine), etc..

To request elevated privileges, the user may initiate a request for such privileges using application <NUM>, for example, using one or more user interface elements (e.g., graphical user interface (GUI) elements that enable the user to request elevated privileges). Upon initiating the request, main processor <NUM> may execute code of application <NUM> that causes main processor <NUM> to send a request for elevated privileges to emergency access circuit <NUM>.

Emergency access circuit <NUM> is configured to verify whether the request originated from a valid user. For instance, emergency access circuit <NUM> may cause a prompt to be provided to the user that solicits credentials from the user. Emergency access circuit <NUM> verifies whether the credentials provided by the user are correct. In response to determining that the credentials are correct, emergency access circuit <NUM> provides a request for elevated privileges to access management service <NUM>. It is noted that emergency access circuit <NUM> may initiate credential verification independent from receiving a request from main processor <NUM>. For example, emergency access circuit <NUM> may periodically perform credential verification and provide a request for elevated privileges upon receiving the request from main processor <NUM> (assuming the verification is successful). Access management service <NUM> determines whether the user requesting elevated privileges is authorized to request such privileges. In response to determining that the user requesting elevated privileges is authorized to do so, access management service <NUM> may send a response to emergency access circuit <NUM> indicating that the user is authorized to request elevated privileges. In response to receiving the response, emergency access circuit <NUM> obtains credentials. The credentials may comprise a private key, which emergency access circuit <NUM> utilizes to a sign an action request for performing an action with respect to resource(s) <NUM> in accordance with the elevated privileges. In accordance with an embodiment, the credentials may be provided by access management service <NUM>. In accordance with another embodiment, the credentials may be stored in a memory accessible only to emergency access circuit <NUM>. In accordance with a further embodiment, the credentials may be stored in the memory in an encrypted fashion and retrieved and decrypted based on a key received from access management service <NUM>. The action request may be provided to access management service <NUM>, which performs the desired action with respect to the resource of resource(s) <NUM> specified by the action request.

In response to emergency access circuit <NUM> determining that the credentials provided by the user are incorrect and/or in response to access management service <NUM> determining that the user requesting elevated privileges is not authorized to do so, the request for elevated privileges is denied, and the user is not enabled to perform an action (e.g., an emergency or break glass action) with respect to a resource of resource(s) <NUM>.

It is noted that access management service <NUM> and resource(s) <NUM> may be included on a same computing device (a node, a server, a virtual machine, etc.) of cloud services platform <NUM>, or alternatively, access management service <NUM> and resource(s) <NUM> may be included on different computing devices of cloud services platform <NUM>. Still further, resource(s) <NUM> may be included on a computing device not included as part of cloud services platform <NUM>. Moreover, resource(s) <NUM> may be maintained by a third-party that is different than the cloud services provider providing cloud services platform <NUM>.

It is further noted that while the present disclosure describes embodiments related to protecting credentials, the embodiments described herein are not so limited. For instance, any type of information (e.g., confidential information) may be protected e.g., by storing such information in the memory of emergency access circuit <NUM>.

<FIG> depicts a block diagram of a system <NUM> for obtaining elevated privileges for access to a resource in accordance in accordance with another example embodiment. As shown in <FIG>, system <NUM> includes a cloud services platform <NUM> and a computing device <NUM> that are communicatively coupled via a network <NUM>. Cloud services platform <NUM>, computing device <NUM>, and network <NUM> are examples of cloud services platform <NUM>, computing device <NUM>, and network <NUM>, as respectively described above with reference to <FIG>.

As shown in <FIG>, cloud services platform <NUM> comprises an access management service <NUM> and one or more resources <NUM>, which are examples of access management service <NUM> and resource(s) <NUM>, as respectively described above with reference to <FIG>.

Computing device <NUM> comprises at least a main processor <NUM> and an emergency access circuit <NUM> that is communicatively coupled to main processor <NUM>. Computing device <NUM> further comprises a main memory <NUM>. Processor <NUM>, emergency access circuit <NUM>, and main memory <NUM> are examples of processor <NUM>, emergency access circuit <NUM>, and main memory <NUM>, as respectively described above with reference to <FIG>. As further shown in <FIG>, computing device <NUM> is communicatively coupled to a display <NUM>, which may be integrated with computing device <NUM> (e.g., display <NUM> may be a display screen, a touch screen, etc.). Although, the embodiments described herein are not so limited. For instance, display <NUM> may an external device (e.g., a monitor, a television, a projector, etc.) that is coupled to computing device <NUM>. Computing device <NUM> further comprises a network interface <NUM>. Network interface <NUM> may interface with remote sites (e.g., cloud services platform <NUM>) and/or networks (e.g., network <NUM>) via wired or wireless connections. Examples of network interface <NUM> include but are not limited to a modem, a network interface card (e.g., an Ethernet card), a communication port, a Personal Computer Memory Card International Association (PCMCIA) card, etc..

Emergency access circuit <NUM> comprises one or more bus interfaces <NUM>, policy enforcer logic <NUM>, secure channel logic <NUM>, and one or more keys <NUM>. As shown in <FIG>, emergency access circuit <NUM> may further comprise a memory <NUM>, although the embodiments described herein are not so limited. For instance, memory <NUM> may be external to emergency access circuit <NUM>. Bus interface(s) <NUM> may comprise a plurality of different bus interfaces, each suitable for communication and data transmission between emergency access circuit <NUM> and one or more other components, such as, but not limited to network interface <NUM>, main processor <NUM>, main memory <NUM>, and/or memory <NUM>. Examples of bus interface(s) <NUM> configured to communicate with main processor <NUM>, main memory <NUM>, network interface <NUM> and/or memory <NUM> include, but are not limited to a serial peripheral interface (SPI), an Octal SPI (OSPI) interface, a Quad SPI (QSPI) interface, a Peripheral Component Interconnect (PCI)-based interface (e.g., PCI-X, PCIe, etc.), a Low Pin Count (LPC) interface, an Inter-Integrated Circuit (I2C) interface, a Universal Asynchronous Receiver/Transmitter (UART) interface, and/or any other bus suitable for transmitting and receiving data between emergency access circuit <NUM> and main processor <NUM>, main memory <NUM>, network interface <NUM> and/or memory <NUM>.

Key <NUM> may comprise a private key that is uniquely associated with emergency access circuit <NUM> and that is stored in memory <NUM>. However, the embodiments described herein are not so limited. For example, as will be described below with reference to <FIG> and <FIG>, key <NUM> may be obtained from access management service <NUM>. Emergency access circuit <NUM> utilizes key <NUM> to a sign an action request for performing an action with respect to resource(s) <NUM> in accordance with elevated privileges. Key <NUM> becomes accessible by emergency access circuit <NUM> only when a user's request for elevated privileges is granted, for example, by access management service <NUM>.

Emergency access circuit <NUM> may be protected with various anti-tamper techniques to prevent unauthorized access to key <NUM>. For example, emergency access circuit <NUM> may use any number of and/or a combination of anti-tamper techniques. Examples of anti-tamper techniques include, but are not limited to fully-enclosed encapsulation or coating techniques, where emergency access circuit <NUM> is fully encapsulated with filled epoxy (or a similar substance) or coated with acrylic, epoxy, or silicone-based substances, the usage of security fuses with respect memory <NUM>, which prevent the unauthorized access of data stored in memory <NUM>, layout and data bus scrambling, etc..

Memory <NUM> may be further protected such that is it only accessible by emergency access circuit <NUM> (and not main processor <NUM> or any other entity communicatively coupled to computing device <NUM>) under certain conditions (e.g., only when a user's request for elevated privileges is granted). Key <NUM> may be written to memory <NUM> using fuses (or anti-fuses), using flash techniques, using certain write ports, which are then subsequently destroyed or deactivated, and/or the like. Memory <NUM> is a non-volatile memory. Examples of memory <NUM>, include, but are not limited to, a programmable read-only memory (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), flash memory, and/or the like.

Key(s) <NUM> comprises one or more private and/or public keys that are used for authentication of requests, responses, and other types of transmissions between emergency access circuit <NUM> and access management service <NUM>. Key(s) <NUM> may be stored via one or more fuses of emergency access circuit <NUM> or in a memory (other than memory <NUM>) maintained by emergency access circuit <NUM>. Such a memory is not shown for brevity. Key(s) <NUM> and key <NUM> may be stored in emergency access circuit <NUM> at the time of provisioning (e.g., manufacturing) of computing device <NUM>. Key(s) <NUM> and/or key <NUM> may be generated in accordance with any technique known in the art, including, but not limited to, a Rivest-Shamir-Adleman (RSA) encryption-based techniques, ElGamal encryption-based techniques, Digital Signature Standard (DSS) encryption-based techniques, etc..

As described above, in certain circumstances, such as in an emergency, a user may request that his privileges be elevated. The elevated privileges grant the user the authorization to access, manage, and/or utilize resource(s) <NUM> that they are normally not allowed to access, manage, and/or utilize and/or perform an action (e.g., a break glass operation) with respect to resource(s) <NUM> that they are normally not authorized to perform. Examples of such actions include, but are not limited to, accessing a root (or admin) account of an operating system or database system, accessing a file that is normally only accessible by an admin, accessing a user account, a storage account, and/or a cloud-based subscription of another user (e.g., an admin), restarting a resource of resource(s) <NUM> (e.g., a virtual machine), etc..

To request elevated privileges, the user may initiate a request for such privileges using application <NUM>, for example, using one or more user interface (e.g., a graphical user interface (GUI) elements of user interface <NUM> that enable the user to request elevated privileges). Upon initiating the request, main processor <NUM> may execute code <NUM> of application <NUM> that causes main processor <NUM> to send a request <NUM> for elevated privileges to emergency access circuit <NUM>. Request <NUM> is received via bus interface(s) <NUM>. Bus interface(s) <NUM> provides request <NUM> to policy enforcer logic <NUM>.

Policy enforcer logic <NUM> of emergency access circuit <NUM> is configured to verify whether request <NUM> originated from an authorized user. For instance, responsive to receiving request <NUM>, emergency access circuit <NUM> may cause a prompt <NUM> to be provided to display <NUM> via bus interface(s) <NUM>. In accordance with an embodiment, prompt <NUM> is provided directly from emergency access circuit <NUM> to display <NUM> (e.g., via bus interface(s) <NUM>). In accordance with another embodiment, emergency access circuit <NUM> provides prompt <NUM> to main processor <NUM> (e.g., via bus interface(s) <NUM>), and main processor <NUM> causes prompt <NUM> to be displayed via user interface <NUM>.

Prompt <NUM> may solicit certain credentials from the user. Examples of such credentials include, but are not limited to, a passphrase, a security code or personal identification number (PIN), a username and/or password, biometric data or information (e.g., a fingerprint, facial detection, blood characteristic detection (e.g., based on blood flow patterns), etc.), environmental information (e.g., based on measurements of motion, temperature, lighting, temperature, etc. of the room in which computing device <NUM> is located), etc. Upon receiving such credentials, policy enforcer logic <NUM> verifies whether the credentials are correct. For example, a memory (e.g., other than memory <NUM>) of emergency access circuit <NUM> may store credentials for the user. Policy enforcer logic <NUM> compares the received credentials to the credentials stored in the memory. If the credentials match, policy enforcer logic <NUM> determines that an authorized user requested the elevated privileges. If the credentials do not match, policy enforcer logic <NUM> determines that an unauthorized user requested the elevated privileges.

Policy enforcer logic <NUM> may also determine a location in which computing device <NUM> is located and/or a network (e.g., a cellular network, a LAN, a WAN, an enterprise network etc.) to which computing device <NUM> is connected. Policy enforcer logic <NUM> may query other components of computing device <NUM> (e.g., a global position system (GPS) module, an operating system, network interface <NUM>, etc.) to determine the location and/or network. Upon determining the location and/or network, policy enforcer logic <NUM> verifies whether the determined location and/or network are from a predetermined list of locations and/or networks. For example, a memory of emergency access circuit <NUM> may store the predetermined list of locations and/or networks for the user. The predetermined list may be configurable and stored (e.g., by an admin or the user of computing device <NUM>) in a memory (other than memory <NUM>) included in emergency access circuit <NUM> and/or main memory <NUM>. Policy enforcer logic <NUM> compares the determined location and/or network to the predetermined list of locations and/or networks stored in the memory. If the determined location and/or network are included in the predetermined list of locations and/or networks, policy enforcer logic <NUM> determines that computing device <NUM> is in a location and/or connected to a network in which requests for elevated privileges are authorized. If the determined location and/or network are not included in the predetermined list of locations and/or networks, policy enforcer logic <NUM> determines that computing device <NUM> is in a location and/or connected to a network in which requests for elevated privileges are not authorized. Such techniques advantageously ensure that computing device <NUM> is in a location or connected to a network that has been designated as being safe or secure (e.g., an environment that is not prone to malicious attacks) before authorizing requests to elevated privileges. This greatly reduces the chances of a malicious entity intercepting communications between computing device <NUM> and access management service <NUM>.

Policy enforcer logic <NUM> may also determine certain hardware-related characteristics associated with emergency access circuit <NUM> and/or computing device <NUM> and determine whether such characteristics have a predetermined relationship with a predetermined threshold. For instance, policy enforcer logic <NUM> may determine voltage characteristics, temperature characteristics, resistance characteristics, etc., associated with emergency access circuit <NUM> and/or computing device <NUM>. Policy enforcer logic <NUM> may query other components of computing device <NUM> (e.g., one or more temperature sensors, resistance sensors, current sensors, voltage sensors, etc.) to determine such hardware-based characteristics. Upon determining such hardware-based characteristics, policy enforcer logic <NUM> verifies whether such hardware-based characteristics exceed a predetermined threshold for each of such hardware-based characteristics. For example, a memory (other than memory <NUM>) of emergency access circuit <NUM> may store the predetermined thresholds. Policy enforcer logic <NUM> compares each of the determined hardware-based characteristics to its associated predetermined threshold. If the determined hardware-based characteristics do not exceed the predetermined threshold, policy enforcer logic <NUM> determines that the hardware-based characteristics are not indicative of any kind of tampering, and therefore, determines that such characteristics are valid. If the determined hardware-based characteristics exceed the predetermined threshold (e.g., such characteristics are too high or low), policy enforcer logic <NUM> determines that emergency access circuit <NUM> and/or computing device <NUM> have been tampered with. Variances in hardware-based characteristics, such as temperature and/or voltage, may be advantageously used to detect certain various tampering attempts, such as a cold boot attacks, glitch attacks, etc..

Policy enforcer logic <NUM> may also query a trusted platform module (TPM) (not shown) or other type of secure cryptoprocessor for a hash key summary of the hardware and/or software configuration of emergency access circuit <NUM> and computing device <NUM>. Upon determining the hash key summary, policy enforcer logic <NUM> verifies whether the hash key summary is the original hash key summary (e.g., the hash key summary determined at the time of provisioning computing device <NUM>). For example, a memory of emergency access circuit <NUM> may store the original hash key summary. The original hash key summary may be stored in a memory (other than memory <NUM>) included in emergency access circuit <NUM> and/or main memory <NUM>. Policy enforcer logic <NUM> compares the hash key summary received from the TPM to the original hash key summary. Policy enforcer logic <NUM> determines that the received hash key summary is valid if it is the same as the original hash key summary and determines that emergency access circuit <NUM> and/or computing device <NUM> have been tampered with. If the original hash key summary and the received hash key summary are not the same, policy enforcer logic <NUM> determines that emergency access circuit <NUM> and/or computing device <NUM> have been tampered with. The TPM may be included as part of emergency access circuit <NUM> or computing device <NUM>.

It is noted that the credentials stored by emergency access circuit <NUM>, the predetermined list of locations and/or networks, the predetermined thresholds, and/or the hash key summary described above may be stored in one or more configuration registers <NUM> maintained by memory <NUM> and/or may be retrieved from access management service <NUM>.

In response to determining that an authorized user has requested elevated privileges, determining that emergency access circuit <NUM> and/or computing device <NUM> have not been tampered with, and/or determining that computing device <NUM> is located in an authorized location and/or connected to an authorized network, emergency access circuit <NUM> provides a request for elevated privileges to access management service <NUM>. The request is provided in a secure fashion to prevent a malicious entity from accessing the contents of request and also to ensure that the request is coming from emergency access circuit <NUM>. For instance, as shown in <FIG>, secure channel logic <NUM> may generate an encrypted request <NUM>. Secure channel logic <NUM> may generate encrypted request <NUM> using a public key of key(s) <NUM> associated with access management service <NUM>. Encrypted request <NUM> may specify a unique identifier of the user and/or computing device <NUM>, the resource of resource(s) <NUM> attempting to be accessed, a uniform resource identifier (e.g., an Internet Protocol (IP) address) of computing device <NUM>, the credentials provided by the user, the location of computing device <NUM>, the network to which computing device <NUM> is connected, the hardware-based characteristics, the hash key summary, etc. Request <NUM> may be encrypted in accordance with any technique known in the art, including, but not limited to, a Rivest-Shamir-Adleman (RSA) encryption-based techniques, ElGamal encryption-based techniques, Digital Signature Standard (DSS) encryption-based techniques, etc..

As further shown in <FIG>, secure channel logic <NUM> may provide encrypted request <NUM> to bus interface(s) <NUM>, which provides encrypted request <NUM> to network interface <NUM>. Network interface <NUM> provides encrypted request <NUM> to access management service <NUM> via network <NUM>. Alternatively, bus interface(s) <NUM> may be configured to provide encrypted request <NUM> to main processor <NUM>, which in turn, provides encrypted request <NUM> to network interface <NUM>.

Upon receiving encrypted request <NUM>, access management service <NUM> decrypts encrypted request <NUM>, for example, using its private key, and determines whether the user requesting elevated privileges is authorized to request such privileges. For instance, access management service <NUM> may comprise one or more user profiles <NUM>. Each of user profile(s) associates a particular user and/or computing device with at least one resource of resource(s) <NUM> and the actions that the user is allowed to perform with respect to the at least one resource in accordance with the elevated privileges. Each of user profile(s) <NUM> may further associate the valid credentials of the user, valid locations and/or networks for a respective computing device (e.g., computing device <NUM>) enabled to provide requests for elevated privileges the credential, acceptable hardware-based characteristics for such a computing device, the hash key summary for such a computing device, etc..

Access management service <NUM> compares the information specified by request <NUM> to the information stored by a user profile of user profile(s) <NUM> identified by request <NUM>. If the information matches and request <NUM> identifies a resource of resource(s) <NUM> for which the user is authorized to request elevated privileges and further identifies an allowed action to be performed with such a resource (as specified by the user profile), access management service <NUM> determines that the user requesting elevated privileges is authorized to do so. In response to such a determination, access management service <NUM> may send an encrypted response <NUM> to emergency access circuit <NUM>, via network <NUM>, indicating that the user is authorized to request elevated privileges. For example, access management service <NUM> may store a public key associated with emergency access circuit <NUM> (and corresponding to a private key of key(s) <NUM> of encrypted access circuit <NUM>) and encrypt response <NUM> using the public key. In response to determining that the information specified by request <NUM> does not match the information in the corresponding user profile of user profile(s) <NUM>, access management service <NUM> may send an encrypted response to emergency access circuit <NUM>, via network <NUM>, indicating that the user is not authorized to request elevated privileges.

Responses sent by access management service <NUM> (e.g., response <NUM>) are received by network interface <NUM> of computing device <NUM>. As shown in <FIG>, network interface <NUM> may provide such responses directly to emergency access circuit <NUM> via bus interface(s) <NUM>. Alternatively, network interface <NUM> may provide such responses to main processor <NUM>, which in turn provides such responses to emergency access circuit <NUM> via bus interface(s) <NUM>.

As further shown in <FIG>, bus interface(s) <NUM> provide encrypted response <NUM> to secure channel logic <NUM>, which decrypts encrypted response <NUM> using a private key of key(s) <NUM> associated with emergency access circuit <NUM>. Secure channel logic <NUM> may determine whether the decrypted response indicates that the user is authorized to receive elevated privileges. If a determination is made that decrypted response indicates that the user is not authorized, the user's request is denied. Optionally, an error or denial message may be displayed to the user, e.g., via user interface <NUM>. If a determination is made that the decrypted response indicates that the user is authorized, secure channel logic <NUM> becomes enabled to access key <NUM> from memory <NUM>. For instance, memory access logic (shown as memory access logic <NUM>) configured to access memory <NUM> may become activated. Upon memory access logic <NUM> being activated, memory access logic <NUM> provides a read command <NUM> to memory <NUM>, identifying an address at which key <NUM> is located. Such an address may be hardcoded in memory access logic <NUM>. Upon receiving read command <NUM>, memory <NUM> provides a response <NUM> comprising key <NUM>.

Secure channel logic <NUM> utilizes key <NUM> to encrypt and/or digitally sign an action request <NUM> for performing an action with respect to the resource of resource(s) <NUM> (identified by request <NUM>) in accordance with the elevated privileges. The digital signature of action request <NUM> assures the recipient of action request <NUM> (e.g., access management service <NUM>) of the identity of the sender (i.e., emergency access circuit <NUM>) and of the integrity of action request <NUM>. As shown in <FIG>, secure channel logic <NUM> provides access request <NUM> to bus interface(s) <NUM>, which in turn, provides access request <NUM> to network interface <NUM>. Network interface <NUM> provides action request <NUM> to access management service <NUM> via network <NUM>. Alternatively, bus interface(s) <NUM> may provide action request <NUM> to main processor <NUM>, and main processor <NUM> provides action request <NUM> to network interface <NUM>.

Upon receiving action request <NUM>, access management service <NUM> decrypts action request <NUM>, for example, using a public key associated with emergency access circuit <NUM> and corresponding to key <NUM>, and/or verifies the identity of the sender of action request <NUM> based on the digital signature. If the identity is verified, request <NUM> serves as notice to access management service <NUM> that emergency access circuit <NUM> has obtained private key <NUM> (i.e., the glass has been broken). Upon successful verification, access management service <NUM> provides a command <NUM> to the resource of resource(s) <NUM> identified by action request <NUM>, and the action specified by action request <NUM> is performed. Access management service <NUM> may log all actions performed under elevated privileges for auditing purposes. If the identity is not verified (e.g., the digital signature is incorrect), action request <NUM> is denied and the action specified by action request <NUM> is not performed.

In response to determining that an unauthorized user has requested elevated privileges, determining that emergency access circuit <NUM> and/or computing device <NUM> has been tampered with, and/or determining that computing device <NUM> is located in an unauthorized location and/or connected to an unauthorized network, request <NUM> is not transmitted, and the user is not enabled to request elevated privileges.

In accordance with an embodiment, the number of times that a user is allowed to request elevated privileges is limited. For instance, as shown in <FIG>, memory <NUM> may comprise one or more configuration registers <NUM>. Configuration register(s) <NUM> may be located in a region of memory <NUM> that is readily accessible by policy enforcer logic <NUM> (i.e., configuration registers <NUM> are located in a memory region other than the memory region in which key <NUM> is located). A first configuration register of configuration register(s) <NUM> may store a maximum number of requests for elevated privileges that a user is enabled to make (e.g., via application <NUM>). A second configuration register of configuration register(s) <NUM> may function as a counter and stores the total number of requests that have been made by the user. For example, each time a request <NUM> is transmitted from main processor <NUM> to emergency access circuit <NUM> (responsive to a user initiating a request for elevated privileges via application <NUM>), the second configuration register may be incremented. Policy enforcer logic <NUM> may then compare the value stored in the second configuration register to the maximum number value stored in the first configuration register. If the value stored in the second configuration register is less than or equal to the maximum number, then the elevated privilege request process described above (e.g., in which secure channel logic <NUM> issues request <NUM> if all other necessary conditions are satisfied (e.g., determining that an authorized user has requested elevated privileges, determining that emergency access circuit <NUM> and/or computing device <NUM> have not been tampered with, and/or determining that computing device <NUM> is located in an authorized location and/or connected to an authorized network, etc.)).

If the value stored in the second configuration register is greater than the maximum number, then policy enforcer logic <NUM> is not enabled to continue the elevated privilege request, and thus, the user is not authorized to obtain elevated privileges.

In accordance with an embodiment, configuration register(s) <NUM> may comprise a third configuration register that stores a maximum number of requests for elevated privileges that may be denied and a fourth configuration register that functions as a counter and stores the total number of such requests that have been denied. Each time a request <NUM> is denied, the fourth configuration register may be incremented.

As an added security measure, upon determining that the value stored in the second configuration register is greater than the maximum number stored in the first configuration register and/or upon determining that the value stored in the fourth configuration register is greater than the maximum number stored in the third configuration register, key <NUM> may be erased from memory <NUM>. For instance, policy enforcer logic <NUM> may send a command to secure channel logic <NUM> that activates memory access logic <NUM>. Memory access logic <NUM> may send a command that causes key <NUM> to be erased (e.g., by overwriting the memory region at which key <NUM> is located with another value or by wiping a key that may be used to encrypt memory <NUM>).

The usage of configuration register(s) <NUM>, as described above, provide logical constraints on the number of times a user may request elevated credentials, and therefore, limits the accessibility to resource(s) <NUM>, for example, from malicious entities that obtain access to computing device <NUM>.

It is noted that the values described above with respect to configuration register(s) <NUM> are purely exemplary and that a determination as to whether the elevated privilege request process may continue may be based on determining whether the number of requests stored in the second configuration register and/or the number of times such requests have been denied stored in the fourth configuration register has a different type of predetermined relationships with the value stored in the first configuration register and the third configuration register, respectively (including, but not limited to, whether the number of requests made/denied is greater than, less than, greater than or equal to, less than or equal to, or equal to the number value stored in the first configuration register and/or third configuration register, respectively).

In accordance with an embodiment, rather than erasing private key <NUM>, the value stored in the second configuration register may be reset and/or a new private key may be stored in memory <NUM>, thereby enabling a user to perform subsequent break glass operations.

In accordance with an embodiment, when a request for elevated privileges is granted, the elevated privileges may be granted for a limited amount of time. The amount of time may be specified by a timer, e.g., maintained by a configuration register of configuration register(s) <NUM>. Alternatively, the time limit may be provided by access management server <NUM>, for example, via response <NUM>. Once the time limit expires, the elevated privileges are revoked.

Accordingly, elevated privileges may be obtained based on a private key maintained by emergency access circuit <NUM> in many ways. For example, <FIG> depicts a flowchart <NUM> of an example method performed by an integrated circuit of a computing device for obtaining elevated credentials based on a private key maintained by the integrated circuit in accordance with an example embodiment. The method of flowchart <NUM> will be described with continued reference to system <NUM> of <FIG>, although the method is not limited to that implementation. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the discussion regarding flowchart <NUM> and system <NUM> of <FIG>.

As shown in <FIG>, the method of flowchart <NUM> begins at step <NUM>, in which a first request for elevated user privileges with respect to a network-based resource is validated. The first request is received from a central processing unit communicatively coupled to the integrated circuit. For example, with reference to <FIG>, bus interface(s) <NUM> of emergency access circuit <NUM> receives first request <NUM> from main processor <NUM>. Request <NUM> is for elevated user privileges with respect to a network-based resource (e.g., resource(s) <NUM>). Request <NUM> may be provided by main processor <NUM> responsive to a user initiating a request for elevated privileges via application <NUM>. Bus interface(s) <NUM> provides request <NUM> to policy enforcer logic <NUM>. Policy enforcer logic <NUM> is configured to validate request <NUM>. Request <NUM> may be validated using various techniques. Additional details regarding validating techniques are described below with reference to <FIG>.

At step <NUM>, a second request for the elevated privileges is provided to a network-based service. For example, with reference to <FIG>, after first request <NUM> is validated, secure channel logic <NUM> may provide second request <NUM> to bus interface(s) <NUM>. Bus interface(s) <NUM> may provide second request <NUM> to network interface <NUM>, which provides second request <NUM> to network-based service (e.g., access management service <NUM>) via network <NUM>. Alternatively, bus interface(s) <NUM> may provide second request <NUM> to main processor <NUM>, and main processor <NUM> may provide second request <NUM> to network interface <NUM>.

In accordance with one or more embodiments, the second request comprises at least one of an identifier of the computing device (e.g., computing device <NUM>), credentials provided by a user, an identifier of the network-based resource (e.g., resource(s) <NUM>), voltage characteristics of the computing device, temperature characteristics of the computing device, or a location of the computing device.

At step <NUM>, a response from the network-based service is received. The response indicates that the second request for elevated credentials is granted. For example, with reference to <FIG>, access management service <NUM> determines whether second request <NUM> is from an authorized user by comparing the information specified by second request <NUM> to a corresponding profile of user profile(s) <NUM>. Responsive to determining that second request <NUM> is from an authorized user, access management service <NUM> provides a response <NUM> to computing device <NUM>. Response <NUM> is received by network interface <NUM>. Network interface <NUM> may provide response <NUM> to bus interface(s) <NUM> of emergency access circuit <NUM>, and bus interface(s) <NUM> provide response <NUM> to secure channel logic <NUM>. Alternatively, network interface <NUM> may provide response <NUM> to main processor, <NUM>, and main processor <NUM> provides response <NUM> to bus interface(s) <NUM>.

At step <NUM>, responsive to receiving the response, a private key stored in a memory communicatively coupled to the integrated circuit is retrieved. For example, with reference to <FIG>, responsive to receiving response <NUM>, secure channel logic <NUM> activates memory access logic <NUM>. Memory access logic <NUM> is configured to read a memory region of memory <NUM> at which key <NUM> is located. Memory access logic <NUM> may provide a read command <NUM> specifying the address of the memory region to memory <NUM>. Memory <NUM> may provide a response <NUM> comprising key <NUM> to memory access logic <NUM>.

At step <NUM>, a third request, to access the network-based resource in accordance with the elevated privileges, is digitally signed using the retrieved private key. For example, with reference to <FIG>, secure channel logic <NUM> may digitally sign request <NUM> using key <NUM>.

At step <NUM>, the digitally-signed request is provided to the network-based service to access the network-based resource. For example, with reference to <FIG>, secure channel logic <NUM> provides digitally-signed request <NUM> to bus interface(s) <NUM>. Bus interface(s) <NUM> may provide request <NUM> to network interface <NUM>, which provides request <NUM> to access management service <NUM> via network <NUM>. Alternatively, bus interface(s) <NUM> provides request <NUM> to main processor <NUM>, and main processor <NUM> provides request <NUM> to network interface <NUM>. Upon receiving request <NUM>, access management service <NUM> verifies the identity of the sender of request <NUM> based on the digital signature. If the identity is verified, access management service <NUM> provides command <NUM> to the resource of resource(s) <NUM> identified by request <NUM>, and the action specified by request <NUM> is performed. If the identity is not verified (e.g., the digital signature is incorrect), request <NUM> is denied and the action specified by request <NUM> is not performed.

<FIG> depicts a flowchart <NUM> of an example method for validating a request for elevated privileges in accordance with an example embodiment. The method of flowchart <NUM> will be described with continued reference to system <NUM> of <FIG>, although the method is not limited to that implementation. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the discussion regarding flowchart <NUM> and system <NUM> of <FIG>.

As shown in <FIG>, the method of flowchart <NUM> begins at step <NUM>, in which a user is requested to provide credentials. For example, with reference to <FIG>, policy enforcer logic <NUM> may issue prompt <NUM>, which may be displayed via user interface <NUM>.

In accordance with one or more embodiments, the credentials comprise at least one of biometric information, environmental information, a passcode, a username, or password.

At step <NUM>, the provided credentials are validated. For example, with reference to <FIG>, policy enforcer logic <NUM> compares the credentials inputted by the user to credentials stored by emergency access circuit <NUM>. If the inputted credentials match the stored credentials, the inputted credentials are validated.

At step <NUM>, responsive to validating the provided credentials, the first request is validated. For example, with reference to <FIG>, policy enforcer logic <NUM> validates first request <NUM> responsive to validating the provided credentials.

<FIG> depicts a flowchart <NUM> of an example method for validating a request for elevated privileges in accordance with another example embodiment. The method of flowchart <NUM> will be described with continued reference to system <NUM> of <FIG>, although the method is not limited to that implementation. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the discussion regarding flowchart <NUM> and system <NUM> of <FIG>.

As shown in <FIG>, the method of flowchart <NUM> begins at step <NUM>, in which a location in which the computing device is located. For example, with reference to <FIG>, policy enforcer logic <NUM> may be configured to determine a location in which computing device <NUM> is located and/or a network to which computing device <NUM> is connected (e.g., a cellular network, a WAN, a LAN, an enterprise network, etc.), for example, by querying other components (e.g., the operating system, a GPS module, etc.) of computing device <NUM>.

At step <NUM>, at least one of voltage characteristics or temperature characteristics associated with the computing device are determined. For example, with reference to <FIG>, policy enforcer logic <NUM> may be configured to determine at least one of voltage characteristics or temperature characteristics, for example, by querying other components (e.g., the operating system, temperature sensors, voltage sensors, etc.) of computing device <NUM>.

At step <NUM>, a determination is made that the location is one from a plurality of predetermined locations. For example, with reference to <FIG>, policy enforcer logic <NUM> may be configured to determine that the location is one from a plurality of predetermined locations, for example, by comparing the determined location to a list of predetermined locations stored in emergency access circuit <NUM>.

At step <NUM>, a determination is made that at least one of the voltage characteristics are below a predetermined threshold or the temperature characteristics are below a predetermined threshold. For example, with reference to <FIG>, policy enforcer logic <NUM> determines that at least one of the voltage characteristics are below a predetermined threshold or the temperature characteristics are below a predetermined threshold, for example, by comparing the determined voltage and/or temperature characteristic values to predetermined voltage and/or temperature characteristic values stored in emergency access circuit <NUM>.

At step <NUM>, responsive to determining that the location is one from the plurality of predetermined locations and determining that at least one of the voltage characteristics are below a predetermined threshold or the temperature characteristics are below a predetermined threshold, the first request is validated. For example, with reference to <FIG>, policy enforcer logic <NUM> validates request <NUM> responsive to determining that the location is one from the plurality of predetermined locations and determining that at least one of the voltage characteristics are below a predetermined threshold or the temperature characteristics are below a predetermined threshold.

In accordance with one or more embodiments, the integrated circuit comprises a configuration register that maintains a number of first requests received from the central processing circuit. For example, with reference to <FIG>, emergency access circuit <NUM> comprises configuration register(s) <NUM>. One of configuration register(s) <NUM> stores a number of first requests <NUM> of main processor <NUM>. Policy enforcer logic <NUM> may validate first request <NUM> based on whether the number of first requests <NUM> has a predetermined relationship with a predetermined threshold. Such an embodiment is described below with reference to <FIG>.

<FIG> depicts a flowchart <NUM> of an example method for validating a request for elevated privileges in accordance with a further example embodiment. The method of flowchart <NUM> will be described with continued reference to system <NUM> of <FIG>, although the method is not limited to that implementation. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the discussion regarding flowchart <NUM> and system <NUM> of <FIG>.

As shown in <FIG>, the method of flowchart <NUM> begins at step <NUM>, in which a determination is made as to whether the number of first request has a predetermined relationship with a predetermined threshold. In response to a determination that the number of first requests does not have the predetermined relationship with the predetermined relationship, flow continues to step <NUM>. Otherwise, flow continues to step <NUM>. For example, with reference to <FIG>, policy enforcer logic <NUM> determines whether the number of first requests <NUM> has a predetermined relationship with a predetermined threshold. The predetermined threshold may be stored in a first configuration register of configuration register(s) <NUM>. The number of first requests <NUM> may be stored in a second configuration register of configuration register(s) <NUM>. Policy enforcer logic <NUM> may compare the number of first requests <NUM> stored in the second configuration register to the predetermined threshold stored in the first configuration register. If the number of first requests <NUM> does not have the predetermined relationship with the predetermined threshold (e.g., the number of first requests <NUM> is above the predetermined threshold), flow continues to step <NUM>. If the number of first requests <NUM> has the predetermined relationship with the predetermined threshold (e.g., the number of first requests <NUM> is below or equal to the predetermined threshold), flow continues to step <NUM>.

At step <NUM>, the first request is validated. For example, with reference to <FIG>, policy enforcer logic <NUM> validates first request <NUM>.

At step <NUM>, the first request is denied. For example, with reference to <FIG>, policy enforcer logic <NUM> denies first request <NUM>.

As described above, instead of storing private key <NUM> in memory <NUM> of emergency access circuit <NUM>, emergency access circuit <NUM> may receive the private key from access management service <NUM>. For example, <FIG> depicts a block diagram of a system <NUM> for obtaining elevated privileges for emergency access to a resource based on a private key received from a network-based service in accordance with an example embodiment. As shown in <FIG>, system <NUM> includes a cloud services platform <NUM> and a computing device <NUM> that are communicatively coupled via a network <NUM>. Cloud services platform <NUM>, computing device <NUM>, and network <NUM> are examples of cloud services platform <NUM>, computing device <NUM>, and network <NUM>, as respectively described above with reference to <FIG>.

Computing device <NUM> comprises at least a main processor <NUM> and an emergency access circuit <NUM> that is communicatively coupled to main processor <NUM>. Computing device <NUM> is also coupled to a display <NUM>, which is an example of display <NUM>. Computing device <NUM> further comprises a main memory <NUM>. Processor <NUM>, emergency access circuit <NUM>, and main memory <NUM> are examples of processor <NUM>, emergency access circuit <NUM>, and main memory <NUM>, as respectively described above with reference to <FIG>. Computing device <NUM> further comprises a network interface <NUM>, which is an example of network interface <NUM>, as described above with reference to <FIG>.

Emergency access circuit <NUM> comprises one or more bus interfaces <NUM>, policy enforcer logic <NUM>, secure channel logic <NUM>, and/or one or more key(s) <NUM>, which are examples of bus interface(s) <NUM>, policy enforcer logic <NUM>, secure channel logic <NUM>, and key(s) <NUM> as respectively described in <FIG>. As shown in <FIG>, emergency access circuit <NUM> may further comprise a memory <NUM>, which is an example of memory <NUM>.

The process for requesting elevated privileges with respect to resource(s) <NUM> is performed in a similar manner as described above with reference to <FIG>. However, rather than retrieving a private key (for digitally signing action requests) from memory <NUM>, such a private key is obtained from access management service <NUM>.

For instance, to request elevated privileges, the user may initiate request for such privileges using application <NUM>, for example, using one or more user interface (e.g., a graphical user interface (GUI) elements that enable the user to request elevated privileges). Upon initiating the request, main processor <NUM> may execute code <NUM> of application <NUM> that causes main processor <NUM> to send a request <NUM> for elevated privileges to emergency access circuit <NUM>. Request <NUM> is received via bus interface(s) <NUM>. Bus interface(s) <NUM> provides request <NUM> to policy enforcer logic <NUM>.

Policy enforcer logic <NUM> of emergency access circuit <NUM> is configured to verify whether request <NUM> originated from an authorized user. For instance, responsive to receiving request <NUM>, emergency access circuit <NUM> may cause a prompt <NUM> to be provided to display <NUM>, via bus interface(s) <NUM>. In accordance with an embodiment, prompt <NUM> is provided directly from emergency access circuit <NUM> to display <NUM> (e.g., via bus interface(s) <NUM>). In accordance with another embodiment, emergency access circuit <NUM> provides prompt <NUM> to main processor <NUM> (e.g., via bus interface(s) <NUM>), and main processor <NUM> causes prompt <NUM> to be displayed via user interface <NUM>. Prompt <NUM> may solicit certain credentials from the user in a similar manner as described above with reference to prompt <NUM>, as described above with reference to <FIG>. Upon a user providing credentials, policy enforcer logic <NUM> verifies whether the credentials provided by the user are correct in a similar manner as described above with reference to <FIG>. Policy enforcer logic <NUM> may also perform other types of validation as described above with reference to <FIG>.

Upon successful validation, emergency access circuit <NUM> provides a request for elevated privileges to access management service <NUM>. The request is provided in a secure fashion to prevent a malicious entity from accessing the contents of request and also to ensure that the request is coming from emergency access circuit <NUM>. For instance, as shown in <FIG>, secure channel logic <NUM> may generate an encrypted request <NUM>. Secure channel logic <NUM> may generate encrypted request <NUM> using a public key of key(s) <NUM> associated with access management service <NUM>. Encrypted request <NUM> may specify an unique identifier of the user and/or computing device <NUM>, the resource of resource(s) attempting to be accessed, a uniform resource identifier (e.g., an Internet Protocol (IP) address) of computing device <NUM>, the credentials provided by the user, the location of computing device <NUM>, the network to which computing device <NUM> is connected, the hardware-based characteristics, a hash key summary, etc. Request <NUM> may be encrypted in accordance with any technique known in the art, including, but not limited to, a Rivest-Shamir-Adleman (RSA) encryption-based techniques, ElGamal encryption-based techniques, Digital Signature Standard (DSS) encryption-based techniques, etc..

Access management service <NUM> compares the information specified by request <NUM> to the information stored by a user profile of user profile(s) <NUM> identified by request <NUM>. If the information matches and request <NUM> identifies a resource of resource(s) <NUM> for which the user is authorized to request elevated privileges and further identifies an allowed action to be performed with such a resource (as specified by the user profile), access management service <NUM> determines that the user requesting elevated privileges is authorized to do so. In response to such a determination, access management service <NUM> generates a response <NUM> that comprises a private key <NUM> and indicates that the user is authorized to request elevated privileges. Private key <NUM> is an example of private key <NUM>, as described above with reference to <FIG>. Private key <NUM> may be stored in a memory (not shown) communicatively coupled to access management service <NUM>. Access management service <NUM> sends response <NUM> to emergency access circuit <NUM>, via network <NUM>, in an encrypted fashion. For example, access management service <NUM> may store a public key associated with emergency access circuit <NUM> (and corresponding to a private key of key(s) <NUM> of encrypted access circuit <NUM>) and encrypt response <NUM> using the public key. In response to determining that the information specified by request <NUM> does not match the information in the corresponding user profile of user profile(s) <NUM>, access management service <NUM> may send an encrypted response (not including private key <NUM>) to emergency access circuit <NUM>, via network <NUM>, indicating that the user is not authorized to request elevated privileges.

As further shown in <FIG>, bus interface(s) <NUM> provides encrypted response <NUM> to secure channel logic <NUM>, which decrypts encrypted response <NUM> using a private key of key(s) <NUM> associated with emergency access circuit <NUM>. Secure channel logic <NUM> may determine whether the decrypted response indicates that the user is authorized to receive elevated privileges. If a determination is made that decrypted response indicates that the user is not authorized, the user's request is denied. Optionally, an error or denial message may be displayed to the user, e.g., via user interface <NUM>. If a determination is made that the decrypted response indicates that the user is authorized, secure channel logic <NUM> obtains private key <NUM> included from response <NUM>.

Secure channel logic <NUM> utilizes the obtained private key <NUM> to encrypt and/or digitally sign an action request <NUM> for performing an action with respect to the resource of resource(s) <NUM> (identified by request <NUM>) in accordance with the elevated privileges. The digital signature of action request <NUM> assures the recipient of action request <NUM> (e.g., access management service <NUM>) of the identity of the sender (i.e., emergency access circuit <NUM>) and of the integrity of action request <NUM>. As shown in <FIG>, secure channel logic <NUM> provides access request <NUM> to bus interface(s) <NUM>, which in turn, provides access request <NUM> to network interface <NUM>. Network interface <NUM> provides action request <NUM> to access management service <NUM> via network <NUM>. Alternatively, bus interface(s) <NUM> may provide action request <NUM> to main processor <NUM>, and main processor <NUM> provides action request <NUM> to network interface <NUM>.

Upon receiving action request <NUM>, access management service <NUM> decrypts action request <NUM>, for example, using a public key associated with emergency access circuit <NUM> and corresponding to key <NUM>, and/or verifies the identity of the sender of action request <NUM> based on the digital signature. If the identity is verified, access management service <NUM> provides a command <NUM> to the resource of resource(s) <NUM> identified by action request <NUM>, and the action specified by action request <NUM> is performed. If the identity is not verified (e.g., the digital signature is incorrect), action request <NUM> is denied and the action specified by action request <NUM> is not performed.

In accordance with an embodiment, the number of times that a user is allowed to request elevated privileges is limited in a similar manner as described above with reference to <FIG>. For instance, as shown in <FIG>, memory <NUM> may comprise one or more configuration registers <NUM>, which are examples of configuration register(s) <NUM>, as shown in <FIG>. As described above with reference to <FIG>, a first configuration register of configuration register(s) <NUM> may store a maximum number of requests for elevated privileges that a user is enabled to make (e.g., via application <NUM>). A second configuration register of configuration register(s) <NUM> may function as a counter and stores the total number of requests that have been made by the user. Policy enforcer logic <NUM> may compare the value stored in the second configuration register to the maximum number value stored in the first configuration register. If the value stored in the second configuration register is less than or equal to the maximum number, then the elevated privilege request process described above is continued.

Accordingly, elevated privileges may be granted to a user based on a private key obtained from a network-based service in many ways. For example, <FIG> depicts a flowchart <NUM> of an example method performed by an integrated circuit of a computing device for obtaining elevated credentials based on a private key obtained from a network-based service in accordance with an example embodiment. The method of flowchart <NUM> will be described with continued reference to system <NUM> of <FIG>, although the method is not limited to that implementation. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the discussion regarding flowchart <NUM> and system <NUM> of <FIG>.

As shown in <FIG>, the method of flowchart <NUM> begins at step <NUM>, in which a first request for elevated user privileges with respect to a network-based resource is validated. The first request is received from a central processing unit communicatively coupled to the integrated circuit. For example, with reference to <FIG>, bus interface(s) <NUM> of emergency access circuit <NUM> receives first request <NUM> from main processor <NUM>. Request <NUM> is for elevated user privileges with respect to a network-based resource (e.g., resource(s) <NUM>). Request <NUM> may be provided by main processor <NUM> responsive to a user initiated a request for elevated privileges via application <NUM>. Bus interface(s) <NUM> provides request <NUM> to policy enforcer logic <NUM>. Policy enforcer logic <NUM> is configured to validate request <NUM>. Request <NUM> may be validated using various techniques, including the techniques described above with reference to <FIG>.

At step <NUM>, a response from the network-based service is received. The response indicates that the second request for elevated credentials is granted and comprises a private key. For example, with reference to <FIG>, access management service <NUM> determines whether second request <NUM> is from an authorized user by comparing the information specified by second request <NUM> to a corresponding profile of user profile(s) <NUM>. Responsive to determining that second request <NUM> is from an authorized user, access management service <NUM> provides a response <NUM> to computing device <NUM>. Response <NUM> includes private key <NUM>. Response <NUM> is received by network interface <NUM>. Network interface <NUM> may provide response <NUM> to bus interface(s) <NUM> of emergency access circuit <NUM>, and bus interface(s) <NUM> provides response <NUM> to secure channel logic <NUM>. Alternatively, network interface <NUM> may provide response <NUM> to main processor <NUM>, and main processor <NUM> provides response <NUM> to bus interface(s) <NUM>.

At step <NUM>, a third request, to access the network-based resource in accordance with the elevated privileges, is digitally signed using the private key. For example, with reference to <FIG>, secure channel logic <NUM> may digitally sign request <NUM> using key <NUM> obtained via response <NUM>.

The systems and methods described above, including the obtaining of elevated privileges and performing actions based thereon in reference to <FIG>, may be implemented in hardware, or hardware combined with one or both of software and/or firmware. For example, cloud services platform <NUM>, access management service <NUM>, resource(s) <NUM>, network <NUM>, and computing device <NUM>, cloud services platform <NUM>, access management service <NUM>, user profile(s) <NUM>, resource(s) <NUM>, network <NUM>, user interface <NUM>, computing device <NUM>, cloud services platform <NUM>, access management service <NUM>, user profile(s) <NUM>, resource(s) <NUM>, network <NUM>, user interface <NUM>, computing device <NUM>, and/or each of the components described therein, and flowcharts <NUM>, <NUM>, <NUM>, <NUM>, and/or flowchart <NUM> may be each implemented as computer program code/instructions configured to be executed in one or more processors and stored in a computer readable storage medium. Alternatively, cloud services platform <NUM>, access management service <NUM>, resource(s) <NUM>, and computing device <NUM>, cloud services platform <NUM>, access management service <NUM>, user profile(s) <NUM>, resource(s) <NUM>, user interface <NUM>, computing device <NUM>, main processor <NUM>, emergency access circuit <NUM>, main memory <NUM>, main processor <NUM>, emergency access circuit <NUM>, main memory <NUM>, main processor <NUM>, emergency access circuit <NUM>, main memory <NUM>, cloud services platform <NUM>, access management service <NUM>, user profile(s) <NUM>, resource(s) <NUM>, user interface <NUM>, computing device <NUM>, and/or each of the components described therein, and flowcharts <NUM>, <NUM>, <NUM>, <NUM>, and/or flowchart <NUM> may be implemented as hardware logic/electrical circuitry. In an embodiment, user interface <NUM>, computing device <NUM>, main processor <NUM>, emergency access circuit <NUM>, main memory <NUM>, main processor <NUM>, emergency access circuit <NUM>, main memory <NUM>, main processor <NUM>, emergency access circuit <NUM>, main memory <NUM>, user interface <NUM>, computing device <NUM>, and/or each of the components described therein, and flowcharts <NUM>, <NUM>, <NUM>, <NUM>, and/or flowchart <NUM> may be implemented in one or more SoCs (system on chip). An SoC may include an integrated circuit chip that includes one or more of a processor (e.g., a central processing unit (CPU), microcontroller, microprocessor, digital signal processor (DSP), etc.), memory, one or more communication interfaces, and/or further circuits, and may optionally execute received program code and/or include embedded firmware to perform functions.

<FIG> shows a block diagram of an exemplary mobile device <NUM> including a variety of optional hardware and software components, shown generally as components <NUM>. Any number and combination of the features/elements of computing device <NUM>, computing device <NUM>, display <NUM>, computing device <NUM>, display <NUM>, and/or each of the components described therein, and flowcharts <NUM>, <NUM>, <NUM>, <NUM>, and/or flowchart <NUM> may be implemented as components <NUM> included in a mobile device embodiment, as well as additional and/or alternative features/elements, as would be known to persons skilled in the relevant art(s). It is noted that any of components <NUM> can communicate with any other of components <NUM>, although not all connections are shown, for ease of illustration. Mobile device <NUM> can be any of a variety of mobile devices described or mentioned elsewhere herein or otherwise known (e.g., cell phone, smartphone, handheld computer, Personal Digital Assistant (PDA), etc.) and can allow wireless two-way communications with one or more mobile devices over one or more communications networks <NUM>, such as a cellular or satellite network, or with a local area or wide area network.

The illustrated mobile device <NUM> can include a controller or processor referred to as processor circuit <NUM> for performing such tasks as signal coding, image processing, data processing, input/output processing, power control, and/or other functions. Processor circuit <NUM> may execute program code stored in a computer readable medium, such as program code of one or more applications <NUM>, operating system <NUM>, any program code stored in memory <NUM>, etc. Operating system <NUM> can control the allocation and usage of the components <NUM> and support for one or more application programs <NUM> (a. applications, "apps", etc.). Application programs <NUM> can include common mobile computing applications (e.g., email applications, calendars, contact managers, web browsers, messaging applications) and any other computing applications (e.g., word processing applications, mapping applications, media player applications). Processor <NUM>, processor <NUM>, and processor <NUM> are examples of processor circuit <NUM>. Emergency access circuit <NUM>, emergency access circuit <NUM>, and emergency access circuit <NUM> (not shown) may be communicatively coupled to processor circuit <NUM>.

As illustrated, mobile device <NUM> can include memory <NUM>. Memory <NUM> can include non-removable memory <NUM> and/or removable memory <NUM>. The non-removable memory <NUM> can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory <NUM> can include flash memory or a Subscriber Identity Module (SIM) card, which is well known in GSM communication systems, or other well-known memory storage technologies, such as "smart cards. " The memory <NUM> can be used for storing data and/or code for running operating system <NUM> and applications <NUM>. Example data can include web pages, text, images, sound files, video data, or other data sets to be sent to and/or received from one or more network servers or other devices via one or more wired or wireless networks. Memory <NUM> can be used to store a subscriber identifier, such as an International Mobile Subscriber Identity (IMSI), and an equipment identifier, such as an International Mobile Equipment Identifier (IMEI). Such identifiers can be transmitted to a network server to identify users and equipment. Main memory <NUM>, main memory <NUM>, and main memory <NUM> are examples of memory <NUM>.

A number of programs may be stored in memory <NUM>. These programs include operating system <NUM>, one or more application programs <NUM>, and other program modules and program data. Examples of such application programs or program modules may include, for example, computer program logic (e.g., computer program code or instructions) for implementing the systems and methods described above, including the embodiments described in reference to <FIG>.

Mobile device <NUM> can support one or more input devices <NUM>, such as a touch screen <NUM>, microphone <NUM>, camera <NUM>, physical keyboard <NUM> and/or trackball <NUM> and one or more output devices <NUM>, such as a speaker <NUM> and a display <NUM>.

Other possible output devices (not shown) can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, touch screen <NUM> and display <NUM> can be combined in a single input/output device. The input devices <NUM> can include a Natural User Interface (NUI).

Wireless modem(s) <NUM> can be coupled to antenna(s) (not shown) and can support two-way communications between processor circuit <NUM> and external devices, as is well understood in the art. The modem(s) <NUM> are shown generically and can include a cellular modem <NUM> for communicating with the mobile communication network <NUM> and/or other radio-based modems (e.g., Bluetooth <NUM> and/or Wi-Fi <NUM>). Cellular modem <NUM> may be configured to enable phone calls (and optionally transmit data) according to any suitable communication standard or technology, such as GSM, <NUM>, <NUM>, <NUM>, etc. At least one of the wireless modem(s) <NUM> is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the mobile device and a public switched telephone network (PSTN).

Mobile device <NUM> can further include at least one input/output port <NUM>, a power supply <NUM>, a satellite navigation system receiver <NUM>, such as a Global Positioning System (GPS) receiver, an accelerometer <NUM>, and/or a physical connector <NUM>, which can be a USB port, IEEE <NUM> (FireWire) port, and/or RS-<NUM> port. The illustrated components <NUM> are not required or all-inclusive, as any components can be not present and other components can be additionally present as would be recognized by one skilled in the art.

<FIG> depicts an exemplary implementation of a computing device <NUM> in which embodiments may be implemented, computing device <NUM>, computing device <NUM>, display <NUM>, computing device <NUM>, display <NUM>, and/or each of the components described therein, and flowcharts <NUM>, <NUM>, <NUM>, <NUM>, and/or flowchart <NUM>. The description of computing device <NUM> provided herein is provided for purposes of illustration, and is not intended to be limiting. Embodiments may be implemented in further types of computer systems, as would be known to persons skilled in the relevant art(s).

Processor <NUM>, processor <NUM>, and processor <NUM> are examples of processor circuit <NUM>. Main memory <NUM>, main memory <NUM>, and main memory716 are examples of system memory <NUM>. Emergency access circuit <NUM>, emergency access circuit <NUM>, and emergency access circuit <NUM> (not shown in <FIG>) may be communicatively coupled to processor circuit <NUM> via bus <NUM>.

A number of program modules may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. These programs include operating system <NUM>, one or more application programs <NUM>, other programs <NUM>, and program data <NUM>. Application programs <NUM> or other programs <NUM> may include, for example, computer program logic (e.g., computer program code or instructions) for implementing the systems described above, including the device management and configuration embodiments described in reference to <FIG>.

As used herein, the terms "computer program medium," "computer-readable medium," and "computer-readable storage medium" are used to generally refer to physical hardware media such as the hard disk associated with hard disk drive <NUM>, removable magnetic disk <NUM>, removable optical disk <NUM>, other physical hardware media such as RAMs, ROMs, flash memory cards, digital video disks, zip disks, MEMs, nanotechnology-based storage devices, and further types of physical/tangible hardware storage media (including system memory <NUM> of <FIG>). Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave. Embodiments are also directed to such communication media.

Claim 1:
A method implemented by an integrated circuit (<NUM>, <NUM>) of a computing device, comprising: validating (<NUM>) a first request (<NUM>) for elevated user privileges with respect to a network- based resource, the first request received from a central processing unit (<NUM>, <NUM>) communicatively coupled to the integrated circuit (<NUM>);
providing (<NUM>) a second request (<NUM>) for the elevated privileges to a network-based service (<NUM>);
receiving (<NUM>) a response from the network-based service, the response indicating that the second request (<NUM>) for elevated credentials is granted;
responsive to receiving the response, retrieving (<NUM>) a private key (<NUM>) stored in a memory communicatively coupled to the integrated circuit;
digitally signing (<NUM>) a third request (<NUM>), to access the network-based resource in accordance with the elevated privileges, using the retrieved private key; and
providing (<NUM>) the digitally-signed request to the network-based service to access the network-based resource.