Patent Description:
The object of the invention is to enhance the protection of software license information.

Methods for protecting software licensing information via a trusted platform module (TPM) are performed by systems and devices. When a licensing server is unreachable, a license is generated for a software application by a licensing manager. The license is protected via a secure register of the TPM using an asymmetric key, specific to the software application and policy-tied to the secure register, to generate a signature of a hashed license file for the software application. The asymmetric key is stored, mapped to the license file, and used for subsequent license validation. A licensing manager validation command is provided to validate the license using the key, as applied to the hash, to verify the signature and check the validity of the time stamp. Time stamp expiration or alteration of the temporary license are determined to provoke invalidation indications for the license.

Further features and advantages, as well as the structure and operation of various examples, are described in detail below with reference to the accompanying drawings. It is noted that the ideas and techniques are not limited to the specific examples described herein. Such examples are presented herein for illustrative purposes only. Additional examples will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.

The features and advantages of embodiments will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like reference characters identify corresponding elements throughout.

The following detailed description discloses numerous embodiments. The scope of the present patent application is not limited to the disclosed embodiments, but also encompasses combinations of the disclosed embodiments, as well as modifications to the disclosed embodiments.

In the discussion, unless otherwise stated, adjectives such as "substantially," "approximately," and "about" modifying a condition or relationship characteristic of a feature or features of an embodiment of the disclosure, are understood to mean that the condition or characteristic is defined to be within tolerances that are acceptable for operation of the embodiment for an application for which it is intended.

Furthermore, it should be understood that spatial descriptions (e.g., "above," "below," "up," "left," "right," "down," "top," "bottom," "vertical," "horizontal," etc.) used herein are for purposes of illustration only, and that practical implementations of the structures and drawings described herein can be spatially arranged in any orientation or manner. Additionally, the drawings may not be provided to scale, and orientations or organization of elements of the drawings may vary in embodiments.

Section II below describes example embodiments for protecting software licensing information via a TPM. Section III below describes example mobile and computing device embodiments that may be used to implement features of the embodiments described herein. Section IV below describes additional examples and advantages, and Section V provides some concluding remarks.

Methods for protecting software licensing information via a trusted platform module (TPM) are performed by systems and devices. Embodiments herein may be directed to client/user systems and/or devices though which a user obtains licenses for different types of software applications (also "software" or "apps"), such as email applications, productivity software, software application suites, etc. For example, a user may utilize a software application such as Outlook® or a suite such as Microsoft® Office from Microsoft Corporation of Redmond, WA, to check email or generate a spreadsheet, which may require a license for such use. In some scenarios, e.g., when a user's device is offline or not connected to a network, a licensing server may not be reachable to verify the license for the installed software. In these cases, a temporary license (also a "grace" license) may be used. A user may already have a temporary license for their software application, or a new temporary license may need to be generated, for the access desired by the user.

The embodiments herein may utilize a TPM, or other equivalent mechanism, in computing devices/systems to help generate and/or protect the license file of a temporary license and ensure that the license file cannot be replaced or tampered with. The embodiments herein also provide for validating standard licenses, long-term licenses, etc., installed for software applications using a TPM. As referred to herein for embodiments, a "license" may refer to and be applicable to, a license of any type. Similarly, embodiments exemplarily described for temporary licenses are also contemplated as being applicable to other license types, e.g., standard licenses, long-term licenses, etc..

As an example, consider a software application installed at a user device that is enabled/configured to make use of these embodiments. The software application may first create/install a license file through an application programming interface (API), or other equivalent mechanism, of licensing software (also a "licensing manager" herein) associated with the user device, e.g., in an operating system such as Windows® from Microsoft Corporation of Redmond, WA. The licensing manager may utilize a secure register of the TPM, e.g., a Platform Configuration Register (PCR), which is configured to be reset, and reset the secure register to its initial value.

Licensing software may then use the TPM and extend a hash of the license file into the secure register. The licensing software may create a key, such as an asymmetric key, via the TPM that is persisted in the TPM. In embodiments, the key may only be utilized for signing and signature verification of licenses, and may only be utilized when the used secure register has a value generated as result of extending the hash of the licensing file. The licensing software then signs the licensing file, and is also configured to keep a record of the licensing file and the associated key that has been created, e.g., in a registry. Accordingly, a robust temporary license is generated that cannot be defeated by conventional techniques of bad actors.

Subsequently, when the software application requires validation of the licensing file for access and use, the software application may call into another API of the licensing manager to verify the temporary license/license file. This second API may reset the secure register used to generate the temporary license and extend the hash of the licensing file into the secure register. The associated key may then be used to verify the signature of the licensing file, and additionally or alternatively, the time stamp may be verified for validity/expiration. Such embodiments are also applicable to validating standard licenses for software applications.

According to embodiments, the key may be generated as being associated with a policy that only allows the key to validate this specific signature because the hash that is extended into the secure register is the same as when the key was created. Then the second API may return the result of the verification to the caller. If the licensing file contains an expiration date, or any tampering with the licensing file is detected when verifying the signature of the licensing file, an invalidation response may be provided to the caller. Additionally, another licensing file with a valid signature that is attempted to be used for defeating the licensing requirement cannot be verified because the hash that is extended into the secure register will be different.

It should be noted that the embodiments herein are not limited to offline scenarios, but are also applicable to cases where a user device is online, i.e., able to connect to a licensing server.

In the context of at least some embodiments, a TPM may refer to a software- or hardware-based technology device that is designed to provide security-related functions for a computing device. A TPM may be embodied as a chip or equivalent hardware module that may be utilized as a secure crypto-processor to carry out cryptographic operations via various physical security mechanisms that make the TPM tamper resistant with respect to bad actors. Additionally, malicious software is unable to tamper with the security functions of the TPM. Some example advantages of utilizing a TPM in the context of protecting software licensing information include, without limitation, the ability to generate, store, and limit the use of cryptographic keys, the availability of secure registers (e.g., PCRs), and ensuring platform integrity by taking and storing security measurements, e.g., for key creation and use with hash values of licensing files. TPM-based keys can be configured to be unavailable outside the TPM which may prevent the keys from being copied and used without the TPM.

