Patent Grant
10318271
The present invention relates to a method and system for programming components, and more specifically to a method and system for updating software components in a program.
Updating software in the field typically takes on a few different approaches. One approach requires that the full program is updated at any renewal. While the advantage of this approach is that any part of the program may be changed at any renewal, it bears the disadvantage of requiring a sizable amount of upload data and code.
A second approach of updatability involves relegating functionality to be data driven, so that data files control paths of control-flow. While this approach does allow behaviour to be changed at run-time, it requires decisions to be built into the software up-front and can cause the renewability aspect of the approach to be limited, especially for the purposes of protecting the code from being attacked.
A third approach uses the availability of dynamic or shared library mechanisms for updating a set of components. While useful, this approach has the disadvantage of requiring a dynamic linking phase to resolve relocatable symbols at run-time giving a performance overhead resulting in the approach being typically used sparingly for a handful of components. Furthermore, the granularity of what functionality lies within the dynamic library is fairly rigid with regards to the overall system. Moreover, certain platforms do not support dynamic linking.
Current methods for dynamically updatable software components are coarsely-granular, slow, or limited in the code and data that may be updated. Additionally, some methods require the software to not be running while taking an update. Those methods that can load updates while running suffer from coarse-granularity and an inability to predict a high confidence level when loading an update dynamically. Furthermore, the ability of updating software components for the purposes of renewing the security as a response to a breach, or as a forerunner to any perceived attack is not well supported. The existing methods for updatable software have been driven by functional updates and responses to defects in fielded products.
Security problems in existing updatable software component mechanisms include an attacker's ability to prevent taking new updates and rolling back to previous updates. Furthermore, the attacker has the ability to gain a lot of information by looking at differences in software component updates. The differential attack can be mounted between software component updates and between different user installations.
It is an object of the invention to provide a method and system that obviates or mitigates at least one of the disadvantages of existing systems.
According to an aspect of the present disclosure, there is provided a method for software renewal, which includes: loading a software component into at least one loadable region of a program by a base component in the program to update the program, the software component being dynamically swapped at run-time of the program in accordance with an update schedule, writing state data associating the state of the update in a storage, upon execution of the software component; testing the state data to verify condition of the updated program, the state data comprising hash chain values; and entangling the state data for verifying the correctness of the updated program with application data used for the program functionality.
According to a further aspect of the present disclosure, there is provided a system for renewing software, which includes: a client including: a processor, and a memory for storing a program including a base loading component for loading a program component into at least one loadable region of the program to update the program, the program component being dynamically swapped at run-time of the program in accordance with an update schedule, the program component having code for writing state data associating the state of the update in a storage, upon execution of the software component, and testing the state data to verify the condition of the updated program, the state data comprising hash chain values, the state data for verifying the correctness of the updated program being entangled with application data used for the program functionality.
These and other features of the invention will become more apparent from the following description in which reference is made to the appended drawings wherein:
Embodiments of the present disclosure are described with reference to
In the description, the terms “loadable”, “swappable”, “updatable”, and “renewable” may be used interchangeably. In the description, the terms “component” and “module” may be used interchangeably. In the description, the terms “programmable component” and “software component” may be used interchangeably.
The embodiments of the present disclosure provide a fine-grained mechanism for supporting software component updates, for example, for support of renewable security in the field and/or performance improvement. The granularity may be defined as software components that may be composed of a single function or any combination of multiple functions. For each renewable software component, there is the opportunity to diversify the contents, meaning that while keeping functionality constant, the structure of the software may be different upon each update, but also, functionality may optionally be variable as the component is updated. This fine-grained mechanism offers a greater flexibility of pieces which may be updated.
The base capability of renewing software components may be combined with the capability for anti-rollback, anti-roll-forward, and forced updates of components. This is achieved, for example, through mechanisms which combine cryptographic hash chains with data tables. These data tables not only contain data for the update mechanism, but also data used in the application. The combination of these multipurpose pieces of data makes the removal of the update mechanism burdensome for the attacker.
According to the embodiments of the present disclosure, single leaf-level functions of a native program may be loaded dynamically into a running program. These ‘hot-swappable’ program components provide the basis for updatable software components for the purpose of the implementation of security features. The mechanism for swapping program components is encapsulated in the program as static code (i.e. the base loading component) (see e.g., 102 of
The loading mechanism for a native component is, for example, but not limited to, a piece of straight-line code without control-flow, with no relocatable symbols, and no references outside the scope other than the parameters and return values to the block of code. Other than the ABI convention (Application Binary Interface), this code does not need to be linked to the rest of the program. Therefore, it is possible to drop this code in place in a program dynamically, as long as there is space in the program and there are no race conditions in what the program is currently executing. Furthermore, it is possible to relax restrictions to what the code may reference if additional mechanisms are introduced that resolve these references. For example, a jump to code outside of the local code is possible as long as there is a jump table of redirections inserted. Similarly, a reference to data outside of the local code is possible as long as there is a table of address redirections inserted. This mechanism can become the equivalent to full-blown run-time dynamic linking. By putting a limit on what a loadable component is permitted to do, it allows for a high performing and efficient dynamic loading mechanism.
In a non-limiting example, the loading mechanism is applied for native applications supported by languages such as C and C++. In another non-limiting example, the loading mechanism is applied to scripting languages and web languages. For example, in scripting languages like python, TCL, and Perl, their evaluation (i.e. eval( )) capabilities form a built-in capability for dynamic updates. Additionally, web languages like Java, JavaScript, Ajax, ASP, and PHP have similar dynamic updatability while a program is running. The dynamic updatability of these scripting-type of languages may be combined with concepts in this disclosure such as anti-rollback, anti-roll-forward, forced updates, and the like to form a renewable system in whatever system context they are working. For example, an HTML5+CSS+JavaScript web system can benefit from the concepts in this invention to provide a renewable system with the dynamic updatability of JavaScript, which in turn, furnishes renewable updates to the HTML5+CSS content.
System Overview
The definition of swappable program components combined with additional concepts provides a framework for the resistance of a number of attacks. Some of these additional concepts include, for example, but not limited to:
One example of the basic mechanism for a renewable system is schematically illustrated in
In a non-limiting example, the dynamically loaded components 104 and 106 are native functions arising from C, C++, assembly code, etc. In a non-limiting example, the dynamically loaded components 104 and 106 are part of scripting language, e.g., Perl python, TCL. In a non-limiting example, the dynamically loaded components 104 and 106 are part of web language, e.g., JavaScript, Java, Ajax, ASP, PHP.
In
One example of the renewable system from a client view is schematically illustrated in
In
In
One example of the renewable system from a server view is schematically illustrated in
In
Referring to
The system can include two types of dynamic loading:
In the fully dynamic loading, the system is always on-line (i.e. tethered/connected to the server). In this set-up, software update components are required to come from the server on a frequent basis and updated components are invoked immediately.
In the partially dynamic loading, the system may be off-line (i.e. not connected to the server) a percentage of the time. In this set-up, software components may be pre-loaded and remain dormant for some time until an update causes a previously loaded component to run.
These fully dynamic and partially dynamic systems have engineering trade-offs with respect to the frequency and size of the software updates. Additionally, there are trade-offs with respect to security. In some cases a partially dynamic system may be preferred over a fully dynamic system, as a designer can prepare dormant code for activation once a threat in the field has been detected.
Code used for both writing and testing state data is included in the swappable component. In
The state data 138 is used for verifying correctness of the updated program. In a non-limiting example, the state data 138 is intermingled with application data 140 used for the program functionality. First, the location of the state data 138 is undisclosed and intertwined with the application data 140, such that the state data 138 may not be easily localized by an attacker. Secondly, locations for the state data 138 are dynamically allocated among locations for the application data 140, meaning that significant state data will be localized dynamically with the running of the program. Thirdly, the state data 138 is not only constant data but is created as computed data which is dependent upon values contained in the application data 140. This last measure resists attacks where state data is modified without changing application data. In effect, the state data has been propagated to include dependencies on application values used in the program 130.
Server-Side Building and Policy Control
The server side 150 of
The policy control 156 monitors and controls how and when updates are deployed to the clients in the system. The policy control 156 determines, for example:
The policy control 156 can either run as a completely automated system, or be run manually or semi-automatically by a system administrator. At the very least, a system administrator monitors the run-time operation of the system through a portal that operates with the policy control 156.
Diversity
Diversity is the concept of applying a differing structure to a software component or set of software components. A differing code structure is an effective means of resisting an attacker's efforts to gain knowledge through comparisons of code. Diversity can be applied in two dimensions:
Diversity can be applied to the base component (e.g., 102 of
Diversity can independently be applied to the swappable/loadable software components. This can be applied spatially as different instances to different customers. As well, this can be applied temporally as each component update is provided. Furthermore, using dimension 2 as described above, functionality may be altered between instances in both the space and time dimension. The ability to change function behaviour in a swappable component can be used, for example, to alter course into a different hash chain than was previously being used. An approach like this can keep clever attackers at bay. This will be described further in the next section.
One example of diversity applied to both base components and to loadable components is schematically illustrated in
For the base components 182 and 192, it shows a differing code structure for instances destined for different customers P and Q. For the loadable components 184 and 194, it shows differing code structure and differing code functionality for each updatable component.
Rejection of Future and Past States (Anti-Rollback and Anti-Roll-Forward)
In a non-limiting example, the state of software update is verified by using a memory slot. Here software update is defined to set pre-defined memory slots in a memory to known values. The mechanism can be used to reject future states. Similarly, the same mechanism can be used to reject past states, so that software updates may not be skipped. Furthermore, when used in cycles, any desired sequence of software updates may be enforced and with a cycle with any predetermined period.
Using multiple data storage slots to verify the state, software updates can both assign state to memory slots and verify correct state. A simplified example is shown in
These values A-D are chosen, for example, such that:
Software updates follow a pre-defined sequence (e.g., A→B→C→D) which enables anti-rollback and anti-roll-forward measures. Anti-rollback measures 230 may verify that data memory slots have not yet attained expected values in future updates. For example, in
Similarly, verifications 232 can be made to resist anti-roll-forward attacks so that software updates are not skipped. For example, in
The verification checks 232 may be concealed and bound to the program by techniques in U.S. Pat. No. 6,842,862 and PCD/CA2011/050157. Alternatively, the values of B or C can be chosen as encryption keys that unlock necessary data or functionality. Also, the ability to cryptographically unlock data may be concealed in the code of an update by using an existing symmetric or asymmetric algorithm with a slight variation. For example, if a white-box implementation of an AES algorithm is varied slightly (e.g. with independent round-keys and with data transformations at the boundaries, as in U.S. Pat. No. 6,842,862) and this code is contained in a software update, then it is the only this update that is able to use predetermined key in the data memory. This method allows the software update to be locked to a key in a slot in memory.
In
Furthermore the anti-rollback and anti-roll-forward mechanisms shown by example may be used interchangeably by cycling patterns in the update system. The chain of updates may contain cycles of any cardinal chosen period greater than 1. In addition, any number of repeating cycles and cycles within cycles may be used and augmented in a dynamic fashion. This flexibility offers the ability to renew security to the field over time.
Forced Updates Using Computed Chains
In a non-limiting example, cryptographic hash chains are used for forced updates. A hash function used for forced updates may be a standard hashing function (e.g. SHA-1, SHA-2, MD-5), or any custom variation of a hash function, or an entirely home-grown hashing function. When used in a chained fashion, a starting data value is run through the function, which in turn becomes the input to the next link in the chain. This periodic system can be made to cycle quickly or slowly at any desired timing, simply by separating the cyclic hash functions by other useful (i.e., application) calculations.
For the software update A 300 of
The predetermined sentinel values can be calculated off-line and embedded in the software, so that when the sentinel value is identified it causes an event which forces a software update to occur (314, 334). For example, a software component may be created that allows no more than 1000 invocations. This may be achieved by placing hash function chain at the beginning of the component and embedding the 1000th sentinel hash value (e.g., from an off-line calculation) in the update. When the software component reaches its 1000th invocation, it invokes a forced software update. The forcing behaviour can be achieved in any number of ways, of which examples include:
The sentinel values do not need to be protected as the actual values have no embedded meaning; however, in a non-limiting example, the behaviour of code using sentinel values for the purpose of invoking a forced update is concealed from any potential attacker. This program code can be concealed through tamper-resistance and obfuscation techniques such as those described in U.S. Pat. No. 6,842,862. Additionally, any measures that increase the ambiguity of the association of program behaviour with sets of data values (including the sentinel value) will necessarily pose a barrier to an attacker. For example, the sentinel value can be part of a large table whose values trigger calls to a large set of possible functions, one of which causes a forced update.
The sentinel values and hash chains may be used as a complement to the previously described rollback and roll-forward detection by using memory slots. For example, instead of checking for a specific value in a memory slot for an immediate behaviour, a chained hash of values may be cycled through to finally trigger a rollback or roll-forward detection behaviour.
The above methods can be augmented with additional control methodologies. The methods can be applied for single updates and single update chains. The methods can be augmented into collective behaviors, where multiple updates and multiple update chains react and function together. For example, one forced update may cause two out of three interdependent update chains to react, while leaving one chain to work on a different period.
Another example is the ability to create order dependencies of software component updates. With the policy control 156 of
As another example, policies that are pushed down from the policy control 156 of
The capabilities of forced updates, as well as anti-rollback and anti-roll-forward features, offers the ability for a software system to have more control over the updates. It would be appreciated by one of ordinary skill in the art that the updates described above can be not only for the purpose of security, but also for the purpose of performance improvements, the addition of features, bug fixes, etc. Control over the timing and the triggers for software updates is a useful utility for the long-term maintenance of any software system, which is especially important in a connected system environment.
Entanglement of State Data with Application Data
In a non-limiting example, the use of internal data (i.e., state data, such as 138 of
Data for the purposes of state or application may be located throughout the area for storage in either a static sense or a dynamic sense. In a static sense, data resides for the lifetime of the program in a constant location. In a dynamic sense, data may reside at different locations depending on where the program is in its lifetime.
Duplication of data is method of creating decoys or diversions for an attacker. For example, state data which is used to verify the current state of an update may be duplicated among 2 or more physical locations in storage. Then, the program can dynamically decide to count on only one (or more) of these locations and create decoy data in the other locations. As the attacker does not know which locations are legitimate, he will be led astray from the real state data. Further to this, the program can be made to dynamically rely on different locations as the program runs on. This will leave the attacker guessing as to which and when state data locations are legitimate.
Splitting of data includes the creation of multiple locations for one piece of data. The sub-pieces which create the final state data may be distributed into disjoint locations, combined with other unrelated data, and/or duplicated as well. The common API for accessing the data controls how the data is recombined in both a static and dynamic sense. The manner in which the data is recombined can vary depending on point in the program during its lifetime.
Dependencies between state/state data and state/application data may be achieved through techniques found in PCT/CA2011/050157. Dependencies can be created for either constant or variable data, consisting of data carriers and data bindings into the program. Adverse changes to the data without an understanding of the dependencies can cause the program to malfunction.
In addition to this common data access API, a compilation tool can be used to analyse and intermingle the code in the data access API with application and state handling code. This is in an effort to automate some or all of the steps described above.
As an added measure to state data, the software now has the ability to collect telemetry data. For example, as states are tracked by updates, it is also possible to track states that are not permitted by a policy. We can define states that are prohibited outright and disallow the software to continue (as described earlier); however, on the other hand if we consider these states as discouraged then we can create policies that count the number of discouraged states as telemetry data. This telemetry data can then be sent back to the server periodically, where the Policy Control (e.g., 156 of
It will be appreciated that the invention also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the invention into practice. The program may be in the form of source code, object code, a code intermediate source and object code such as partially compiled form, or in any other form suitable for use in the implementation of the method according to the invention. The carrier may be any entity or device capable of carrying the program. For example, the carrier may include a storage medium, such as a ROM, for example a CD ROM or a semiconductor ROM, or a magnetic recording medium, for example a floppy disc or hard disk. Further the carrier may be a transmissible carrier such as an electrical or optical signal, which may be conveyed via electrical or optical cable or by radio or other means. When the program is embodied in such a signal, the carrier may be constituted by such cable or other device or means. Alternatively, the carrier may be an integrated circuit in which the program is embedded, the integrated circuit being adapted for performing, or for use in the performance of, the relevant method.
One or more currently preferred embodiments have been described by way of example. It will be apparent to persons skilled in the art that a number of variations and modifications can be made without departing from the scope of the invention as defined in the claims.
This application is the continuation of U.S. patent application Ser. No. 14/387,215, filed Jan. 5, 2015 which is a National Stage of International Patent Application No. PCT/CA2012/000307, filed Mar. 22, 2012, the disclosure of which is hereby incorporated by reference in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 6128773 | Snider | Oct 2000 | A |
| 6341373 | Shaw | Jan 2002 | B1 |
| 6842862 | Chow et al. | Jan 2005 | B2 |
| 7397916 | Johnson et al. | Jul 2008 | B2 |
| 7496910 | Voskuil | Feb 2009 | B2 |
| 7562214 | Riordan | Jul 2009 | B2 |
| 7818736 | Appavoo et al. | Oct 2010 | B2 |
| 7934210 | Stampfli et al. | Apr 2011 | B1 |
| 9588756 | Liem et al. | Mar 2017 | B2 |
| 20030191870 | Duggan | Oct 2003 | A1 |
| 20030221121 | Chow et al. | Nov 2003 | A1 |
| 20040139340 | Johnson et al. | Jul 2004 | A1 |
| 20040158742 | Srinivasan | Aug 2004 | A1 |
| 20050022026 | Riordan | Jan 2005 | A1 |
| 20050132249 | Burton et al. | Jun 2005 | A1 |
| 20050132349 | Roberts et al. | Jun 2005 | A1 |
| 20050262076 | Voskuil | Nov 2005 | A1 |
| 20060265704 | Holt | Nov 2006 | A1 |
| 20070061372 | Appavoo et al. | Mar 2007 | A1 |
| 20080022380 | Lu et al. | Jan 2008 | A1 |
| 20080051075 | Einloth | Feb 2008 | A1 |
| 20090259999 | Srinivasan | Oct 2009 | A1 |
| 20100268692 | Resch | Oct 2010 | A1 |
| 20110154299 | Kim et al. | Jun 2011 | A1 |
| 20120030758 | van den Berg et al. | Feb 2012 | A1 |
| 20120304164 | van der Zweep | Nov 2012 | A1 |
| 20140122901 | Bilke | May 2014 | A1 |
| Number | Date | Country |
|---|---|---|
| 1694031 | Nov 2005 | CN |
| 1770121 | May 2006 | CN |
| 1906575 | Jan 2007 | CN |
| 104303148 | Jan 2015 | CN |
| 1 643 361 | Apr 2006 | EP |
| 2013138895 | Sep 2013 | WO |
| Entry |
|---|
| Silva, John Edward, “An Overview of Cryptographic Hash Functions and Their Uses,” SANS Institute, Jan. 15, 2003, p. 1-11. (Year: 2003). |
| Extended European Search Report cited in European Application No. 12871704.8 dated Oct. 15, 2015. |
| International Search Report and Written Opinion for International Patent Application No. PCT/CA2012/000307 dated Dec. 14, 2012. |
| Second office action received in Chinese patent application No. 201280073360.3, dated Oct. 10, 2017, 20 pages. |
| Communication pursuant to article 94(3) EPC issued patent application No. 12871704.8, dated Jun. 27, 2016, 4 pages. |
| Communication pursuant to rules 70(2) and 70a(2) issued patent application No. 12871704.8 , dated Nov. 3, 2015, 1 page. |
| First office action received in Chinese patent application No. 201280073360.3, dated Dec. 5, 2016 19 pages. |
| International Preliminary Report on Patentability issued by WIPO in PCT application No. PCT/CA2012/000307, dated Oct. 2, 2014 9 pages. |
| Non-Final Office Action dated Jul. 15, 2016 in U.S. Appl. No. 14/387,215, 34 pages. |
| Notice of Allowance dated Oct. 25, 2016 in U.S. Appl. No. 14/387,215, 27 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20170147331 A1 | May 2017 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14387215 | Jan 2015 | US |
| Child | 15426090 | US |
