TRUSTED COMPUTE ENVIRONMENT USING A SECURE ELEMENT AND DEVICE IDENTITY COMPOSITION ENGINE (DICE)

In some aspects, the techniques described herein relate to a system including: a Device Identity Composition Engine (DICE) configured to generate asymmetric key pairs for software layers of a computing system; and a secure element (SE), the secure element configured to receive requests for accessing the software layers and validating a request for a given software layer by: generating a nonce, providing the nonce and an identifier of the given software layer to the DICE, receiving a response from the DICE, and validating the response using a public key corresponding to the given software layer to allow access to the given software layer.

FIELD OF THE TECHNOLOGY

At least some embodiments disclosed herein relate generally to the security of computing systems and, in particular, securing layers of a compute environment using a combination of a secure element (SE) and Device Identity Composition Engine (DICE).

BACKGROUND

Computing systems are subject to various forms of attacks that compromise the security and integrity of these systems. In many systems, various components of a computing system may be viewed as sequentially executed layers. For example, a firmware layer executed first, followed by an operating system layer, followed by one or more application layers. Any of these layers may be compromised by either malicious software or software that contains errors. In current systems, a remote attestation server is used to validate such layers (e.g., by comparing a measurement of the installed layer with a golden measurement maintained by the server). Such approaches have numerous drawbacks including a failure to operate offline, additional compute resources (e.g., an additional server), and slow response times (due to network transmission delays), among others.

DETAILED DESCRIPTION

The example embodiments provide solutions for preventing attacks on computing systems and, in particular, to securing layers of a compute environment using a combination of an SE and DICE.

The example embodiments provide a system that includes an SE and a DICE. The SE can receive requests for accessing software layers managed by the DICE. The SE further stores public keys generated by the DICE during setup. The SE can, in response, generate a nonce and issue a challenge (e.g., request) to the DICE that include the generated nonce and a layer identifier (ID). The DICE signs the nonce and Layer ID using a private key associated with the Layer ID and returns the digital signature and, in some implementations, the nonce and Layer ID. The SE can then validate the digital signature using its stored copies of the expected public key. The SE may also validate the returned nonce and Layer ID. If all validations pass, the SE can allow access to the requested software layer. If not, the SE can deny access and take remedial measures (if implemented).

In some aspects, the techniques described herein relate to a system including: a DICE configured to generate asymmetric key pairs for software layers of a computing system; and an SE, the secure element configured to receive requests for accessing the software layers and validating a request for a given software layer by: generating a nonce, providing the nonce and an identifier of the given software layer to the DICE, receiving a response from the DICE, and validating the response using a public key corresponding to the given software layer to allow access to the given software layer.

In some aspects, the techniques described herein relate to a system, wherein the SE includes one of a trusted execution environment (TEE), Secure Enclave, or hardware security module (HSM).

In some aspects, the techniques described herein relate to a system, wherein the SE includes a write-protected storage area storing DICE public keys generated by the DICE, the DICE public keys including the public key corresponding to the given software layer.

In some aspects, the techniques described herein relate to a system, wherein the SE is configured to receive a command to store the DICE public keys from a key management server (KMS), the command signed using a private key of the KMS and verified, by the SE, using a corresponding public key of the KMS, wherein the SE is configured to read the DICE public keys from the DICE to execute the command.

In some aspects, the techniques described herein relate to a system, wherein validating the response using a public key corresponding to the given software layer includes reading the public key corresponding to the given software layer from the write-protected storage area, decrypting a digital signature included in the response to generate a decrypted result, and comparing the decrypted result to the nonce and the identifier of the given software layer to validate the response.

In some aspects, the techniques described herein relate to a system, wherein validating the response using a public key corresponding to the given software layer further includes determining if a received nonce in the response matches the nonce and if a received layer identifier matches the identifier of the given software layer prior to decrypting the digital signature.

In some aspects, the techniques described herein relate to a system, wherein the DICE is configured to receive the nonce and the identifier of the given software layer and identify a corresponding private key based on the identifier of the given software layer and generating a digital signature using the nonce and the identifier of the given software layer as a message for a digital signature algorithm.