The embodiments herein provide for solutions to issues for licensing avoidance by providing secure methods and systems for license generation and persistence via TPMs. These and other embodiments for protecting software licensing information via a TPM will be described in further detail below in association with the Figures, and in the Sections/Subsections that follow.

Systems, devices, and apparatuses may be configured in various ways to protect software licensing information via a TPM. For instance, <FIG> is a block diagram of a system <NUM>, according to embodiments. System <NUM> is configured to protect software licensing information via a TPM, according to embodiments. As shown in <FIG>, system <NUM> includes a user device <NUM> and a license server <NUM>. In embodiments, user device <NUM> and license server <NUM> may communicate with each other over a network <NUM>, and in some embodiments, user device <NUM> may be offline and not connected to network <NUM>. It should be noted that various numbers of license hosts and/or user devices may be present in various embodiments. Additionally, any combination of the components illustrated in <FIG> may be present in system <NUM>, according to embodiments.

Network <NUM> may comprise any number and/or type of communication links that connect computing devices and hosts/servers such as, but not limited to, the Internet, wired or wireless networks and portions thereof, point-to-point connections, local area networks, enterprise networks, and/or the like.

License server <NUM> may comprise one or more server computers or computing devices, which may include one or more distributed or "cloud-based" servers. In embodiments, license server <NUM> may be associated with, or may be a part of, a cloud-based service platform such as Microsoft® Azure® from Microsoft Corporation of Redmond, WA, and in some embodiments, license server <NUM> may comprise an on-premises server(s) in addition to, or in lieu of, cloud-based servers. Various systems/devices herein, such as license server <NUM> may be configured to receive requests for license validation for software applications installed at and/or executing at user device <NUM>, from user device <NUM> via network <NUM>.

It should be noted that as described herein, license server <NUM> may be applicable to any type of system for performance of operations, including license validation for software applications, according to embodiments. One example of implementations noted above are network, or "cloud," implementations, applications, or services in a network architecture/platform. A cloud platform may include a networked set of computing resources, including servers, routers, etc., that are configurable, shareable, provide data security, and are accessible over a network such as the Internet. Cloud applications/services such as licensing servers for license validations, etc., may run on these computing resources, often atop operating systems that run on the resources, for entities that access the applications/services, locally and/or over the network. A cloud platform may support multi-tenancy, where cloud platform-based software services multiple tenants, with each tenant including one or more users who share common access to software services of the cloud platform. Furthermore, a cloud platform may support hypervisors implemented as hardware, software, and/or firmware that run virtual machines (emulated computer systems, including operating systems) for tenants. A hypervisor presents a virtual operating platform for tenants.

User device <NUM> may be any number, type, or combination of computing devices or computing systems, including a terminal, a personal computer, a laptop computer, a tablet device, a smart phone, a personal digital assistant, a server(s), a wearable device (e.g., a smart watch), a gaming console, and/or the like, including internal/external storage devices, that may be utilized to execute software applications and determine license validity for such software applications. In embodiments, user device <NUM> may be used by various types of users, including without limitation, software application end users, operating system end users, etc., that obtain licenses to access software. As illustrated, user device <NUM> includes a TPM <NUM> and a license manager <NUM>. TPM <NUM> may be a TPM as described herein that is configured to improve security for generation and persistence of software licenses. License manager <NUM>, described in further detail below, may be part of an operation system of user device <NUM>, and may be configured to perform licensing functions for software applications, and to provide one or more APIs that enable calls/commands for performance of such licensing functions via TPM <NUM>.

User device <NUM> may also include additional components (not shown for brevity and illustrative clarity) including, but not limited to, components and subcomponents of other devices and/or systems herein, as well as those described below with respect to <FIG>, <FIG>, and <FIG>, such as but not limited to, an operating system, etc..

User device <NUM> may be configured in various ways for protecting software licensing information via a TPM. For instance, referring now to <FIG>, a block diagram of a system <NUM> is shown for protecting software licensing information via a TPM, according to an example embodiment. System <NUM> may be an embodiment of system <NUM> of <FIG>, e.g., user device <NUM>. System <NUM> is described as follows.

System <NUM> includes a computing device <NUM>, which may be an embodiment of user device <NUM> of <FIG>, and which may be any type of server or computing device, as mentioned elsewhere herein, or as otherwise known. As shown in <FIG>, computing device <NUM> may include one or more processors ("processor") <NUM>, one or more of a memory and/or other physical storage device ("memory") <NUM>, as well as one or more network interfaces ("network interface") <NUM>. Computing device <NUM> includes a license manager <NUM> and a TPM <NUM> that may respectively be embodiments of license manager <NUM> and TPM <NUM> of <FIG>. License manager <NUM> and TPM <NUM> may be configured to protect software licensing information, as described herein, and in embodiments, license manager <NUM> may comprise a portion of licensing software of an operating system (OS) <NUM>. Computing device <NUM> may also include or be configured to execute one or more software applications <NUM> (also "app(s)"), and may include a registry <NUM>.

System <NUM> may also include additional components (not shown for brevity and illustrative clarity) including, but not limited to, components and subcomponents of other devices and/or systems herein, as well as those described below with respect to <FIG>.

Processor <NUM> and memory <NUM> may respectively be any type of processor circuit(s) and memory that is described herein, and/or as would be understood by a person of skill in the relevant art(s) having the benefit of this disclosure. Processor <NUM> and memory <NUM> may each respectively comprise one or more processors or memories, different types of processors or memories (e.g., at least one cache for query processing), remote processors or memories, and/or distributed processors or memories. Processor <NUM> may be multi-core processors configured to execute more than one processing thread concurrently. Processor <NUM> may comprise circuitry that is configured to execute computer program instructions such as, but not limited to, embodiments of license manager <NUM>, including one or more of the components thereof as described herein, and/or application(s) <NUM>, which may be implemented as computer program instructions, as described herein.

