Patent Application
20220078026
Distributed computing may allow a central data server to break a computing task into multiple workloads for execution by a distributed set of endpoints. The central data server may base the workloads for an individual endpoint based on the resources available to the endpoint.
Various examples will be described below referring to the following figures:
Execution of distributed workloads may pose a security risk to the endpoints executing the workloads. Malicious code may be present in the workload or a workload may be presented for execution from a source other than an authorized central data server.
The central data server may digitally sign workloads using a public and private key pair. The endpoint may verify the signature of the workload to know the workload has been provided by an authorized central data server. The cryptographic keys used by the authorized central data server may be specific to the endpoint being provided with the workload.
In various examples, the security chip 130 may include a trusted platform module. The workload may be signed by the private key of a public-private key pair. The security chip 130 may use the public key to verify the signature of the workload. The signature of the workload may be an encryption of the workload using the private key, an encryption of a hash of the workload using the private key, or other appropriate signature to allow the security chip 130 to verify the workload has not been modified and the workload was provided by the trusted source.
In various examples, while the central data server may sign the workload with the private key, the private key may actually belong to or correspond to the apparatus 100. During manufacture, the private key may be prepared for the apparatus and stored by the central data server. The public key and possibly the private key may be stored in the security chip 130. The central data server may use the private key to sign workloads or other communications with the apparatus 100. When communicating with other endpoints, the central data server may use a different private key corresponding to the other endpoints or the security chips in those endpoints.
If the security chip 130 verifies the signature of the workload, the processor 110 may execute or process the workload. The workload may include machine-readable instructions for execution by the processor 110. The workload may include data for manipulation by the processor 110, based on the machine-readable instructions in the workload or based on existing machine-readable instructions stored in the apparatus 100. If the security chip 130 cannot verify the signature of the workload, the workload may not be executed or processed. The workload may have come from a source other than the authorized central data server, or the workload may be from the authorized central data server but signed using a private key for a different endpoint. The other endpoint should be receiving and handling the workload, rather than the apparatus 100.
In addition to verifying the signature of the workload, a workload authorization setting may be checked before executing or handling the workload. The workload authorization setting may be settable by a user of the apparatus 100 to control whether the apparatus 100 is accepting workloads for execution or handling. In various examples, the workload authorization setting may be checked before verifying the signature of a workload. When the workload authorization setting specifies that workloads are not being accepted, the apparatus 100 may send a message to the authorized central data server rejecting the workload. To prevent communication of workloads over the network interface connector 120 when workloads are not being accepted, the apparatus 100 may send such a message to the authorized central data server when the workload authorization setting is modified.
In various examples, the public-private key pair may correspond to multiple endpoints. The size and groupings of these endpoints may be arbitrary. A set of endpoints owned and operated by one business may use the same public-private key pair. Any workload sent to one of these endpoints may be signed using the same private key. The workloads may still be sent to specific endpoints for processing.
In various examples, the security chip 130 may be used to perform verification of the operating system of the apparatus 100 or applications executing on the processor 110. During startup, the security chip 130 may perform a secure boot, verifying that the operating system has not been modified from a known good state. Modification of the operating system may indicate the presence of a disruptive application, such as a virus or trojan. The security chip 130 may also verify applications to execute on the processor 110. The application that handles the workloads may be one such application verified by the security chip 130. Verification of the operating system, application, and workload may provide additional protection against execution of malicious code on the apparatus 100. The operating system and application may be stored in a computer-readable medium coupled to the processor. The computer-readable medium may include a hard drive, solid state drive (SSD), flash memory, electrically erasable programmable read-only memory (EEPROM), or random access memory (RAM).
In various examples, the security chip 130 may update the public-private key pair used to verify the workloads. The new public or private key may be received via the network interface connector 120 or via a removable medium, such as a USB memory stick. The security chip 130 may include provisions to verify that the update of the public-private key is authorized so as to prevent use of the update process to provide a public-private key pair from an unauthorized central data server.
In various examples, the computer-readable medium 140 may include memory that is part of the security chip 130 and main memory or long-term memory of the apparatus 100, such as RAM or a SSD. The machine-readable instructions 143 may be stored in the long-term memory. The workload authorization setting 146 may be stored in the long-term memory or in memory that is part of the security chip 130. The workload authorization setting 146 may be stored in a registry of the apparatus 100.
In various examples, a user may modify the workload authorization setting 146. A user may supply a password when modifying the workload authorization setting 146. Modification of the workload authorization setting 146 may be limited to certain users or certain groups of users, such as by an administrator. The workload authorization setting 146 may specify that workloads are authorized from certain central data servers but not from others, regardless of whether the workloads are properly signed. The workload authorization setting 146 may restrict handling of workloads to workloads that use or do not use certain resources of the apparatus 100. The workload authorization setting 146 may include a timer, where the authorization to handle workloads ends upon expiration of the timer, or where the restriction against handling workloads ends upon expiration of the timer. The workload authorization setting 146 may be based on a calendar or clock. For example, the workload authorization setting 146 may allow handling of workloads during times when the apparatus is otherwise in off-peak usage, such as the middle of the night or on weekends.
In various examples, the processor may check a state of the workload authorization setting before handling the workload. If the workload authorization setting indicates that workloads are not authorized, the processor may delete the workload without verifying or executing or otherwise handling the workload. The processor may send a message to the central data server indicating the workload was rejected. The message may include an indication of the reason for rejection.
In various examples, the processor may verify the workload before executing the workload. The verification of the workload by the processor may be in addition to verification of the workload using the public key. The processor may verify that the workload actually contains content that the processor can process.
In various examples, the central data server may encrypt the workload using the private key. Verification of the workload using the public key may include decrypting the workload with the public key.
In various examples, an endpoint may use a first public key to verify a workload is intended for that endpoint and comes from an authorized central data server. The public-private key pair corresponding to that endpoint may be updated to a second public-private key pair, at which point, the endpoint may use the second public key to verify incoming workloads.
In various examples, when the central data server is to send a second workload to a second endpoint, the central data server may assemble the second workload. The central data server may sign the second workload using a second public-private key pair that corresponds to the second endpoint. The second workload may be transmitted to the second endpoint. On receipt, the second endpoint may use the public key of its public-private key pair to verify that the workload is from the authorized central data server and that the workload is meant for the second endpoint. If the first endpoint were to receive the second workload, the signature would not be verified, as it uses a different public-private key pair. In such circumstances, the first endpoint may not handle the second workload.
In various examples, the central data server may send a third workload to a third endpoint using the public-private key of the first endpoint. The first and third endpoint may share the public-private key pair. The central data server may assemble the third workload. The central data server may sign the third workload using the private key, which corresponds to both the first endpoint and third endpoint. The central data server may transmit the third workload to the third endpoint. If the first endpoint receives the third workload, the signature would be verifiable using the public key, and the first endpoint may handle the third workload. Handling of a workload by multiple endpoints that share a public-private key pair may be desired in some cases. For example, the central data server may want a workload to be handled quickly and provide the workload to multiple endpoints, using the results of the first completed workload. The central data server may use the multiple endpoints for redundancy checking, ensuring that the endpoints agree on the results.
In various examples, an endpoint may register itself with the central data server. The registration may notify the central data server that the endpoint may be used for distributed computing. As part of registration, the endpoint may provide information regarding the resources of the endpoint. The resources may include processing ability, available short-term or long-term memory, or peripheral devices. In assembling workloads, the central data server may match the workload with the resources available to an endpoint. When a match is made, the central data server may assemble a workload specific to the endpoint.
In various examples, the endpoints may be used as part of the distributed computing network when otherwise not in use. The endpoint may communicate with the central data server to indicate when the endpoint is idle and ready to receive workloads. The endpoint may communicate with the central data server to indicate the endpoint will no longer accept workloads due to local activities of the endpoint, such as when a user begins using a computer. The endpoint may communicate with the central data server when the workload authorization setting of the endpoint changes. The central data server may begin sending workloads to the endpoint in response to the indication that the endpoint is ready to receive workloads. The central data server may halt the sending of workloads when the endpoint indicates it is being used locally.
Verification of the signatures of workloads allows the endpoints control over their use as distributed computing devices. Multiple central data servers may exist, such as from different companies providing distributed computing services. Through cryptography, an endpoint may ensure that a workload was provided by an authorized central data server. The endpoint determines whether the central data server is authorized and may still decline to process workloads from an authorized central data server. Workloads from unauthorized central data servers, or even from an authorized central data server but signed using a different endpoint's private key, may not be executed by the endpoint.
In various examples, an endpoint may sign up to be a distributed computing device for multiple central data servers. The central data servers may use the same public-private key pair for communication with the endpoint, as the key pair belongs to the endpoint, or different public-private key pairs may be used for communication with the different central data servers.
In various examples, an endpoint may remove itself from the distributed computing network by removing or disabling its copy of the public-private key pair. This may be performed when retiring a computing device from a fleet of computing devices operated by a company. This may also be done when reconfiguring a fleet of computing devices that use the same public-private key pair for communications with the central data server. Individual computing endpoints may be added or removed by temporarily, or permanently, disabling the key pair in the individual endpoint.
In various examples, the results of handling the workload may be returned to the central data server from the endpoint. The endpoint may use the same public-private key pair to sign or encrypt the response. Additional tracking may be performed by the endpoint or the central data server to provide for billing or payments for use of the endpoint in the distributed computing network.
The above discussion is meant to be illustrative of the principles and various examples of the present disclosure. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2019/030017 | 4/30/2019 | WO | 00 |