In some aspects, the techniques described herein relate to a method including: receiving, by an SE, a request to access a software layer stored by a computing system; generating, by the SE, a nonce; transmitting, by the SE, a request to a DICE, the request including the nonce and an identifier of the software layer; receiving, by the SE, a response from the DICE; and validating, by the SE, the response using a public key corresponding to the software layer to manage access to the software layer.

In some aspects, the techniques described herein relate to a method, wherein the request to access a software layer includes a request to access a software layer managed by the DICE.

In some aspects, the techniques described herein relate to a method, wherein generating the nonce includes generating a pseudo-random value.

In some aspects, the techniques described herein relate to a method, wherein validating the response includes extracting a received nonce, a received layer identifier, and a digital signature from the response.

In some aspects, the techniques described herein relate to a method, wherein validating the response includes determining that the received nonce matches the nonce included in the request.

In some aspects, the techniques described herein relate to a method, wherein validating the response includes determining that the received layer identifier matches the identifier of the software layer included in the request.

In some aspects, the techniques described herein relate to a method, wherein validating the response includes reading the public key from a write-protected storage area, decrypting the digital signature included in the response to generate a decrypted result, and comparing the decrypted result to the nonce included in the request and the identifier of the software layer included in the request.

In some aspects, the techniques described herein relate to a method, wherein validating the response using a public key corresponding to the software layer to manage access to the software layer includes disallowing access to the software layer if: the received nonce does not match the nonce included in the request; the received layer identifier does not match the identifier of the software layer included in the request; or the decrypted result does not match the nonce included in the request and the identifier of the software layer included in the request.

In some aspects, the techniques described herein relate to a method, wherein validating the response using a public key corresponding to the software layer to manage access to the software layer includes executing the software layer by a processing device.

In some aspects, the techniques described herein relate to a method including: receiving, at a computing device, a request from an SE, the request including a nonce and a layer identifier; loading, by a computing device, a private key corresponding to the layer identifier; generating, by a computing device, a digital signature using a digital signature algorithm, the digital signature generated by using the nonce and the layer identifier as a message input into the digital signature algorithm; and returning, by a computing device, the digital signature to the SE.

In some aspects, the techniques described herein relate to a method, wherein the private key includes a private key generated by a DICE.

In some aspects, the techniques described herein relate to a method, wherein the private key is generated on startup of the computing device.

In some aspects, the techniques described herein relate to a method, further including receiving a request from the SE for public keys and returning the public keys to the SE.

FIG.1is a block diagram of a secure compute environment according to some embodiments of the disclosure.

In the illustrated computing system, a DICE102and SE104are communicatively coupled. As illustrated, the DICE102includes a signature generator106, layer selector108, and key storage110. The key storage110includes various keys including L0 keys112, L1 keys114, and L2 keys116(certainly more keys may be included and the specifically illustrated number is not limiting). The SE104includes a key loader118, key storage120, signature validator132, nonce generator134, layer validator136, and interface138. As illustrated, the key storage120may include various keys including an L0 key122, an L1 key124, an L2 key126, SE keys128, and a KMS public key130(certainly more keys may be included and the specifically illustrated number is not limiting). Various details of these components are described in more detail herein.

In an implementation, the DICE102and SE104may both be implemented as secure elements. Examples of a secure element include a Secure Enclave, a Hardware Security Module (HSM), a Trusted Execution Environment (TEE), a Trusted Platform Module (TPM), Secure Element in the Cloud (SEiC), or similar type of secure processing device. In some implementations, the DICE102and SE104may be the same secure element (i.e., implemented in a single TEE or other type of SE). When implemented as separate SEs, the DICE102and SE104can communicate via a secure interface (not illustrated). When implemented in the same SE, the DICE102and SE104can communicate using an internal message bus of the SE.

Both the DICE102and SE104include key storage areas (key storage110and key storage120, respectively). In both devices, these areas may comprise secure storage areas within an SE. Such storage areas may not be accessible without issuing verified commands to the respective devices. For example, these storage areas may comprise write-protected storage locations within a security perimeter of the SE. Both secure storage areas store cryptographic secrets such as asymmetric keys. Asymmetric keys may comprise public and private cryptographic keys generated using an algorithm such as Rivest-Shamir-Adleman (RSA), Elliptic Curve Digital Signature Algorithm (ECDSA), Elliptic-curve Diffie-Hellman (ECDH), ElGamal, or similar algorithms. While ECDSA is generally used in the description, the disclosure is not limited to a specific asymmetric algorithm.