Memory <NUM> may include volatile storage portions such as a random access memory (RAM) and/or persistent storage portions such as hard drives, non-volatile RAM, and/or the like, to store or be configured to store computer program instructions/code as described herein, as well as to store other information and data described in this disclosure including, without limitation, OS <NUM>, license manager <NUM>, one or more of application(s) <NUM>, license files of application(s) <NUM>, contents of registry <NUM>, and/or the like.

Network interface <NUM> may be any type or number of wired and/or wireless network adapter, modem, etc., configured to enable system <NUM>, including computing device <NUM>, to communicate with other devices and/or systems over a network, such as communications between computing device <NUM> and other devices, systems, hosts, of system <NUM> in <FIG> over a network such as network <NUM>.

Application(s) <NUM> may be any type of software application, such as email applications, productivity software, software application suites, etc. Application(s) <NUM> may be executed by processing device <NUM> and may run on OS <NUM>. As referred to herein, a software application may one of application(s) <NUM>. Application(s) <NUM> may require a license, such as a standard license or a temporary license, in order to be used. OS <NUM> may be any OS from any developer/publisher. OS <NUM> may be enabled to or programmed to verify licenses, such as temporary licenses, for one or more of application(s) <NUM>, via licensing software, e.g., license manager <NUM>. Registry <NUM> may be a portion of OS <NUM> in embodiments, and may store information associated with software licenses, such as program identifiers for specific licenses, and keys used to sign the licenses.

License manager <NUM> of computing device <NUM> may include a plurality of components for performing the functions and operations described herein for protecting software licensing information via a TPM, such as TPM <NUM>. For instance, license manager <NUM> may be configured to receive calls to APIs thereof that provide commands to TPM <NUM> for secure license generation and persistence. As noted above, ones of application(s) <NUM> may require respective licenses in order to allow their use by a user of a client device such as computing device <NUM>. In some embodiments, computing device <NUM> may be offline or otherwise unable to access a remote license host over a network. In such scenarios, a software application to be accessed by the user may provide a call or other request to license manager <NUM> for a license or for verification of an existing license, such as a temporary license for the software application. As illustrated, license manager <NUM> includes a license determiner <NUM>, an install API <NUM>, a verification API <NUM>, and license file(s) <NUM>.

License file(s) <NUM> may include one or more license files/licenses specific to ones of application(s) <NUM>. Ones of license file(s) <NUM> may be generated by license manager <NUM> for a specific software application based on application information, according to embodiments herein, e.g., for temporary licenses. License file(s) <NUM> may be persistent stored by memory <NUM> in a persistent storage portion thereof in embodiments as being associated with license manager <NUM>. As referred to herein, a license file or a license, e.g., a temporary license, may be one of license file(s) <NUM>. In embodiments, a license file may include a validity period for the license, such as a time stamp at which the license was granted and a period of validity therefrom, an expiry time/date for the license, and/or the like.

License determiner <NUM> is configured to receive requests from software applications for determinations of the presence/absence of licenses, such as standard licenses, and the validity state of such licenses. For example, license determiner <NUM> may provide an indication, responsive to a request, back to a software application that a license is present or existing therefor, according to embodiments. License determiner <NUM> may base such an indication on locating a license for the software application as one of license(s) <NUM>, or via communication with a license server such as license server <NUM> of <FIG>. Alternatively, license determiner <NUM> may determine that the requested license is not valid or is not present or as one of license(s) <NUM>, or that the license host is unreachable over a network. In these scenarios, the indication may convey to the software application that there is no license, and the software application may determine that it lacks a valid temporary license, standard license, etc..

Install API <NUM> is configured to be exposed by license manager <NUM> to service calls from software applications to create and install a software license therefor, e.g., a temporary license. Install API <NUM> is configured to provide commands to TPM <NUM>, as described herein, for secure generation of license files/licenses. That is, install API <NUM> enables a software application to indirectly utilize TPM <NUM> to securely generate license files/licenses.

Verification API <NUM> is configured to be exposed by license manager <NUM> to service calls from software applications for verification of license files/licenses. Verification API <NUM> is configured to provide commands to TPM <NUM>, as described herein, for robust verification of license validity. That is, verification API <NUM> enables a software application to indirectly utilize TPM <NUM> to securely verify license files/licenses.

TPM <NUM> may comprise a hardware-based technology device that is designed to provide security-related functions for a computing device. TPM <NUM> may be embodied as a chip or equivalent module in computing device <NUM>, or as a secure software implementation, and may be configured to be utilized as a secure crypto-processor to carry out cryptographic operations. TPM <NUM> may include one or more secure registers, a key generator, memory, etc., further details of which are described below. Accordingly, TPM <NUM> may be configured to protect software licensing information in conjunction with license manager <NUM>, as described herein.

For example, <FIG> shows a block diagram of a TPM <NUM> for protecting software licensing information that may be an embodiment of TPM <NUM> of <FIG>. TPM <NUM> is described as follows.

TPM <NUM> includes a key generator <NUM>, policies <NUM>, an operator <NUM> and secure registers <NUM>. Key generator <NUM> is configured to generate keys, e.g., asymmetric keys, to be utilized in signing and signature verification of license files/licenses. In embodiments, license manager <NUM> of <FIG> may request that a key for a specific software application be generated by key generator <NUM> for utilization in signing and signature verification. Key generator <NUM> may generate keys as being associated with one or more of policies <NUM>. For example, a policy of policies <NUM> may specify that key may only be utilized for signing and signature verification of licenses, and may only be utilized when the used secure register has a value generated as result of extending the hash of the licensing file. In some embodiments, one or more of policies <NUM> may be stored in association with license manager <NUM> at memory <NUM> of <FIG> and may be provided from license manager <NUM> to TPM <NUM> with a request for key generation.

