BACKGROUND

1. Field

The present disclosure relates to systems and methods for signing, encrypting and/or decrypting data for use on devices, and in particular to a system and method for authenticating and authorizing client services.

2. Description of the Related Art

Client devices often provide a variety of services ranging from distributing, installing, and updating code (e.g., onto field client devices) to licensing software. To ensure adequate security and that the services are not received from or being executed by unauthorized sources, authentication and security is required. However prior art authentication and security systems may be inadequate and/or fail to provide the level of customization/configuration that is desired. To better understand such problems of the prior art, a description or prior art client authentication and authorization services may be useful.

It is beneficial in some circumstances to provide data to devices which have already been distributed to end users (e.g. fielded devices). Such data may be needed to update the device(s) to newer configurations or to perform additional functions, to ameliorate software “bugs” or other issues, or to simply replace data already resident in the device that may have been compromised. Such data may include software instructions (e.g. code) to update fielded devices by providing data such as software code to those devices remotely.

One of the problems with the remote downloading of such data to fielded devices is that the data may be from an unauthorized source. An entity providing the data to the fielded devices may pose as a legitimate source of the data, yet provide data that is designed to compromise the security or functionality of the device. For example, the user of the device may be misled into believing that their device needs a software update in order to function properly, and may be provided a bogus uniform resource location (URL) from which to download the software update. If the user downloads and installs the software update from the bogus URL, the code that is actually downloaded may include a virus or other malware that negatively affects the operation of the device, perhaps compromising all of the data (including the user's private information) that was stored by the device before the infected.

To prevent the foregoing problems, code signing techniques can be used to digitally sign data such as executables and scripts. Such signatures confirm the identity of the author of the data and guarantee that the data has not been altered or otherwise corrupted since it was signed. Most code signing paradigms provide a digital signature mechanism to verify the identity of the author of the data or build system, and a checksum to verify that the data object has not been modified. Such code signing paradigms typically use authentication mechanisms such as public key infrastructure (PKI) technologies, which rely on data publishers securing their private keys against unauthorized access. The public key used to authenticate the data signature should be traceable back to a trusted root certificate authority (CA). If the data signature is traced to a CA that the device user trusts, the user is presumed to be able to trust the legitimacy and authorship of the data that is signed with a key generated by that CA. Such a system is referred to as a chain of trust and refers to the concept such that if the issuing CA is trusted and the chain can be traced to a trusted root certificate from that issuing CA, the entire chain is trusted and no further information/authentication is performed. However, it is undesirable to simply rely on a base trusted root certificate.

Systems for code signing are known in the art. However, such prior art code signing systems do not provide a framework that allows different organizations or companies to structure their data signing permission needs as they see fit or to safely permit data signing by other independent organizations. In other words, there may be a need/desire to customize the configuration and authentication of a software system. For example, assume Company A produces a set top box that can use a chip that can execute software from Company1or Company2. Company A may desire to establish a data signing framework that allows Company1to sign data that it installs into their set top boxes, without providing Company2with access to that data signing framework. Similarly, Company A may desire to establish a data signing framework that allows Company2to establish a data signing framework that excludes (or includes) Company1. In another example, a particular client/software provider may need to update a particular feature of a software application based on the type of end user within an organization (e.g., an administrator may be have feature while another user may have a different or fewer features). Accordingly, it is desirable to utilize a more flexible/configurable system than that of a chain based authentication system or other system of the prior art.

Alternative prior art code signing systems include the issuance of USB crypto tokens (i.e., hardware dongles) for authentication. However, the use of hardware tokens is undesirable in some scenarios.

In addition to code signing, feature licensing systems require authentication and configurable licenses for certain clients and subcategories within a client (e.g., types of users). However, prior art feature licensing systems lack configurability while ensuring security without the use of a hardware token/dongle.

In view of the above, what is needed is a system and method that provides a configurable system for the management, authentication and authorization of client services for code or configuration signing and encryption.

SUMMARY OF THE INVENTION

Embodiments of the invention overcome the problems of the prior art by providing an automated client service application that authenticates a client and authorizes a requested client service without using hardware encryption token/dongles. Embodiments utilize a client certificate that includes configuration information to provide a flexible system. In particular, a code signing server is configured with a service/operation configuration on a per/client account basis. Upon receipt of a service application request received from a client, the code signing server verifies a client certificate, checks the authorization of the client (via the service/operation configuration), and generates an appropriate authorization or authorization denial that is transmitted to the client service application via a secure communication protocol.

More specifically, embodiments of the invention provide the ability to authenticate client services. A private key and a client certificate are created for a client service application. The private key and the client certificate are delivered to and installed in an environment of the client service application. Based on the private key and the certificate, a client account is created for the client service application on a server. One or more authorized client operations are defined on the server for the client account. The client certificate and a request to perform a requested client service are received, from the client service application on the server. The request includes a server configuration identifier for the requested client service. The server verifies the client certificate at an application layer and extracts a client account ID from the client certificate. A determination is made regarding whether the client account corresponding to the client service application is authorized to perform the requested client service. Such a determination is based on the client account ID and configuration information associated with the server configuration identifier. Upon determining that the client account is authorized to perform the requested client service, the request is processed and an authorization is sent to the client service application. Upon determining that the client account is not authorized to perform the requested client service, requested client service is denied.