In key storage110, the DICE102stores the various asymmetric key pairs for each layer protected by the DICE (e.g., L0 keys112, L1 keys114, L2 keys116, etc.). While three layers are illustrated, there is no limit to the number of layers managed by DICE102. Further, the DICE102may only protect a subset of software executed by a computing device and need not manage all software. For example, critical applications or firmware may be protected via DICE102while non-critical software may not. In some implementations, L0 keys112, L1 keys114, L2 keys116may comprise asymmetric key pairs (e.g., public key and private key) for each layer.

The DICE102may prevent access to the private key portions of these keys but may allow access to the public key portions. For example, SE104may utilize a key loader118to access the public keys and store L0 keys112, L1 keys114, L2 keys116in its own secure area (key storage120), illustrated as L0 key122, L1 key124, and L2 key126. Notably, L0 key122, L1 key124, and L2 key126comprise the public key portions of L0 keys112, L1 keys114, L2 keys116.

The key loader118may comprise firmware or software executing in SE104to receive a signed command (e.g., from a KMS) to load the public keys from DICE102into key storage120. The key loader118may verify such a command by reading a KMS public key130and validating the command before requesting the DICE102provide the L0 keys112, L1 keys114, L2 keys116to the SE104. Details of this process are described more fully inFIG.2. In some implementations, the key storage120may further include the asymmetric key pair(s) of the SE104itself (e.g., SE keys128) which can be used to prove the identity of SE104(e.g., via digital signature).

The SE104further includes interface138which can receive requests for layers from other parts of the computing system. For example, a general purpose processor may issue requests (via the OS or firmware) to load and execute software (e.g., via filenames or memory locations) corresponding to the layers of DICE102. A layer validator136may receive such requests and transmit the Layer ID of the requested layer to nonce generator134which generates a random or pseudo-random nonce value that is transmitted (along with the Layer ID) to the DICE102. The DICE102includes a layer selector108that receives the nonce and Layer ID and can select the corresponding public key from L0 keys112, L1 keys114, L2 keys116. The signature generator106can generate a digital signature using the selected public key and the nonce and, in some implementations, Layer ID. The signature generator106can then return the digital signature (and nonce and Layer ID) to a signature validator132which can validate the digital signature and the nonce and Layer ID. If the signature validator132validates all data, the layer validator136can return a success message which allows access to the requested layer. Alternatively, if the signature validator132cannot validate all data the layer validator136may return an error which disallows access. In some implementations, layer validator136, nonce generator134and signature validator132may be implemented in software or firmware instructions executed by a controller or processor of the SE104. Similarly, signature generator106and layer selector108may also be implemented in software or firmware instructions executed by a controller or processor of the DICE102. Functional operations of these components are described more fully inFIG.3(operations of SE104) andFIG.4(operations of DICE102).

FIG.2is a flow diagram illustrating a method for loading DICE public keys into an SE according to some embodiments of the disclosure.

In step202, the method can include generating one or more DICE keys. In some implementations, step202may be implemented as part of the startup as a DICE-enabled system and the details of a standard-compliant DICE system are not repeated herein.

In brief, a DICE-enabled computing system may include various layers of functionality. In some implementations, these layers may include software layers, firmware layers, or even hardware layers that perform functions of the computing system. When such a system executes, the layers are generally executed in sequential order, although in some implementations, each layer may include multiple sub-layers. For example, a hardware circuit may comprise a DICE core root of trust that boots to a Layer 0 (L0) firmware, which boots to a Layer 1 (L1) operating system, which then executes one or more Layer 2 (L2) software applications (e.g., mail clients, web browsers, etc.). The specific nature of the software layers or their amount is not limiting.