Operator <NUM> may be configured to perform operations for TPM <NUM> as described herein, including but without limitation, hashes of license files, resetting of values of secure registers <NUM>, extending of hashes to secure registers <NUM>, determinations of hashes being the same or different, determinations of expirations of time stamps, and/or the like. Secure registers <NUM> may include one or more registers of TPM <NUM>, e.g., PCRs in embodiments, configured to provide secure storage of information within TPM <NUM>.

As shown, TPM <NUM> also includes a non-volatile (NV) random access memory (RAM) <NUM> that stores, or is configured to store, one or more key(s) <NUM>. Key(s) <NUM> may be keys, such as asymmetric keys, generated by key generator <NUM>, as described above. By storing/persisting key(s) <NUM> in NV-RAM <NUM>, TPM <NUM> may prevent access or disclosure of key(s) <NUM> outside of TPM <NUM>, thus adding an additional security measure to the protection of the licenses and licensing information. In embodiments, key(s) <NUM> may comprise a data structure for storage of keys that maps the keys to their respective license files and/or software application identifiers.

It is also contemplated herein that TPM <NUM> may include additional components and features not shown for brevity and illustrative clarity, as would be understood by those of skill in the relevant art(s) having the benefit of this disclosure.

While shown separately for illustrative clarity, in embodiments, one or more of the components of license manager <NUM> of <FIG> and/or TPM <NUM> of <FIG> may be combined together and/or as a part of other components of system <NUM> and/or TPM <NUM>. In some embodiments, less than all of the components of license manager <NUM> and/or TPM <NUM> as illustrated may be included. In software implementations, one or more components of license manager <NUM> may be stored in memory <NUM>, and may be executed by processor <NUM>. Further details regarding license manager <NUM> and TPM <NUM>, and their respective subcomponents, are described below.

As noted above for <FIG>, embodiments herein provide for protecting software licensing information via a TPM. System <NUM> of <FIG>, system <NUM> of <FIG>, and TPM <NUM> of <FIG> may each be configured to perform such functions and operations. <FIG> will now be described. <FIG> shows a flowchart <NUM> for protecting software licensing information via a TPM, according to example embodiments. System <NUM> and license manager <NUM> of computing device <NUM> in <FIG> as well as TPM <NUM> of <FIG> may operate according to flowchart <NUM>, in embodiments. Further structural and operational examples will be apparent to persons skilled in the relevant art(s) based on the following descriptions. Flowchart <NUM> is described as follows with respect to system <NUM> of <FIG>, system <NUM> of <FIG>, and TPM <NUM> of <FIG>.

Flowchart <NUM> begins at step <NUM>. In step <NUM>, it is determined that a license server is unreachable over a network and/or that a software application lacks a license. For example, a software application may determine an offline state for a computing device on which the software application is executing, where a license server/host is unreachable, or that a license is not present for the software application. In embodiments, such determinations may be made in conjunction with license determiner <NUM> of license manager <NUM> in <FIG>, or alternatively by license determiner <NUM>, as described above.

In step <NUM>, a request is received at a license manager to generate a license for a software application based at least on the software application lacking a license, the request including a license file specific to the software application. For instance, install API <NUM> of license manager <NUM> may be configured to receive a request or a call from the software application in step <NUM>. The request or call may include information about the software application, such as an identifier of the software application, a period of time, authorizations, and/or permissions to be associated with the license, as well as a license file associated with the software application. In embodiments, the license file may include one or more portions of the information in the request. Additionally, the request or call may be sent by the software application responsive to the determination made in step <NUM>.

In step <NUM>, a command is generated that is sent to a TPM responsive to the request, the command specifying a license generation action and information including the license file and an identifier of the software application. For instance, install API <NUM> may be configured to generate the command and send the command to TPM <NUM> or TPM <NUM> of <FIG> (hereinafter for flowchart <NUM>), based on the request or call from step <NUM>. Install API <NUM> may generate the command to specify that an action be taken by TPM <NUM> in furtherance of the generation of the license requested. The command may also be generated to include, or be accompanied by, the license file from the software application and an identifier therefor.

In step <NUM>, a key is generated that is configured sign and verify a signature of the license. For example, install API <NUM> may include as part of the command generated in step <NUM> the performance of a key generation action to be performed by key generator <NUM>. In embodiments, key generator <NUM> may generate an asymmetric key that is specific to the license file for signing and later verifying its signature, as described herein. The key may be generated based on a hash of the license file, as described in further detail below with respect to <FIG>. The generated key may be stored by key generator <NUM> in NV-RAM <NUM> as one of key(s) <NUM>. In embodiments, the key may be mapped to the license file and/or to the identifier of the software application in a data structure of NV-RAM <NUM>, as described herein.

In step <NUM>, the license is generated utilizing a secure register of the TPM responsive to the command, and based on the information and the key. For example, if a time stamp or expiration time for the license, e.g., as for a temporary license, is not included in the license file, operator <NUM> of TPM <NUM> may be configured to capture a time stamp to be associated with the temporary license file. The time stamp and/or the license file from the information of step <NUM> may be signed by operator <NUM>, license manager <NUM> via install API <NUM>, or license manager <NUM> via install API <NUM> and operator <NUM>, using one of secure registers <NUM> of TPM <NUM> based on the key generated in step <NUM>. Non-temporary licenses may be generated without the use of time stamps, in embodiments. Additional details regarding the operation of step <NUM> are provided below with respect to <FIG>.

In step <NUM>, the license is provided to the license manager. For instance, TPM <NUM> may provide the generated license back to license manager <NUM>. License manager <NUM> may then store the license as one of license file(s) <NUM>. In embodiments, the license may comprise the signed license file.

In step <NUM>, a validation indication response to the command is provided by the TPM. For example, TPM <NUM> may provide a response with an indication of validity of the license back to license manager <NUM>, which may in turn provide the indication response to the software as a response to the request or call to install API <NUM>. In embodiments, step <NUM> and step <NUM> may be combined as a single operation.

