System and method for securely binding and node-locking program execution to a trusted signature authority

#The present invention relates generally to prevention of unauthorized use of software. More particularly, the present invention relates to software protection by way of binding and node-locking software applications to a trusted signature authority.

#In the software industry, it is often desirable to limit access to a given software application for reasons that may include preventing unauthorized use (e.g., unlicensed pirating) or unauthorized manipulation (e.g., hacking). One known solution to unauthorized use of software is to bind any given software application to a specific computer or device. In this manner, the software application may then only be executed on the respective licensed device. This binding of the software application to a specific device is commonly known as node-locking or alternatively referred to as hardware-software anchoring.

#The traditional approach to node-locking has been to take a unique identifier (ID) from a piece of hardware and make the software application dependent on the given ID. The number and characteristics of these unique IDs vary greatly from platform to platform. Some common hardware identifiers include: the Media Access Control (MAC) address, the Hard-Disk Drive Identifier (HDD ID), and a Serial Number (SN). Additional node-locking identifiers can include Basic Input/Output System (BIOS) values, hash values computed by a driver hash function, device IDs, or any similar identifier unique to a given hardware device or element. In the traditional approach to node-locking, anchoring a piece of software (i.e. the application) to a particular node is a matter of creating a dependency from the unique ID to the functioning of the software. In some systems, this may be a set of mathematical operations that derive a key from a unique ID. In other systems, an algorithm may be devised that requires a subset of unique IDs to be valid while allowing all others to be incorrect. The latter allows for variation in the hardware itself—for example, a network interface card may be removed from a computer.

#Embodiments of the present invention will now be described, by way of example only, with reference to the attached Figures.

#FIGS. 1A and 1B illustrate the general flow processes in accordance with the present invention.

#FIG. 2 is a flow diagram in accordance with a first embodiment of the present invention executed on an untrusted platform.

#Generally, the present invention provides a system and method for a signing-based node-locking mechanism that includes binding a program, P, to any untrusted execution platform, E, containing a TSA which itself may take many alternate forms. With regard to FIGS. 1A and 1B, there is shown generally the overall flow of the present inventive signing-based node-locking mechanism.

#With specific regard to FIG. 1A, the process begins with an off-line process on a trusted execution platform 101 to create a protected program. The off-line binding process takes the original program, P, 10 and a seed from a source of entropy 11 as an input to a provisioning step 12. The entropy 11 is used in part to determine the value of a secret, S, and is further described in more detail herein below. In general, the secret, S, may be, for example, a public/private key pair. The provisioning step 12 produces a secret, S, and a protected program, PS as output 13. More specifically, the provisioning step 12 produces a uniquely diverse protected program, PS, 14 that is destined for the untrusted execution platform 102 shown in FIG. 1B. It should be understood that the binding process of FIG. 1A occurs one time only for each hardware-software instance.

#Although shown separated for purposes of illustrative clarity, it should be readily apparent that the trusted execution platform 101 as seen by way of FIG. 1A may or may not be a separate entity from the untrusted execution platform 102. Indeed, the trusted execution platform 101 and the untrusted execution platform 102 may be one in the same without straying from the intended scope of the present invention, if, for example, the inventive binding process is executed in a one-time secure initialization under an orthogonal set of security conditions. In accordance with the present invention, it should be understood that the binding process of FIG. 1A must securely communicate once with the TSA 16 such that the secret, S, 16 may be embedded into the untrusted platform 102 as shown. However, the protected program, PS, 14 may be made publicly available.