In a DICE system, during startup each layer is associated with a set of keys. This set of keys includes at least one asymmetric key pair. An asymmetric key pair will include a public key and a private key. In a DICE system, these key pairs are generated in part on data associated with a previous layer, which ensures the integrity of the system. Details of such cascading key generation are part of the DICE standard and are not repeated herein. For purposes of the following description, it can be assumed that during startup (or at other times), such a DICE system will generate at least one asymmetric key pair for each layer measured by the DICE system.

In step204, the method can include receiving a key load command.

In some implementations, the key load command may be received over a network from a KMS. In some implementations, the key load command may be a command having a predetermined opcode or identifier and a body. In some implementations, the key load command may be signed using a cryptographic key. In some implementations, the cryptographic key may be a private key of an asymmetric key pair. In some implementations, this asymmetric key pair can be generated and stored by the KMS.

For example, in some implementations a KMS may generate an asymmetric key pair using an algorithm such as an RSA, ECDSA, ECDH, ElGamal, or similar algorithm. The KMS may keep its private key secret and issue signed key load commands to a computing device such as that depicted inFIG.1. In some implementations, the computing device may request the key from the KMS. In other implementations, the KMS can issue the command on its own.

In step206, the method can include determining if the key load command is valid.

Upon receipt of the key load command, the receiving computing device can read a public key corresponding to the private key used to sign the key load command and validate that the command was signed using the expected private key. For example, an SE may store the KMS public key in a write-protected area and use this KMS public key to validate the key load command. In some implementations, step206can include using a digital signature verification routine provided by an asymmetric cryptography algorithm such as RSA or ECDSA. The specific details of this process are not limiting. For example, the method can include decrypting the signature and comparing the result to the key command itself (either the command or a hash thereof).

In step208, if the signature validation fails, the method can ignore the command and halt any further processing. In this manner, only an authorized entity (e.g., the holder of the private key corresponding to the stored public key) can cause the system to transfer DICE keys.

In step210, alternatively, if the key load command is validly signed, the method can load the DICE public keys into an SE. In some implementations, the SE may issue a command to the DICE to retrieve all public keys that are generated during the DICE process. As discussed above, this may include L0, L1, . . . LN public keys generated by the DICE. The DICE may return the public keys to the SE and the SE can store the public keys in the write-protected storage area or a similar secure location. In some implementations, the DICE may freely provide access to any public keys generated during the DICE process. In other embodiments, the SE may forward the signed key load command and the DICE, which may store the KMS public key, may additionally validate the key load command.

At the competition of the method, the SE may thus store the KMS public key, the DICE public keys, as well as its own personal asymmetric key pair. As will be described next, these DICE public keys may be used to authenticate requests to access the various software layers secured by the DICE.

FIG.3is a flow diagram illustrating a method for validating access to a software layer according to some embodiments of the disclosure.

In step302, the method can include receiving a request to access a software layer. In some implementations, this access can be executing a layer, reading the contents of a layer, or generally performing any operation on the software layer. In some implementations, the request can be received by an SE from another layer or another process executing on a computing device.

In step304, the method can include generating a nonce.

In some implementations, the nonce can comprise a random or pseudo-random value. In some implementations, the SE can use a hardware random number generator (HRNG) which may be a physical device that generates truly random numbers by measuring natural phenomena such as electronic noise. Alternatively, or in conjunction with the foregoing, the SE can use a pseudorandom number generator (PRNG). A PRNG is a software-based algorithm that generates a sequence of numbers that appears to be random but are not truly random. PRNGs are typically seeded with an initial value, such as the current time or a hardware sensor reading, to ensure that the generated numbers are unique. In some implementations, a combination of an HRNG and PRNG may be used (e.g., using the HRNG to seed a PRNG). In alternative implementations, a monotonic counter or similar mechanism may be used to generate a nonce. In some implementations, a timestamp (which is not random, but may be sufficiently unique) may be used as a nonce.

In step306, the method can include transmitting the nonce and a Layer ID to the DICE.

In some implementations, the Layer ID may be received as part of step302. For example, the request to access a layer may include the Layer ID. In other embodiments, the method can include identifying the Layer ID based on the requested layer. For example, a table or similar type of lookup may map filenames and/or memory addresses to layer IDs. Thus, if the request in step302includes a filename (e.g., application executable), the method can include looking up the Layer ID. Similarly, if the request includes a memory location (e.g., in the case of firmware), the method can look up the Layer ID for the memory address.