<FIG> will now be described in the context of flowchart <NUM> of <FIG> shows a flowchart <NUM> for protecting software licensing information via a TPM, according to example embodiments. System <NUM> and license manager <NUM> of computing device <NUM> in <FIG> and TPM <NUM> of <FIG> may operate according to flowchart <NUM>, in embodiments. Further structural and operational examples will be apparent to persons skilled in the relevant art(s) based on the following descriptions. Flowchart <NUM> may be an embodiment of flowchart <NUM> of <FIG>, and is described as follows with respect to system <NUM> of <FIG> and TPM <NUM> of <FIG>.

Flowchart <NUM> begins with step <NUM>. In step <NUM>, a hash of the license file is generated by the TPM. For instance, operator <NUM> of TPM <NUM> may be configured to generate a hash of the license file from the information in step <NUM> of flowchart <NUM>. In embodiments, the hash may be generated prior to generation of the key in step <NUM> of flowchart <NUM>.

In step <NUM>, the hash is extended into the secure register by the TPM. For example, operator <NUM> of TPM <NUM> may extend the hash of the license file generated in step <NUM> to a secure register of secure registers <NUM>. In embodiments, operator <NUM> may reset the secure register to an initial value prior to extending the hash thereto.

In step <NUM>, the key is generated and associated with a policy that restricts use of the key to the secure register based on the hash. Step <NUM> may be a further embodiment of step <NUM> of flowchart <NUM>. For instance, key generator <NUM> of TPM <NUM> may be configured to generate the key as being associated with a policy of policies <NUM>. In embodiments, the policy may require that the key be utilized for the secure register in association with generated hash of step <NUM> when extended into the secure register as described in step <NUM>. That is, the key may be restricted to use with the secure register and the hash.

In step <NUM>, a signature of the license file is generated utilizing the key and based on the information. Step <NUM> may be a further embodiment of step <NUM> of flowchart <NUM>. For example, the license may be generated based on the generation of a signature for the license file from the information of step <NUM> using the key.

Accordingly, a secure mechanism for generation of a license is achieved at least through the restriction for the use of the key being tied to the secure register and the hash generated by TPM <NUM> as extended into the secure register.

Referring now to <FIG>, a block diagram for a system communication layer model <NUM> ("model <NUM>") with respect to system <NUM> of <FIG> is shown, according to example embodiments. Model <NUM> includes an application layer <NUM>, an operating system (OS) layer <NUM>, and a hardware layer <NUM>. As exemplarily shown, an application app <NUM><NUM> and an application app <NUM><NUM> may reside in application layer <NUM>. Application app <NUM><NUM> and application app <NUM><NUM> may be ones of application(s) <NUM> shown in system <NUM> of <FIG>, and may be any application that requires a license for use thereof. Below application layer <NUM>, license manager <NUM> of system <NUM> resides in OS layer <NUM>, and install API <NUM> and verification API <NUM> are illustrated for license manager <NUM>. Below OS layer <NUM> is hardware layer <NUM> which includes processor <NUM>, memory <NUM>, and TPM <NUM> (or TPM <NUM> of <FIG>, in embodiments), being connected by a system bus <NUM> that enables communications therebetween in accordance with the described embodiments for protecting software licensing information via a TPM.

Model <NUM> illustrates how the embodiments herein allow for an application, e.g., app <NUM><NUM>, to request secure generation of a license such as a temporary license that may be provided utilizing TPM <NUM> via install API <NUM> without direct access to TPM <NUM> from applications of application layer <NUM>.

Model <NUM> also illustrates how the described embodiments allow for an application, e.g., app <NUM><NUM>, to subsequently request secure validation of the license utilizing TPM <NUM> via validation API <NUM> without direct access to TPM <NUM> from applications of application layer <NUM> as described in further detail below.

For example, <FIG> shows a flowchart <NUM> for protecting software licensing information via a TPM, according to example embodiments. System <NUM> and license manager <NUM> of computing device <NUM> in <FIG> as well as TPM <NUM> of <FIG> may operate according to flowchart <NUM>, in embodiments. Further structural and operational examples will be apparent to persons skilled in the relevant art(s) based on the following descriptions. Flowchart <NUM> is described as follows with respect to system <NUM> of <FIG>, system <NUM> of <FIG>, and TPM <NUM> of <FIG>.

Flowchart <NUM> begins at step <NUM>. In step <NUM>, it is determined that a license server is unreachable over a network and/or that the software application lacks a license. For example, a software application may determine an offline state for a computing device on which the software application is executing, where a license server/host is unreachable, or that a license is not present for the software application. In embodiments, such determinations may be made in conjunction with license determiner <NUM> of license manager <NUM> in <FIG>, or alternatively by license determiner <NUM>, as described above.

In step <NUM>, a request is received from the software application to determine whether a license is valid for the software application at least in response to the software application determining that a license is not issued therefor. For instance, verification API <NUM> of license manager <NUM> in system <NUM> may be configured to receive a request or a call from the software application in step <NUM>. The request or call may specify a determination be made as to whether or not a standard or temporary license exists and/or is valid for the software application, and may include an identifier of the software application. In embodiments, the request or call may be received responsive to the determination made in step <NUM>. In embodiments, license determiner <NUM> of license manager <NUM> may determine if the license exists and is stored in license file(s) <NUM>.

In step <NUM>, a command is generated that is sent to a TPM responsive to the request, the command specifying an identifier of the software application and including a license file of the license. For instance, verification API <NUM> may be configured to generate the command and send the command to TPM <NUM> or TPM <NUM> of <FIG> (hereinafter for flowchart <NUM>), based on the request or call from step <NUM>. Verification API <NUM> may generate the command to specify that an action be taken by TPM <NUM> in furtherance of the validation determination for the license as requested. The command may also be generated to include, or be accompanied by, the license file for the software application, e.g., as signed and stored in license file(s) <NUM>, and an identifier of the software application, e.g., as provided in the request or call, or as determined from information in registry <NUM>, or as stored with the license file.

