Optimized Key Management for Data Signing Systems

The present application is a continuation of U.S. patent application Ser. No. 18/090,851, filed Dec. 29, 2022, which claims priority to U.S. Provisional App. No. 63/294,845 filed Dec. 30, 2021, the content of which is incorporated herein by reference in its entirety.

The present invention relates to systems and methods for signing data for use on devices, and in particular to a system and method for providing distributed data signing services.

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 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 it was 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.

In such code signing systems, the signing and encryption keys are typically stored in a secure hardware security module (HSM). Key generation and clear key handling require multiple person integrity to ensure security and an audit trail. Such multi-person audited events are called “key ceremonies.” If multiple HSMs are used in different environments (development, quality assurance, and production, for example), backing up and restoring keys stored in the HSMs are needed to propagate the new keys to all HSMs, especially if they are on different networks. Otherwise, repeated key ceremonies need to be performed for each HSM. All these activities are labor intensive.

What is needed is a system and method to create and back up such keys.

To address the requirements described above, this document discloses a system and method for providing a security credential, for example a credential that can be used to sign, encrypt, or decrypt data. In one embodiment, the method comprises accepting a request to generate at least one key in an online data signing system; generating, in a hardware security module communicatively coupled to the online data signing system, a first key Kas a temporary object; encrypting, by the hardware security module, the first key Kaccording to a wrapping key Kw to produce an encrypted first key E[K]; storing the encrypted first key; and providing a second key Kassociated with the first key Kto a user device communicatively coupled to the online data signing system. In another embodiment, the method further comprises linking, in the online data signing system, a configuration defined by an administrator to the encrypted first key E[K]; accepting, in the online data signing system, a request from the user device to perform a cryptographic operation on data according to the configuration; retrieving the encrypted first key from storage; decrypting, in the hardware security module, the encrypted first key according to the wrapping key Kw to recover the first key Kas a further temporary object; performing the cryptographic operation on the data in the online data signing system according to the first key K; and providing a result of the cryptographic operation to the user device.

Another embodiment is evidenced by an apparatus having a processor and a communicatively coupled memory storing processor instructions for performing the foregoing operations.

The features, functions, and advantages that have been discussed can be achieved independently in various embodiments of the present invention or may be combined in yet other embodiments, further details of which can be seen with reference to the following description and drawings.

In the following description, reference is made to the accompanying drawings which form a part hereof, and which is shown, by way of illustration, several embodiments. It is understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present disclosure.

Described below is a system and method of providing keys that can be used for security credentials. In this system and method, new keys are generated in the HSM itself and are encrypted (e.g. wrapped) for backup external to the HSM. To achieve this, the ODSSincludes additional functionality to generate a new key as a session object in an HSM partition of the system. The new key is wrapped with a global wrapping key and stored to the database of the data signing system.

The keys are then unwrapped to the HSM when needed. For asymmetric keys (e.g., RSA or ECDSA, El Gamal, and NTRU), the public key associated with the private key is permitted to be downloaded by the client. For symmetric keys, the same symmetric key is permitted to be downloaded, preferably encrypted with user's public key. For the case where a CVC (Code Verification Certificate) needs to be issued based on the public key, a CSR (Certificate Signing Request) is generated and allowed to be downloaded.

is a diagram depicting an exemplary ODSS. The ODSS frontendis a Graphic User Interface (GUI) layer that is the presentation layer for the ODSS. The ODSS frontendis hosted on a server that is behind a firewallto protect against unnecessary or unauthorized access. The ODSS frontendcomprises a web portal interfacethat implements the presentation (e.g. “look and feel”) of functionality of the ODSSto the user. As described below, usersmay include human usersH, which comprise a human or personand a human user deviceH or a machine userM, which comprises a machine user deviceM. Hereinafter, the term useris used to refer collectively to either a human userH or a machine userM, and the term user deviceH is used to refer collectively to either a human user deviceH or a machine user deviceM. Preferably, the ODSS frontenddoes not enforce signing permissions, perform any signing or key generation activities, or define the hierarchy of the entities discussed below or how the access to such entities are managed. Rather, the ODSS frontendcontrols access to the ODSS backend, and the ODSS backendperforms the functionality of enforcing signing permissions, performing signing or key generation activities, and/or defining the hierarchy of the entities discussed below and how the access to such entities are managed.

The ODSS frontendalso has access to a server operating according to a user authentication service such as an Lightweight Directory Access Protocol (LDAP) server to authenticate valid users. The ODSSmaintains its own database of useraccounts, and the ODSS User authentication serviceis used when a user is added to the system for the first time and a user account is created and stored in the ODSS database.