In step308, after a short time, the method will receive a response from the DICE. If it does not (not illustrated), the method will terminate and branch immediately to step312. Presuming, however, that the DICE responds, in step308, the method will receive this response which will generally include responsive data which should include at least a digital signature. In some implementations, as well, the response may also include a received Layer ID and received nonce. In some implementations, this digital signature is generated by the DICE (described inFIG.4) and is computed using a digital signature algorithm such as an ECDSA algorithm. Specifically, the DICE can read a private key corresponding to the Layer ID and sign a message using the private key. This message may be the concatenation (or other combination) of the nonce and Layer ID sent in step306. Alternatively, the message may be either the nonce or Layer ID sent in step306.

In step310, the method can include determining if the response actually includes a signature. If not, the method immediately branches to step312where access to the layer requested in step302is disallowed. In this scenario, the method determines that the DICE is not functioning properly or is compromised in some manner as it did not generate a signature at all. In some implementations, step312can include returning an error to the calling device and preventing the software layer from being accessed (e.g., executed). In some implementations, step312can also include taking remedial measures with respect to the requested layer. For example, the computing system may include golden images of trusted software layers and step312may include rolling back the requested layer to the golden image (i.e., a trusted state). Alternatively, or in conjunction with the foregoing, step312can include logging the error or issuing an alert or notification to a computing device or user that may take action (e.g., re-installing software, etc.).

If, on the other hand, a signature is included in the response, the method proceeds to step314where the method validates the nonce and Layer ID. As discussed, step314and step316may be optional and only executed if one or both of a received nonce and received Layer ID are included in the response. If they are, the method will compare the received nonce and received Layer ID to the nonce generated in step304and the Layer ID transmitted in step306. In this step, the method can ensure that the DICE is operating correctly and the nonce and Layer ID were not corrupted during transmission in step306. Further, validation of the nonce prevents replay attacks for a given layer. Specifically, if only a Layer ID were signed, this signature could be cached and re-used despite the private key associated with the layer being removed. As such, if an attacker were to remove the private keys from the DICE, it could not validly sign a nonce value.

If the nonce and Layer ID (if included) are valid, the method proceeds to step318where it validates the digital signature included in the response. In some embodiments, step318can include using an ECDSA or similar type of signature algorithm to validate the signature. Then, in step320, the results of validating the digital signature can be analyzed.

In some implementations, in step318, the method may use a corresponding public key, which corresponds to the Layer ID and the private key used to generate the digital signature, to verify the digital signature. Using the method ofFIG.2, an SE can store an expected set of public keys that correspond the DICE layers and can store these public keys in a write-protected storage region. Thus, the DICE must sign a given layer using the correct private key and tampering can be prevented.

If the signature is determined valid in step320, it confirms that the response is authentic and came from the DICE using the expected asymmetric key pair. As such, the method can proceed to step322where it will allow access to the requested layer. As described above, this may include executing, reading, or otherwise processing the underlying software, firmware, or hardware layer.

Alternatively, if the signature is not valid, it indicates that the response may have been tampered with or did not come from the intended source, and the method will terminate and branch to step312, as discussed above.

In some implementations, the above method may be used any time a secure access to a layer is desired. In some computing systems, access to layers may either be secured (via the method) or unsecured (bypassing the method) depending on the needs of the system. As an example, an operating system (OS) may receive a request to launch an email client. The OS may issue a request to the SE (step302) which generates a nonce (step304) and transmits the nonce and Layer ID to the DICE (step306). The DICE generates a response (FIG.4) and returns a digital signature (as well as nonce and Layer ID in some implementations) to the SE (step308). The SE then checks if the digital signature is present (step310), validates the nonce and Layer ID (step314), and validates the digital signature (step318). If any of these checks fail (step310, step316, step320), the SE will disallow access to the layer (step312) by, for example, returning an error to the OS. Alternatively, if all checks pass, the SE will allow access to the layer (step322) by, for example, returning a success message or providing the contents of the layer itself to the OS.