In step <NUM>, a hash of the license file is generated by the TPM and extended into a secure register by the TPM. For instance, operator <NUM> of TPM <NUM> may be configured to generate a hash of the license file provided with the command in step <NUM>. Operator <NUM> may also extend the hash of the license to a secure register of secure registers <NUM>. In embodiments, operator <NUM> may reset the secure register to an initial value prior to extending the hash thereto.

In step <NUM>, a key is retrieved by the TPM based on a mapping for the identifier in a mapping data structure subsequent to receiving the command. For example, after receipt of the command by TPM <NUM>, operator <NUM> may retrieve the key used to sign the license file from key(s) <NUM> stored in NV-RAM <NUM> (as described in step <NUM> of flowchart <NUM>). That is, the key may be mapped to the license file and/or to the identifier of the software application in a data structure of NV-RAM <NUM>, and may be thus identified by operator <NUM>.

In step <NUM>, the license is validated using the secure register of the TPM based on the key and the license file, or by verifying a time stamp. For instance, operator <NUM> of TPM <NUM> may utilize the key retrieved in step <NUM> to validate the signature of the signed license file. As described in step <NUM>, the hash of the license file is generated and extended into the secure register, and it is enabled to be used to verify the signature at least because the secure register currently contains the hash that was also present when the key was created, e.g., as described in step <NUM> of flowchart <NUM> and in step <NUM> of flowchart <NUM>. In some embodiments, verification API <NUM> may verify a time stamp of a temporary license, e.g., an expiry date of the temporary license, a current time stamp with respect to a validity time period or expiration date of the temporary license, and/or the like.

In step <NUM>, a validation indication response to the command is provided by the TPM. For example, TPM <NUM> may provide a response with an indication of validity of the license back to license manager <NUM>, which may in turn provide the indication response to the software as a response to the request or call to validation API <NUM>.

Embodiments herein also provide for determinations of invalidity for licenses, including temporary licenses, that are invalid utilizing a TPM, such as TPM <NUM> of <FIG>. <FIG> shows a flowchart for protecting software licensing information via a TPM, according to example embodiments. System <NUM> and license manager <NUM> of computing device <NUM> in <FIG> as well as TPM <NUM> of <FIG> may operate according to flowchart <NUM>, in embodiments. Further structural and operational examples will be apparent to persons skilled in the relevant art(s) based on the following descriptions. Flowchart <NUM> may be an embodiment of flowchart <NUM> of <FIG>, and is described as follows with respect to system <NUM> of <FIG>, system <NUM> of <FIG>, and TPM <NUM> of <FIG>.

Flowchart <NUM> begins at step <NUM>. In step <NUM>, it is determined that the license is invalid. For instance, step <NUM> may be performed subsequent to step <NUM> of flowchart <NUM> and in lieu of step <NUM> and step <NUM> when a license file is not valid. In embodiments, license manager <NUM> and/or TPM <NUM> may be configured to perform step <NUM>, and step <NUM> may include one or more sub-steps: step <NUM>, step <NUM>, and/or step <NUM>.

In step <NUM>, an expiration of the license with respect to a time stamp is determined. For example, license determiner <NUM> and/or validation API <NUM> may be configured to determine expiration of temporary licenses by analyzing ones of license file(s) <NUM> to determine expiration times. For instance, it may be determined that a temporary license may be invalid after an expiration date included in the license file, that a temporary license is valid for a time period subsequent to a time stamp in the license file, etc..

In step <NUM>, it is determined that the license has been altered. For instance, TPM <NUM> may be configured to determine that alterations have been made to a license file. In one example, a license file that otherwise appears valid may be determined as altered and invalid by operator <NUM> of TPM <NUM> based on a failure to validate a signature of the license file using the signing key. That is, a signature of a license file that appears valid may not be able to be validated because a hash of an altered license file that is extended into one of secure registers <NUM> for validation against the key will not match the hash that was present in the secure register when the key was created. Thus, the license file may be determined as altered and invalid.

In step <NUM>, a mismatch between the license and a registry entry related to the license is determined. For example, in some embodiments, information for an entry in registry <NUM> of <FIG> for a license file may not match a current license file that is attempted to be used for a software application. Licensing manger <NUM> may sign the licensing file, e.g., via TPM <NUM>, after its generation and is configured to keep a record of the licensing file and the associated key that has been created for the signing in registry <NUM>. Licensing manger <NUM>, e.g., via verification API <NUM>, and/or TPM <NUM> may be configured to compare information related to a license file that is provided during validation operations described herein with the entry record in registry <NUM>, and any mismatches determined for this comparison may indicate the invalidity of the provided license file.

In step <NUM>, an invalidation indication response to the second command is returned, the invalidation indication response indicating that the license is invalid for the application. For instance, TPM <NUM> may provide a response with an indication of invalidity of the license back to license manager <NUM>, which may in turn provide the indication response to the software as a response to the request or call to validation API <NUM>.

Referring now to <FIG>, a diagram of a data structure <NUM> for protecting software licensing information via a TPM is shown, according to example embodiments. Data structure <NUM> may comprise a portion of NV-RAM <NUM> and/or key(s) <NUM> of TPM <NUM> in <FIG>. Data structure <NUM> is configured as a mapping for keys, as described herein. In embodiments, data structure <NUM> may be a file-to-key mapping that associates generated keys in a storage with license files, such as temporary license files, for identification and/or retrieval of the keys for license file generation and/or validation, as described for the embodiments herein.

Data structure <NUM> may include fields/entries for a key and for a license file identifier (ID). As illustrated, data structure <NUM> exemplarily stores two key mappings: a first mapping <NUM> and a second mapping <NUM>. First mapping <NUM> includes a first license file ID "File <NUM>" that is mapped to a first key "Key <NUM>," while second mapping <NUM> includes a second license file ID "File <NUM>" that is mapped to a second key "Key <NUM>. " That is, the key may be stored (e.g., as part of key(s) <NUM>, described above) and mapped to an ID of the license file to which it is associated. In this manner, when a license file is installed for a software application, including the signing of the license file with a generated key, the key may be stored in a way that it is readily identifiable and retrievable for license file validation when a subsequent request or call is received to validate the associated license file.