To access the ODSS, the usermust specify user credentials, such as a password. Those credentials are used to validate every user session between the userand the ODSS frontend. The ODSSforbids access to usersunless valid credentials are provided and favorably compared to analogous information specified in ODSS database. Hence, only valid ODSSusershaving credentials matching those stored in the ODSS database) can access ODSS.

The ODSS backendis behind a second firewalland provides protected access to the ODSS databaseand the data signing keys that are stored in an ODSS hardware security module (HSM). It is used to access the ODSS hierarchical entities discussed below and to look up user permissions for different data signing configurations and to perform all authorized crypto operations.

The ODSS backendconnects to ODSS HSMand using the ODSS HSM, performs operations such as data signing, encryption, and decryption. The ODSS backendmay implement a plurality of software layers including, from the top software layer to the bottom software layer, an ODSS Service Layer, a Business Logic Layer (BLL)and a Data Access Layer (DAL).

Although the foregoing discloses an ODSShaving a ODSS frontendand an ODSS backend, the ODSSmay be implemented with a single server performing the functions of both the ODSS frontendand the ODSS backend, albeit, with reduced security.

The ODSS Service Layeris the heart of ODSSand is comprised of a plurality of signing/generation operations that are supported by ODSS. Depending on what type of service is needed, a specific dynamically loadable library (DLL) required for that service may be injected into memory to perform the operation.

The Business Logic Layer (BLL)specifies which usershave access to the ODSSand the conditions on which access is granted or revoked. The BLLalso takes care of other business logic such as updating audit logs and generating reports.

The Data Access Layer (DAL) layerprovides access to the ODSS databaseand enables queries to access, add or remove entries in the ODSS database.

In a first embodiment, a manual data signing generation functionality is provided to users. This embodiment is illustrated in, which illustrates a human user ODSSH. This embodiment implements a manual process by which the designated human usersH of the ODSSH sign data using a human user deviceH.

Step: In this embodiment, the useris a human userH that comprises a personand a human user deviceH. Before a human userH can access the ODSS, an administrator of the ODSSadds the user's identity such as a username to the ODSS configurations (further described below) in ODSS databasecorresponding to software development projects the userhas been assigned. This can be accomplished, for example, using an administrator client device analogous to the illustrated human user deviceH.

Step: The human userH interacts with the ODSS frontendvia a web browser executing on a human user deviceH. Preferably, this interaction is performed using the secure hypertext transfer protocol (HTTPS).

Step: The ODSS frontendutilizes appropriate services provided by the ODSS backendover a simple object access protocol (SOAP) interface.

Step: When the human userH logs in, the ODSS frontendvalidates the user credentials (e.g., username and password) received from the human user deviceH against data stored in the ODSS User authentication serviceand if the user credentials compare favorably with the data stored in the ODSS User authentication service, the human userH can access the ODSS. If not, the human userH is denied access to the ODSS.

Step: Based on logged in user's credential, the ODSS frontendinvokes BLLof the ODSS backendto look up user permissions to determine which configurations the logged in human userH has access to and presents only those configurations to the human userH.

Step: Using the human user deviceH, the human userH then selects one or more of the presented configurations and uploads an input/request file as well as other request parameters to ODSS frontend.

Step: The ODSS frontendpasses the uploaded input/request file, selected configuration, and operational details such as which signing key, signature algorithm, and/or digital signature format to use to ODSS backend.

Step: The ODSS backend, upon receiving request from the ODSS frontend, invokes the ODSS Service Layer.

Step: The invoked ODSS Service Layeraccesses the ODSS HSMto get the keys that are needed to sign the data in the input/request file, and retrieves configuration details from ODSS database. In one embodiment, the ODSS Service Layeralso parses the input file. This is required because for some signing operations, the input file must follow a particular format, and this operation verifies that the input file is using the proper format, then retrieves certain information from certain portion(s) of input file. The ODSS Service Layerthen performs appropriate operations such as data signing, encryption, and decryption on the relevant portions of the input file. Based on these operations, the ODSS Service Layergenerates an output response file having the signed data and other information.

Step: The ODSS Service Layerreturns the generated output/response to the ODSS frontend. The ODSS frontendgenerates a file from the generated output/response administrator client device, subsequently forwarded to the human userH.

Another embodiment provides the automatic signing generation functionality to customers such that they can integrate this in their automated build process. In order to provide such a mechanism a machine-to-machine interface must be provided over Internet such that ODSS machine user client deviceM can automatically connect with our ODSSService to request data signing

is a diagram of an automated version of the ODSSM. As described below, the automated ODSSM uses same ODSS architecture depicted in, and can be used to support automated online requests from a ODSS machine userM implemented by a machine user deviceM associated with an internet protocol (IP) address. In this case, the IP address is treated as a virtual user of the ODSSM and can obtain the same kinds of permissions as are normally assigned to a human userH.