FIG.4is a flow diagram illustrating a method for signing a request to access a software layer according to some embodiments of the disclosure.

In step402, the method can include a DICE receiving a nonce and Layer ID from an SE. In some implementations, this nonce and Layer ID can be generated by the method ofFIG.3and transmitted to the DICE in step306.

In step404, the method can include loading a private key for the received Layer ID.

In some implementations, the DICE can include a write-protected or otherwise secure area of memory that stores asymmetric key pairs for each layer protected by the DICE. When receiving a Layer ID, the processor of the DICE can read this secure area and retrieve a private key that corresponds to the received Layer ID. If no such key exists, the DICE can return an error or empty response which will trigger the method ofFIG.3to disallow layer access (step312).

In step406, the method can include signing the Layer ID and nonce with the private key retrieved in step404. In some alternative implementations, only the nonce or Layer ID may be signed. In general, however, the nonce may be used in the signature to ensure freshness and prevent relay attacks. If both are used, the nonce and Layer ID may be concatenated to form a message input into a digital signature algorithm such as ECDSA.

In step408, the method can include returning the digital signature generated using a digital signature algorithm in step406. In some implementations, the method may only return the digital signature. In other implementations, the method may also return the data received in step402(e.g., the nonce and/or Layer ID). As discussed in the description ofFIG.3, this response (received in step308) may then be verified and used to control access to the underlying layers of the DICE.

FIG.5is a block diagram illustrating a computing system according to some embodiments of the disclosure.

As illustrated inFIG.5, a computing system500includes a host processor520communicatively coupled to a memory device502via a bus504. The memory device502comprises a controller506communicatively coupled to one or more memory banks (e.g., banks508A-508N, etc.) forming a memory array via an interface512. As illustrated, the controller506include es a local cache514, firmware516, and an ECC module518.

In the illustrated embodiment, host processor520can comprise any type of computer processor, such as a central processing unit (CPU), graphics processing unit (GPU), or other types of general-purpose or special-purpose computing devices. The host processor520includes one or more output ports that allow for the transmission of address, user, and control data between the host processor520and the memory device502. In the illustrated embodiment, this communication is performed over the bus504. In one embodiment, the bus504comprises an input/output (I/O) bus or a similar type of bus.

The memory device502is responsible for managing one or more memory banks (e.g., banks508A-508N, etc.). In one embodiment, the memory banks (e.g., banks508A-508N, etc.) comprise NAND Flash dies or other configurations of non-volatile memory. In one embodiment, the memory banks (e.g., banks508A-508N, etc.) comprise a memory array.

The memory banks (e.g., banks508A-508N, etc.) are managed by the controller506. In some embodiments, the controller506comprises a computing device configured to mediate access to and from banks (e.g., banks508A-508N, etc.). In one embodiment, the controller506comprises an ASIC or other circuitry installed on a printed circuit board housing the memory banks (e.g., banks508A-508N, etc.). In some embodiments, the controller506may be physically separate from the memory banks (e.g., banks508A-508N, etc.). The controller506communicates with the memory banks (e.g., banks508A-508N, etc.) over the interface512. In some embodiments, this interface512comprises a physically wired (e.g., traced) interface. In other embodiments, the interface512comprises a standard bus for communicating with memory banks (e.g., banks508A-508N, etc.).

The controller506comprises various modules including local cache514, firmware516and ECC module518. In one embodiment, the various modules (e.g., local cache514, firmware516and ECC module518) comprise various physically distinct modules or circuits. In other embodiments, the modules (e.g., local cache514, firmware516and ECC module518) may completely (or partially) be implemented in software or firmware.

As illustrated, firmware516comprises the core of the controller and manages all operations of the controller506. The firmware516may implement some or all of the methods described above. Specifically, the firmware516may implement the methods described in the foregoing figures.

FIG.6is a block diagram of a computing device according to some embodiments of the disclosure.

As illustrated, the device600includes a processor or central processing unit (CPU) such as CPU602in communication with a memory604via a bus614. The device also includes one or more input/output (I/O) or peripheral devices612. Examples of peripheral devices include, but are not limited to, network interfaces, audio interfaces, display devices, keypads, mice, keyboard, touch screens, illuminators, haptic interfaces, global positioning system (GPS) receivers, cameras, or other optical, thermal, or electromagnetic sensors.