In some embodiments, in addition to or in lieu of the license file ID being used for the mapping, a software identifier (ID) of the software application with which the license file is associated may be used for mapping to the key in data structure <NUM>. As exemplarily illustrated in <FIG>, a software ID field/entry may be included for data structure <NUM>. Accordingly, first mapping <NUM> may include a first software ID "App <NUM>" and second mapping <NUM> may include a second software ID "App <NUM>. " In this manner, a generated key may be stored in an additional or alternative way such that it is readily identifiable and retrievable for license file validation when a subsequent request or call is received to validate the associated license file. It should also be noted that in embodiments, the software ID may not be used or may not be present in data structure <NUM>.

Embodiments described herein may be implemented in hardware, or hardware combined with software and/or firmware. For example, embodiments described herein may be implemented as computer program code/instructions configured to be executed in one or more processors and stored in a computer readable storage medium. Alternatively, embodiments described herein may be implemented as hardware logic/electrical circuitry.

As noted herein, the embodiments described, including but not limited to, system <NUM> of <FIG>, system <NUM> of <FIG>, TPM <NUM> of <FIG>, model <NUM> of <FIG>, and data structure <NUM>, along with any components and/or subcomponents thereof, as well any operations and portions of flowcharts/flow diagrams described herein and/or further examples described herein, may be implemented in hardware, or hardware with any combination of software and/or firmware, including being implemented as computer program code configured to be executed in one or more processors and stored in a computer readable storage medium, or being implemented as hardware logic/electrical circuitry, such as being implemented together in a system-on-chip (SoC), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC). A SoC may include an integrated circuit chip that includes one or more of a processor (e.g., a microcontroller, microprocessor, digital signal processor (DSP), etc.), memory, one or more communication interfaces, and/or further circuits and/or embedded firmware to perform its functions.

Embodiments described herein may be implemented in one or more computing devices similar to a mobile system and/or a computing device in stationary or mobile computer embodiments, including one or more features of mobile systems and/or computing devices described herein, as well as alternative features. The descriptions of computing devices provided herein are provided for purposes of illustration, and are not intended to be limiting. Embodiments may be implemented in further types of computer systems, as would be known to persons skilled in the relevant art(s).

<FIG> is a block diagram of an exemplary mobile system <NUM> that includes a mobile device <NUM> that may implement embodiments described herein. For example, mobile device <NUM> may be used to implement any system, client, or device, or components/subcomponents thereof, in the preceding sections. As shown in <FIG>, mobile device <NUM> includes a variety of optional hardware and software components. Any component in mobile device <NUM> can communicate with any other component, although not all connections are shown for ease of illustration. Mobile device <NUM> can be any of a variety of computing devices (e.g., cell phone, smartphone, handheld computer, Personal Digital Assistant (PDA), etc.) and can allow wireless two-way communications with one or more mobile communications networks <NUM>, such as a cellular or satellite network, or with a local area or wide area network.