The automated ODSSM introduces two additional components: an ODSS client toolimplemented on an ODSS machine user deviceM and an ODSS web service. The ODSS Web Serviceprovides an interface to the ODSSinfrastructure elements described above.

The automated ODSSimplements a machine-to-machine interface that comprises ODSS client tool, ODSS Web Serviceand ODSS backend. ODSS backendfunctionality is shared between the manual user access modes described with respect to(e.g. graphical user interface or GUI), and the machine-to-machine interface described further below.

The ODSS client toolthat is executed in the ODSS machine userM environment handles any pre-processing and post-processing of image files of the data to be signed so the ODSS machine userM does not need to know the details of the signing operations being performed on such data. The ODSS client toolcommunicates with the ODSS Web Servicewhich runs on ODSS frontend.

The ODSS web serviceis hosted on ODSS frontendbehind firewallto protect against unauthorized access. The ODSS Web Serviceperforms authorization and authentication functionality of ODSSM. The ODSS web serviceallows the ODSS machine userM, through the ODSS frontendto request data signing, encryption and decryption without a human interface or human userH involvement.

Before an ODSS machine userM can access ODSS, the ODSS administrator creates a user (machine) account in the ODSS User authentication serviceand personalizes a hardware cryptographic token for that ODSS machine userM (by for example creating a digital certificate and private key on that token which identify a data signing client host where ODSS client toolis executing). The hardware cryptographic token can be used for ODSS machine user deviceM authentication in a number of ways.

Once the ODSS machine userM is authenticated, the ODSS Web Serviceinvokes the ODSS backendto retrieve machine authorization permission data that is used to determine whether the requesting machine account is authorized to perform the requested operation. Such authorization permission data is stored in the ODSS database.

Upon receiving the request from ODSS Web Service, the ODSS backendinvokes the ODSS Service Layer, which accesses the ODSS HSMto retrieve the keys required for the data signing process and also retrieve configuration details for the configurations that the machine userM is authorized to access or control. The ODSS backendthen optionally parses the input file provided by the ODSS machine userM above. The ODSS backendthen performs the appropriate action such as signing the data or other data in the input file, and/or encryption and decryption of data or keys. Based on the results of the action, the ODSS Service Layergenerates a response having the output or results of the requested action. This output may comprise, for example, the signed data, and/or encrypted or decrypted keys. The ODSS Service Layerlater returns this output to ODSS Web Serviceexecuting on the ODSS frontend. The ODSS Web Servicereturns the generated output to ODSS client tool. If no output is available, the ODSS web servicereturns an error code.

The ODSSM is secured with multiple layers of protection against unauthorized access and protection of private keys including those used to sign the data. Such protection includes:

Certificates stored on hardware crypto tokens are generated with the IP address of the ODSS machine userM as a unique user identifier in the CommonName attribute of each certificate. Optionally, a client is not permitted to be behind proxy settings, so that the ODSS machine userM IP address is the actual address and not modified as seen by the server. IP addresses may be blocked from accessing ODSSconfigurations and entities based on the geographic location associated with that IP address.

As described above, there is a need to 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 that publish the data to their customers. This is accomplished by defining a hierarchical organization of a plurality of entities within the ODSS, and managing eligibility to designate users to access those entities via accounts granting different eligibility status, as further described below.

As described above, the ODSS systemhas two types of users: human usersH and machine usersM. To manage those users, we define what “roles” can be assigned to these users. Such roles include administrator roles, manager roles, and user roles. Both human usersH and machine usersM may have “user” roles in the ODSS system, while only human usersH can have “manager” or “administrator” roles.

An account represents the relation between a company and an ODSS entity and all of the children of the ODSS entity. An account is one of two account types, including an owner account type, and a participant account type. Granting an account provides eligibility to grant permission of a userto access an ODSS entity (and those hierarchically below that entity), but not permission itself. The permission is instead granted to the eligible user. A company may have multiple accounts for different ODSS entities, as further discussed below.

The top level ODSS entity (the application platform entity discussed below) can be owned by just one company through an owner account. This is enforced by the ODSS administrator granting an owner account to only one company. However, a company may have a participant account on the two top ODSS entity levels (the application platform entity and the project entity). This structure allows different ODSS entities to be accessible by multiple companies by the granting of the particular type of an account (owner or participant).

Only human usersH from an owner account can be assigned a manager role, and only userswhose company has an account (either an owner account or a participant account) can be granted permission to sign data to be installed on devices associated with an entity associated with that account.

is a diagram depicting a hierarchical organization (e.g. hierarchy) of a plurality of entities associated with data signing operations discussed above. The hierarchyof entities includes, in decreasing hierarchical order, an application platform entity, at least one project entityfor each application platform entity, at least one model entityfor each project entityand at least one configuration entityfor each model entity.