In some embodiments, the CPU602may comprise a general-purpose CPU. The CPU602may comprise a single-core or multiple-core CPU. The CPU602may comprise a system-on-a-chip (SoC) or a similar embedded system. In some embodiments, a graphics processing unit (GPU) may be used in place of, or in combination with, a CPU602. Memory604may comprise a memory system including a dynamic random-access memory (DRAM), static random-access memory (SRAM), Flash (e.g., NAND Flash), or combinations thereof. In one embodiment, the bus614may comprise a Peripheral Component Interconnect Express (PCIe) bus. In some embodiments, the bus614may comprise multiple busses instead of a single bus.

Memory604illustrates an example of a non-transitory computer storage media for the storage of information such as computer-readable instructions, data structures, program modules, or other data. Memory604can store a basic input/output system (BIOS) in read-only memory (ROM), such as ROM608for controlling the low-level operation of the device. The memory can also store an operating system in random-access memory (RAM) for controlling the operation of the device.

Applications610may include computer-executable instructions which, when executed by the device, perform any of the methods (or portions of the methods) described previously in the description of the preceding figures. In some embodiments, the software or programs implementing the method embodiments can be read from a hard disk drive (not illustrated) and temporarily stored in RAM606by CPU602. CPU602may then read the software or data from RAM606, process them, and store them in RAM606again.

The device may optionally communicate with a base station (not shown) or directly with another computing device. One or more network interfaces in peripheral devices612are sometimes referred to as a transceiver, transceiving device, or network interface card (NIC).

An audio interface in peripheral devices612produces and receives audio signals such as the sound of a human voice. For example, an audio interface may be coupled to a speaker and microphone (not shown) to enable telecommunication with others or generate an audio acknowledgment for some action. Displays in peripheral devices612may comprise liquid crystal display (LCD), gas plasma, light-emitting diode (LED), or any other type of display device used with a computing device. A display may also include a touch-sensitive screen arranged to receive input from an object such as a stylus or a digit from a human hand.

A keypad in peripheral devices612may comprise any input device arranged to receive input from a user. An illuminator in peripheral devices612may provide a status indication or provide light. The device can also comprise an input/output interface in peripheral devices612for communication with external devices, using communication technologies, such as USB, infrared, Bluetooth®, or the like. A haptic interface in peripheral devices612provides tactile feedback to a user of the client device.

A GPS receiver in peripheral devices612can determine the physical coordinates of the device on the surface of the Earth, which typically outputs a location as latitude and longitude values. A GPS receiver can also employ other geo-positioning mechanisms, including, but not limited to, triangulation, assisted GPS (AGPS), E-OTD, CI, SAI, ETA, BSS, or the like, to further determine the physical location of the device on the surface of the Earth. In one embodiment, however, the device may communicate through other components, providing other information that may be employed to determine the physical location of the device, including, for example, a media access control (MAC) address, Internet Protocol (IP) address, or the like.

The device may include more or fewer components than those shown inFIG.6, depending on the deployment or usage of the device. For example, a server computing device, such as a rack-mounted server, may not include audio interfaces, displays, keypads, illuminators, haptic interfaces, Global Positioning System (GPS) receivers, or cameras/sensors. Some devices may include additional components not shown, such as graphics processing unit (GPU) devices, cryptographic co-processors, artificial intelligence (AI) accelerators, or other peripheral devices.

The subject matter disclosed above may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein; example embodiments are provided merely to be illustrative. Likewise, a reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, or systems. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, or any combination thereof (other than software per se). The preceding detailed description is, therefore, not intended to be taken in a limiting sense.

Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in an embodiment” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter include combinations of example embodiments in whole or in part.

These computer program instructions can be provided to a processor of a general purpose computer to alter its function to a special purpose; a special purpose computer; ASIC; or other programmable digital data processing apparatus, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, implement the functions or acts specified in the block diagrams or operational block or blocks, thereby transforming their functionality in accordance with embodiments herein.