Mobile device <NUM> can include a controller or processor <NUM> (e.g., signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, input/output processing, power control, and/or other functions. An operating system <NUM> can control the allocation and usage of the components of mobile device <NUM> and provide support for one or more application programs <NUM> (also referred to as "applications" or "apps"). Application programs <NUM> may include common mobile computing applications (e.g., e-mail applications, calendars, contact managers, web browsers, messaging applications) and any other computing applications (e.g., word processing applications, mapping applications, media player applications).

Mobile device <NUM> can include memory <NUM>. Memory <NUM> can include non-removable memory <NUM> and/or removable memory <NUM>. Non-removable memory <NUM> can include RAM, ROM, flash memory, a hard disk, or other well-known memory devices or technologies. Removable memory <NUM> can include flash memory or a Subscriber Identity Module (SIM) card, which is well known in GSM communication systems, or other well-known memory devices or technologies, such as "smart cards. " Memory <NUM> can be used for storing data and/or code for running operating system <NUM> and application programs <NUM>. Example data can include web pages, text, images, sound files, video data, or other data to be sent to and/or received from one or more network servers or other devices via one or more wired or wireless networks. Memory <NUM> can be used to store a subscriber identifier, such as an International Mobile Subscriber Identity (IMSI), and an equipment identifier, such as an International Mobile Equipment Identifier (IMEI). Such identifiers can be transmitted to a network server to identify users and equipment.

A number of programs may be stored in memory <NUM>. These programs include operating system <NUM>, one or more application programs <NUM>, and other program modules and program data. Examples of such application programs or program modules may include, for example, computer program logic (e.g., computer program code or instructions) for implementing one or more of system <NUM> of <FIG>, system <NUM> of <FIG>, TPM <NUM> of <FIG>, model <NUM> of <FIG>, and data structure <NUM>, along with any components and/or subcomponents thereof, as well as the flowcharts/flow diagrams described herein, including portions thereof, and/or further examples described herein.

Mobile device <NUM> can include a mobile TPM <NUM>. Mobile TPM may be a mobile device equivalent embodiment of the TPMs described herein, as would be understood by one of skill in the relevant art(s) having the benefit of this disclosure. For example, mobile TPM <NUM> may be configured to perform one or more functions or operations as described for TPMs herein for protecting software licensing information via a TPM.

Mobile device <NUM> can support one or more input devices <NUM>, such as a touch screen <NUM>, a microphone <NUM>, a camera <NUM>, a physical keyboard <NUM> and/or a trackball <NUM> and one or more output devices <NUM>, such as a speaker <NUM> and a display <NUM>. Other possible output devices (not shown) can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, touch screen <NUM> and display <NUM> can be combined in a single input/output device. Input devices <NUM> can include a Natural User Interface (NUI).

One or more wireless modems <NUM> can be coupled to antenna(s) (not shown) and can support two-way communications between processor <NUM> and external devices, as is well understood in the art. Modem <NUM> is shown generically and can include a cellular modem <NUM> for communicating with the mobile communication network <NUM> and/or other radio-based modems (e.g., Bluetooth <NUM> and/or Wi-Fi <NUM>). At least one wireless modem <NUM> is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the mobile device and a public switched telephone network (PSTN).

Mobile device <NUM> can further include at least one input/output port <NUM>, a power supply <NUM>, a satellite navigation system receiver <NUM>, such as a Global Positioning System (GPS) receiver, an accelerometer <NUM>, and/or a physical connector <NUM>, which can be a USB port, IEEE <NUM> (FireWire) port, and/or RS-<NUM> port. The illustrated components of mobile device <NUM> are not required or all-inclusive, as any components can be deleted and other components can be added as would be recognized by one skilled in the art.

In an embodiment, mobile device <NUM> is configured to implement any of the above-described features of flowcharts herein. Computer program logic for performing any of the operations, steps, and/or functions described herein may be stored in memory <NUM> and executed by processor <NUM>.

<FIG> depicts an exemplary implementation of a computing device <NUM> in which embodiments may be implemented. For example, embodiments described herein may be implemented in one or more computing devices similar to computing device <NUM> in stationary or mobile computer embodiments, including one or more features of computing device <NUM> and/or alternative features. The description of computing device <NUM> provided herein is provided for purposes of illustration, and is not intended to be limiting. Embodiments may be implemented in further types of computer systems and/or game consoles, etc., as would be known to persons skilled in the relevant art(s).

A number of program modules may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. These programs include operating system <NUM>, one or more application programs <NUM>, other programs <NUM>, and program data <NUM>. Application programs <NUM> or other programs <NUM> may include, for example, computer program logic (e.g., computer program code or instructions) for implementing embodiments described herein, such as but not limited to, system <NUM> of <FIG>, system <NUM> of <FIG>, TPM <NUM> of <FIG>, model <NUM> of <FIG>, and data structure <NUM>, along with any components and/or subcomponents thereof, as well as the flowcharts/flow diagrams described herein, including portions thereof, and/or further examples described herein.

TPM <NUM> may be connected to bus <NUM>, and may be an embodiment of TPM <NUM> of <FIG> and/or TPM <NUM> of <FIG>, as described herein.

As used herein, the terms "computer program medium," "computer-readable medium," "computer-readable storage medium," and "computer-readable storage device," etc., are used to refer to physical hardware media. Examples of such physical hardware media include the hard disk associated with hard disk drive <NUM>, removable magnetic disk <NUM>, removable optical disk <NUM>, other physical hardware media such as RAMs, ROMs, flash memory cards, digital video disks, zip disks, MEMs, nanotechnology-based storage devices, and further types of physical/tangible hardware storage media (including memory <NUM> of <FIG>). Such computer-readable media and/or storage media are distinguished from and non-overlapping with communication media and propagating signals (do not include communication media and propagating signals).

Embodiments are also directed to computer program products comprising computer code or instructions stored on any computer-readable medium or computer-readable storage medium.

As described, systems and devices embodying the techniques herein may be configured and enabled in various ways to perform their respective functions for protecting software licensing information via a TPM. In embodiments, one or more of the steps or operations of any flowchart and/or flow diagram described herein may not be performed. Moreover, steps or operations in addition to or in lieu of those in any flowchart and/or flow diagram described herein may be performed. Further, in examples, one or more operations of any flowchart and/or flow diagram described herein may be performed out of order, in an alternate sequence, or partially (or completely) concurrently with each other or with other operations.

As described herein, systems, devices, components, etc., of the embodiments that are configured to perform functions and/or operations are also contemplated as performing such functions and/or operations.

The described embodiments combine new methods of protecting software licensing information via a TPM, e.g., utilizing secure registers of a TPM for generation and validation of licenses. The embodiments described herein utilize a combination novel APIs for licensing software (that allow license file information to be provided to a TPM), secure registers of the TPM, and a hash/policy-tied key for generating and validating license file signatures, which was previously not available for software applications and license security.

For example, while standard cryptographic signature validation is often used to determine if a file has been modified, the embodiments herein that utilize the secure registers of a TPM, e.g., PCRs, provides additional security for licenses above and beyond the use of typically available memory or registers for performing such functions. That is, the use of the TPM registers as in the described embodiments allows for the key to be used only with one specific license file, and only when a hash of the original license file is present in the register of the TPM.

For instance, the key could be used to sign other files as well, if not bound to register values for the hash, and that would allow an attacker to sign a forged license file and bypass security measures to replace an original, expired license file with a new file. So when software calls the verification API, a simple signature validation would succeed without the use of the TPM secure register. The embodiments herein prevent license file secure from being defeated in this way. As noted herein, an attempt to use another licensing file with a valid signature for defeating a licensing requirement cannot be verified because a hash that is extended into a secure register of a TPM will be different from the hash value that was present at key generation.

Embodiments herein are also applicable to mobile and personal devices, and not just to computing devices such as servers, desktops, laptops, and/or the like. In such embodiments, a mobile TPM may be embedded in a mobile device to be utilized in operations for protecting software licensing information via a TPM.

Claim 1:
A method performed by a computing device, the method comprising:
receiving (<NUM>) a request from a software application (<NUM>, <NUM>, <NUM>) to determine whether a license is valid for the software application;
generating (<NUM>) a command that is sent to a trusted platform module, TPM, (<NUM>, <NUM>) responsive to the request, the command specifying an identifier of the software application and including a license file (<NUM>) corresponding to the license, the license file being specific to the software application and being generated for the software application based on application information, wherein the license file is signed using a key (<NUM>) generated by the TPM based on a hash of the license file;
retrieving (<NUM>) the key by the TPM based on a mapping for the identifier of the software application in a mapping data structure subsequent to receiving the command;
validating (<NUM>) the license at the TPM using a secure register (<NUM>) of the TPM based on the key and the license file, wherein validating the license comprises utilizing the retrieved key to validate the signature of the license file; and
providing (<NUM>) by the TPM a validation indication response to the command.