Electrical computers and digital processing systems: support – Data processing protection using cryptography
Reexamination Certificate
1999-08-19
2004-08-17
Barrón, Gilberto (Department: 2132)
Electrical computers and digital processing systems: support
Data processing protection using cryptography
C713S194000, C713S190000
Reexamination Certificate
active
06779114
ABSTRACT:
The present invention relates generally to computer software, and more specifically, to a method and system of making computer software resistant to tampering and reverse-engineering.
BACKGROUND OF THE INVENTION
The market for computer software in all of its various forms is recognized to be very large and is growing everyday. In industrialized nations, hardly a business exists that does not rely on computers and software either directly or indirectly, in their daily operations. As well, with the expansion of powerful communication networks such as the Internet, the ease with which computer software may be exchanged, copied and distributed is also growing daily.
With this growth of computing power and communication networks, a user's ability to obtain and use unauthorized or unlicensed software is increasing, and a practical means of protecting such computer software has yet to be devised.
As well, personal computers are found in a substantial percentage of all households in America, and in Canada. Home computing is also common in Europe and various parts of the SEATO region. However, when home computer users access banking or other online services via the World Wide Web or the like, much of the processing must be in the physically protected servers rather than in the home computers, because the applications running on home computers are vulnerable to tampering.
Any bank or other service institution must protect itself by ensuring that operations whose results must be trusted are performed in secured environments. The result is that service support tends to be centralized at a relatively small number of sites. Servers must therefore be massive to support heavy transaction loads. If the clientele doubles, the centralized support must likewise be doubled.
This need for centralized physical security requires centralized implementations of services. Centralized services are undesirable as they are inherently vulnerable to localized attacks and provide a single point of failure.
A possible, but impractical, solution would be to house centralized servers in fortresses, and to implement them on fault-tolerant architectures with fault-tolerant tools. However, both aspects of this approach are quite costly.
Before describing the difficulties and failed approaches, the general language used in the art will be outlined.
Computer software is generally written by software developers in a high-level language which must be compiled into low-level object code in order to execute on a computer or other processor.
High-level computer languages use command wording that closely mirrors plain language, so they can be easily read by one skilled in the art. Typically, source code files have a suffix that identifies the corresponding language. For example, Java is a currently popular high-level language and its source code typically carries a name such as “prog1.java”. Such files are generally referred to as “.java” files. Other examples include the high-level computer languages C and C++, where source files are typically “.c” or “.cpp” (for “C plus plus”) files, respectively, as in “prog1.c” or “prog1.cpp”, respectively.
High-level structure refers to, for example, the class hierarchy of object oriented programs such as those in Java™, or the module structure of module-based languages such as Ada™ and Modula-2™ programs
Object-code generally refers to machine-executable code, which is the output of a software compiler that translates source code from human-readable to machine-executable code. In the case of Java™, these files typically are commonly named “filename.class”, where the “filename” may be any valid identifier string, and are referred to as “.class files”.
The low-level structure of object code refers to the actual details of how the program works, including scalar data flow and detailed control flow including inter-routine call-return linkages. Low-level analysis usually focuses on, or at least begins with, one routine at a time. This routine may be variously called, for example, a procedure, function or method; in C or C++ all routines are called “functions”, whereas in Java, they are all called “methods”. The conventions vary with the source high-level software language. Analysis of individual routines may be followed by analyses of wider scope in some compilation tool sets.
The low-level structure of a software program is usually described in terms of its data flow and control flow. Data flow is a description of the variables together with the operations performed on them, and the way information flows from one variable to another. Control flow is a description of how control jumps from place to place in the program during execution, and the tests that are performed to determine those jumps.
Instructions which potentially transfer control to another instruction are referred to as branches. A conditional branch is a branch whose destination is determined by its input value or values. A boolean branch is a conditional branch which takes a single input value and chooses between two destinations, one associated with the input value “true”, and the other with the input value “false”.
Tampering refers to changing computer software in a manner contrary to the wishes of the original author. In the past, computer software programs had limitations encoded into them, such as requiring password access, preventing copying, or allowing the software only to execute a predetermined number of times or for a certain duration. However, because the user has complete access to the software code, techniques have been found to identify the code administering these limitations. Once this coding has been identified, the user is able to overcome these programmed limitations by modifying the software code.
To protect a program from hostile attackers, both the behaviour of the program and the knowledge which it embodies must be protected. That is, one must prevent changes to its behaviour, and one must conceal its embedded knowledge. The prevention of behavioral changes is referred to as “tamper-proofing”, and the concealment of embedded knowledge as “obscuring”.
When an attacker seeks to subvert the behaviour of a program, for example, by removing password checking or eliminating a date-check on a time-limited trial version of a software package, the attack is generally directed at control flow, rather than the data flow. Changing behaviour through an attack on the data flow generally requires substantial insight into the way the program operates, whereas an attack on control flow can often succeed with almost no knowledge of how the application functions.
Although these two aspects of program protection are related, they are not the same. For example, it is possible to conceal almost all of the knowledge embedded in a program, but still leave it vulnerable to tampering.
Consider, for example, an application program which is password-protected to prevent unauthorized use. When an attempt is made to use it, it asks for a password to determine whether its use is valid. To subvert this password checking, it is not necessary to understand the application or how it operates, or even how the password is stored or checked. Typically, all that is needed is to find the particular conditional branch instruction whose execution results in either refusal or acceptance of the user. Replacing this single instruction with an unconditional branch to the location leading to “acceptance” completely subverts the password checking. Discovering the accept/reject conditional branch can be done by low-level tracing of the initial phases of execution. No knowledge of anything else about the program, other than what is needed to find the crucial branch-point, is required. This remains true irrespective of how obscure any other information, whether in algorithms or in data, might be.
Obscurity, in and of itself, does not necessarily prevent tampering. In fact, obscuring is necessary, but not sufficient, for tamper-proofing.
There are many tools on the market whose purpose is to obfuscate the algorithms in progra
Chow Stanley T.
Gu Yuan
Johnson Harold J.
Barrón Gilberto
Cloakware Corporation
Gurshman Grigory
Maclean Cassan
LandOfFree
Tamper resistant software-control flow encoding does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Tamper resistant software-control flow encoding, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Tamper resistant software-control flow encoding will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3362160