Software applications (or programs) may be executed locally (on a client device) or over a network via a web browser, for example. A browser application can also run in the browser in the offline mode (locally) behaving like a native one running locally.
When a software application is being executed by a processor, the environment in which the execution is being performed is a so-called “white-box” environment if the user (or a third party) has access to the processing so that the user can observe and alter the execution of the software application (e.g. by running a suitable debugger)—such alterations could be changes to the process flow or changes to the data being processed. This observation and/or alteration of the execution of the software application may be referred to as tampering. The user may observe or alter (or in other words tamper with) the execution of the software application in order to satisfy their own aims or goals, which may not be possible to satisfy if the software application were to run normally without being tampered with. Such tampering to achieve a particular aim or goal may be referred to as goal-directed tampering. Goal-directed tampering may involve, for example, observing and/or altering the execution of a software application being run in a white-box environment in order to obtain or deduce a cryptographic key that is used by the software application to process digital data (e.g. a decryption key for decrypting data).
Various techniques are known for protecting the integrity of a data processing software application (or program or system) which is being run in a white-box environment. One exemplary technique can be found in “White-Box Cryptography and an AES Implementation”, by Stanley Chow, Philip Eisen, Harold Johnson, and Paul C. Van Oorschot, in Selected Areas in Cryptography: 9th Annual International Workshop, SAC 2002, St. John's, Newfoundland, Canada, Aug. 15-16, 2002, the entire disclosure of which is incorporated herein by reference. Such techniques generally aim to hide the embedded knowledge of the application by introducing additional complexity and/or randomness in the control and/or data paths of the software application. This additional complexity and/or randomness has the effect of obscuring or obfuscating the information (or data) or execution path of the software application. As a result of this obfuscation, it becomes more difficult to extract information from the application by code inspection and it is more difficult to find and/or modify the code that is associated with particular functionality of the software application. It is therefore much more difficult for an attacker with access to the software application running in a white-box environment to retrieve sensitive data or alter the operation of the software application in order to meet their own goals by tampering with the execution of the software application. As such, the ability of the attacker to carry out goal-directed tampering is reduced. These techniques which aim to reduce the ability of an attacker to carry out goal-directed tampering may be considered to improve the tamper-resistance of the software. If it is sufficiently difficult for an attacker to carry out goal-directed tampering, then, for any practical purposes, the software application may be considered to be tamper-resistant, even if theoretically tampering is still possible.
When a software application is being executed by a processor, the software application generally requires access to a data store or database or memory. Data stored in a data store may be encrypted or transformed so as to provide a further barrier for a potential attacker. Such a data store may be considered as a “protected” data store.
The prior art described above is schematically illustrated in FIG. 1. In particular, FIG. 1 shows a software application 10 which includes a “protected” (or tamper-resistant) part 12, and a “protected” data store 14. However, any interactions 16 between the protected part 12 of the application 10 and the protected data store 14 are still visible to an attacker. In other words, access 16 to the data store 14 by the software application 10 is visible to an attacker.
The present invention seeks to obfuscate access to a data store by a software application.
USPTO Backgrounds
USPTO Backgrounds