SYSTEMS AND METHODS FOR WATERMARKING SOFTWARE AND OTHER MEDIA
Systems and methods are disclosed for embedding information in software and/or other electronic content such that the information is difficult for an unauthorized party to detect, remove, insert, forge, and/or corrupt. The embedded information can be used to protect electronic content by identifying the content's source, thus enabling unauthorized copies or derivatives to be reliably traced, and thus facilitating effective legal recourse by the content owner. Systems and methods are also disclosed for protecting, detecting, removing, and decoding information embedded in electronic content, and for using the embedded information to protect software or other media from unauthorized analysis, attack, and/or modification.
Latest Intertrust Technologies Corporation Patents:
- Product Rights Management Systems and Methods Using Secure Tags and Cryptographic Tokens
- Digital content integrity verification systems and methods
- Content Distribution and Management Systems and Methods Using Cryptographic Tokens
- TRUST AND IDENTITY MANAGEMENT SYSTEMS AND METHODS
- Policy managed vehicle operation systems and methods
This application is a continuation of U.S. application Ser. No. 15/144,145, filed May 2, 2016, which is a continuation of U.S. application Ser. No. 14/462,513, filed Aug. 18, 2014 (now U.S. Pat. No. 9,350,547), which is a continuation of U.S. application Ser. No. 13/738,311, filed Jan. 10, 2013 (now U.S. Pat. No. 8,892,893), which is a continuation of U.S. application Ser. No. 12/784,202, filed May 20, 2010 (now U.S. Pat. No. 8,370,634), which is a continuation of U.S. application Ser. No. 11/927,220, filed Oct. 29, 2007 (now U.S. Pat. No. 7,739,511), which is a continuation of U.S. application Ser. No. 09/629,807, filed Jul. 31, 2000, now abandoned, which claims priority from U.S. Provisional Application Ser. No. 60/146,420, entitled “Software Watermarking Systems and Methods,” filed Jul. 29, 1999, and is related to commonly-assigned U.S. patent application Ser. No. 09/629,546, entitled “Software Self-Defense Systems and Methods,” filed Jul. 31, 2000 (“the Software Self-Defense application”), each of which is hereby incorporated in its entirety by reference.
COPYRIGHT AUTHORIZATIONA portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
FIELD OF THE INVENTIONThe present invention relates to the protection of electronic content. More particularly, the present invention relates to systems and methods for watermarking computer software or other electronic content for the purpose of identifying content or controlling its use, and for detecting, tracing, and resisting attacks.
BACKGROUND OF THE INVENTIONAdvances in microelectronics and networking technology have enabled the development of increasingly complex computer systems. The software that controls these systems or operates thereon has also become exceedingly complex. As a result, companies often spend large sums to develop the software that they sell to consumers or use in commerce. Yet software, like other forms of electronic content—such as digital music, images, video clips, and text—can be easily modified, copied, and distributed without the permission of its creator.
Although encryption is often used to prevent the unauthorized use of electronic content, encryption is insufficient to protect content at all times, since the content must be decrypted before it can be used for its intended purpose, and once decrypted, can be saved, modified, copied, and/or transmitted to others in unencrypted form.
Content can also be protected by marking it with special identification information. The added information may, for example, identify the person to whom the content was sold. If all authorized copies of the content include such identification information, then someone who attempts to copy or sell the content without the creator's permission can be identified by examining the identification information found in the unauthorized copies.
Thus, a person wishing to distribute unauthorized copies of the electronic content may try to avoid detection by removing the identification information, or by forging the identification information of an innocent party. To avoid such attacks, content owners often try to hide the identification information, and/or to embed it in such a way that removing it from the content will render the content useless or less desirable.
Information that is added to electronic content in the manner described above is often referred to as a “watermark,” by analogy to the marks used by paper manufacturers to indicate the origin and quality of their paper. There are a number of fundamental differences, however, between digital watermarks and paper watermarks, including differences in the way the watermarks are applied and used, and in the properties that the watermarks possess.
While increasing attention has been paid to the development of techniques for watermarking digital images and digital audio and video content, relatively little attention has been paid to the development of techniques for watermarking software. Moreover, the watermarking techniques that have been developed for electronic content, and software in particular, are often relatively complicated to apply and/or relatively easy to defeat. What is needed are systems and methods for more efficiently and/or more robustly embedding information in software and other electronic content. Improved systems and methods are also needed for detecting, extracting, and decoding information embedded in software or other electronic content, and for using the embedded information to manage and enforce the rights and interests of the content owner.
SUMMARY OF THE INVENTIONThe present invention provides systems and methods for embedding information in software and/or other media such that the information is difficult for an unauthorized party to detect, remove, insert, forge, and/or corrupt. The embedded information can thus be used to protect content by identifying the content's source, thereby enabling unauthorized copies or derivatives to be reliably traced, and thus facilitating effective legal recourse by the content owner. Systems and methods are also disclosed for protecting, detecting, removing, and decoding the embedded information, and for utilizing the embedded information to, e.g., protect software or other media from unauthorized analysis, attack, and/or modification. It should be appreciated that the present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, or a computer readable medium. Several inventive embodiments of the present invention are described below.
In one embodiment, obfuscation techniques are used to impede an attacker's attempts to understand the structure and/or operation of a program. In general, these techniques also make watermarks more difficult to identify, remove, and/or replace, as they typically make it more difficult to deduce the importance, or lack thereof, of particular code sequences to the program's correct operation. Tamper resistance techniques are also used to make it difficult for attackers to analyze or modify a program without detection. The present invention also provides methods for making watermarks blend in with the rest of the program, thus making it difficult for an attacker to spot the watermarks in the program's static image. The present invention also provides a variety of techniques for resisting specific attacks, including collusive and auto-collusive attacks. The systems and methods of the present invention also can be used to make it difficult for an attacker to use knowledge gained from one successful attack to mount another.
In one embodiment, a system and method for watermarking a computer program (or other piece of electronic content) is provided. The program is “primed” by inserting a sequence of code that is operable to produce a distinctive pattern. The primed program may then be compiled or transformed in some other manner. The primed program is then watermarked by finding the distinctive pattern, and inserting watermarking information at a location indicated thereby. In one embodiment, the sequence of programming code is inserted via a macro or inlined function, and comprises a sequence of executable machine language instructions.
In another embodiment, a method for inserting a plurality of copies of a watermark into a computer program is described. Each copy of the watermark is combined with a different, quasi-randomly-selected number, or “salt,” and the combination is encrypted and embedded in the program. A digital signature of the watermark copy may also be included in the combination. In one embodiment, an unencrypted copy of the salt is also embedded in the program with the encrypted combination. A watermark can be detected by decrypting the encrypted combination and identifying the relationship between the decrypted copy of the watermark and the signature, and/or between the decrypted salt and the unencrypted copy of the salt.
In another embodiment, a method for watermarking copies of a computer program is disclosed. A unique combination of obfuscating transformations is applied to a copy of the computer program, the obfuscating transformations being operable to create a unique “signature.” Other copies of the computer program can also be obfuscated with other unique combinations of transformations. An individual copy of the computer program can be identified by detecting the signature left by the obfuscating transformations that were applied to that copy.
In another embodiment, a method for detecting a watermark embedded in an executable software file is described. The watermark is detected by sequentially proceeding through the executable file looking for distinctive registration information associated with the watermark. In one embodiment, portions of the executable file are decrypted, and the resulting decrypted value is analyzed to see if it satisfies a predefined relationship. If it does, then the decrypted value is deemed to be part of the watermark. The process of decrypting and analyzing portions of the executable file can be repeated until the entire watermark is retrieved.
In yet another embodiment, a method for watermarking a piece of software in a manner designed to resist a collusive attack is described. Watermarks are encoded as a sequence of multi-bit symbols, wherein each symbol is selected from a predefined alphabet. In a preferred embodiment, the length of the sequence, the size of the alphabet, and the number of bits in each symbol are selected in relation to an expected number of colluders. This encoding technique is simpler than the Boneh-Shaw encoding technique, and is shorter in length if the expected number of colluders is small.
In another embodiment, a method for protecting a program instance-specific watermark (or fingerprint) from collusive attacks is described. The method involves performing a number of obfuscating transformations on the program—such as rearranging the program's basic blocks, inserting opaque predicates, rearranging the program's control flow graph, and the like—to create a number of different program versions. Instances of each version can be marked with instance-specific watermarks. The number of expected colluders can be used to determine how many versions to create.
In another embodiment, a method for watermarking and distributing a piece of software is described. The software is divided into at least two portions. Copies of the first portion are distributed to consumers, and copies of the second portion are individually watermarked and maintained in a database. When a consumer wishes to activate his or her copy of the first portion of the software, the consumer contacts the database administrator and asks for a copy of the second portion. The copy of the second portion is combined with the copy of the first portion, either on the consumer's computer system or at a remote server, and a record is maintained of the unique watermark contained in the copy of the second portion that was used. In some embodiments, additional watermarks can be embedded in the copy of the second portion before it is combined with the consumer's copy of the first portion.
In another embodiment, a method is provided for protecting watermarks in a computer program from unauthorized detection or modification. A number of obfuscating transformations are performed on the program before and/or after watermarking, and one or more self-checking or other tamper-resistance mechanisms are added to the program. Mechanisms for detecting debuggers or other analysis tools may also be added.
These and other features and advantages of the present invention will be presented in more detail in the following detailed description and the accompanying figures which illustrate by way of example the principles of the invention.
The present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements, and in which:
A detailed description of the invention is provided below. While the invention is described in conjunction with several embodiments, it should be understood that the invention is not limited to any one embodiment. On the contrary, the scope of the invention is limited only by the appended claims and encompasses numerous alternatives, modifications, and equivalents. For example, while embodiments are described in the context of a system and method for watermarking software, those skilled in the art will recognize that the disclosed systems and methods are readily adaptable for broader application. For example, without limitation, the present invention could be readily applied in the context of watermarking other types of protected content, such as audio, video, or textual files. In addition, while numerous specific details are set forth in the following description in order to provide a thorough understanding of the present invention, the present invention may be practiced according to the claims without some or all of these details. Finally, for the purpose of clarity, certain technical material that is known in the art has not been described in detail in order to avoid obscuring the present invention.
1. OverviewThe present invention provides systems and methods for watermarking software and other media, such that the watermarks are difficult for unauthorized parties to detect, remove, insert, forge, and/or corrupt. Watermarking is closely related to information hiding techniques such as steganography and fingerprinting, and indeed, the precise dividing line between these techniques is somewhat ill-defined. Thus, for ease of explanation, and unless otherwise clear from the context, the term “watermarking” will be used to refer to information hiding and/or embedding techniques in general, and is intended to encompass what some practitioners may classify as watermarking, steganography, fingerprinting, and/or other information hiding or embedding techniques.
As shown in
When watermarking a piece of software, care should be taken to avoid adversely affecting the software's performance. While a certain amount of delay may be tolerable, incorrect program execution typically will not. Thus, effective software watermarking techniques—like effective techniques for watermarking other media—should take reasonable steps to reduce or minimize the amount of perceptible differences between the watermarked and the unwatermarked versions of the software, and between differently-watermarked copies of the software. Stated differently, it will generally be desirable to maintain functional equivalence between differently watermarked copies of a piece of software and the original, unwatermarked program. It should be noted, however, that equivalence is not an absolute notion. For example, if a program includes code that receives two inputs, processes them, and generates an output, a first instance may take the inputs 2 and 2 and yield 4, while a second instance may take 2 and 2 and yield 5, and a third instance may take 2 and 2 and yield 6. Under a strict definition of equivalence, these programs would not be equivalent, as they produce different results for the same input. However, if one is only interested in whether the result is a positive or a negative number, such programs could be considered equivalent. Thus, the watermarked program need not be identical to the original program to be considered its equivalent, and will generally have a variety of observable differences when executed on a computer. For example, different values may be stored in particular RAM locations, execution times may be different, and/or different results may be computed. However, an effective software watermarking technique will strive to maintain equivalence between the behavior observed by a user of the unwatermarked software and the behavior observed by a user of a watermarked version of the software, both in terms of the results generated by the software, and preferably also in terms of the amount of time and space the software consumes while generating those results.
1.1. Threats and Countermeasures
In a general sense, an “attacker” can be seen as anyone who attempts to use a program in an unauthorized manner. For example, an attacker might be a person who attempts to make or distribute unauthorized copies of a piece of software, or a person who attempts to use one of those unauthorized copies. An attacker might also be a person who attempts to modify a program to perform functions that the author did not intend the program to perform, or for which the attacker has not obtained the necessary permissions. An attacker might also be a competitor of the software's author or owner, who wishes to misappropriate portions of the software or to undermine the software's effectiveness. Watermarking techniques can be used to resist, prevent, and/or detect some or all of these general attacks, and thus, at a more specific level, an attacker can be seen as a person who attempts to circumvent the protection offered by a watermarking scheme.
There are a variety of attacks that might be mounted against a watermarking scheme. To the extent a watermark is used to identify attackers or to prevent certain uses of the watermarked content, an attacker may attempt to remove the watermark or replace it with another, valid watermark. Similarly, if a watermark is required in order to use the content in certain ways, an attacker may attempt to add such a watermark to unwatermarked content in order to gain access to the restricted features. Thus, there is a need for systems and methods which are resistant to both unauthorized removal and unauthorized addition of watermarks. In many cases, the means for resisting these attacks will be the same or closely related.
Attackers might apply a variety of static, dynamic, manual, or automatic attacks to detect, remove, and/or forge marks. For example, an attacker might examine the static binary image of the program in order to determine how the program operates and what each particular programming construct does. Or the attacker might simply look for unusual programming constructs, and focus his analysis there. An attacker might also examine the execution of the program dynamically, using, e.g., a debugger or other specialized tool, in an attempt to further understand the program's operation and the purpose of the individual programming statements and data structures contained therein. For example, an attacker might search for code that is never used or that has no practical effect on the program's execution. Having found such code, an attacker might simply remove it.
An attacker might also compare two instances of a program, looking for dissimilarities between the two. If the programs contain different watermarks—for example, if the programs are watermarked with information regarding the identity of their respective users—these differences will show up on comparison. An attacker might then change one program to contain the watermark of the other, or might remove both watermarks. This type of attack is known as a collusive attack, and is particularly difficult to defend against.
As described in more detail below, the present invention provides systems and methods for creating watermarks that are resistant to some or all of these attacks. For example, in one embodiment obfuscation techniques are used to impede an attacker's attempts to understand the structure and/or operation of a program. In general, these techniques also make watermarks more difficult to identify, remove, and/or replace, as they typically make it more difficult to deduce the importance, or lack thereof, of particular code sequences to the program's correct operation. Tamper resistance techniques can also be used to make it difficult for attackers to analyze or modify a program without detection. Similarly, special measures can be taken to make the watermarks themselves blend in with the rest of the program, thus making it difficult for an attacker to spot them in the program's static image. The present invention also provides a variety of techniques for resisting specific attacks, including collusive and auto-collusive attacks. The systems and methods of the present invention also can be used to make it difficult for an attacker to use knowledge gained from one successful attack to mount another.
1.2. Program Structure and Formation
The design of optimal watermarking techniques typically requires an understanding of the media into which the watermarks are to be inserted. In the case of software, this involves understanding the structure of the program that is to be watermarked.
The resulting executable program 218 contains machine language instructions that a microprocessor can execute. The format of an executable program will typically vary depending on the hardware platform and/or operating system on which the executable program is designed to run. Due to the relative ubiquity of computer systems that use Intel® microprocessors and the Microsoft® Windows™ operating system, many of the examples and illustrations set forth herein will, for ease of explanation, be modeled after the Portable Executable (PE) format used by those systems; however, it will be appreciated that the concepts described herein are generally applicable to other platforms.
As shown in
Executable file 300 also includes a text or code section 304 containing the machine code of the program. For purposes of illustration, and to improve readability, the “machine code” shown in
As shown in
Referring once again to
Executable 300 may also include relocation information 312, a symbol table 314, and debugging information 316. Relocation information 312 identifies the instructions and data in program 300 that depend on absolute addresses. If instructions or data are moved to a different address, the relocation table can be used to adjust these addresses appropriately. Thus, the relocation table is typically useful for other programs, such as debuggers or linkers. Similarly, symbol table 314 contains information about the names and locations of functions, procedures, global variables, labels, and the like. Debugging information 316 contains a variety of information for use by debugging tools. For example, debugging information 316 typically includes information that enables a debugger to map machine language instructions to their source-code counterparts. Although relocation information, symbol table(s), and debugging information are often generated automatically by a compiler, it is generally possible for this information to be removed from an executable program without affecting the program's operation, since the information contained in these tables is typically not used at runtime.
A typical executable file may also contain a variety of other components. For example, executable file 300 may contain an import table and/or an export table listing the external references that are made by the program or the internal locations that can be referenced by outside programs, respectively. An executable file 300 may also contain jump tables, virtual function tables, index tables, and the like. More information on the components of executable files is readily available. For example, information regarding the PE file format can be found in “Microsoft Portable Executable and Common Object File Format Specification,” rev. 6.0, Visual C++ Business Unit (Microsoft 1999)(see also, http://msdn.microsoft.com/library/specs/msdn_pecoff.htm). As described in more detail below, the format of the executable file and the intricacies of the microprocessor's instruction set will typically offer a variety of opportunities for the application of watermarking techniques.
Programs are typically distributed to consumers or other users in executable form. This allows the consumer to simply load the program onto a computer and use it, without needing to first compile the program into machine-readable form. Distributing executable code, rather than source code, also makes the underlying details of the program's operation more difficult for an attacker to understand or modify. However, some programs are distributed in source code form or in other relatively high-level forms. Thus, the present invention provides a variety of systems and methods for applying watermarks, some of which are applicable generally to code in whatever form it is distributed, and others of which are specific to a given code form (e.g., source or machine code) or processor/operating system platform.
- a processing unit 416;
- system memory 418, usually including high speed random access memory (RAM), read-only non-volatile memory (ROM), and a bulk non-volatile storage unit (e.g., a hard disk and/or flash memory) for storing programs and data for use and execution by processing unit 416;
- one or more input/output devices, such as:
- network interface 410 for communicating with other systems via a network 403 such as the Internet;
- I/O port 412 for connecting to one or more peripheral devices; and/or
- one or more disk drives 414 for reading from, and/or writing to, diskettes, compact discs, DVDs, and/or other computer-readable media;
- a user interface 426, including a display 428 and one or more input devices, such as keyboard 406 and mouse 408; and
- one or more internal buses 440 for interconnecting the aforementioned elements of the system.
The operation of system 402 is controlled primarily by programs contained in system memory 418 and executed by the system's processing unit 416. For example, system 402 might contain an operating system and one or more watermarked or unwatermarked application programs. If system 402 is being used to apply watermarks to a piece of software, or to extract watermarks therefrom, it might also contain, e.g., a binary code modification tool for modifying the executable image of a program, and/or a variety of programs or modules that implement or embody the techniques described herein. It should be appreciated that while
As discussed above, the information conveyed by a watermark is commonly referred to as the payload. The payload may contain virtually any type of information, including, for example, information that identifies the watermarked item, its owner, its licensee, and/or the terms of the license. Watermarks can also be used in connection with special hardware and/or software to control access to software or other content, the special hardware and/or software checking for the presence of the watermark and enforcing whatever rules or controls are explicitly or implicitly contained therein. For example, use could be made of techniques such as those described in commonly-assigned U.S. Pat. No. 5,943,422, entitled “Steganographic Techniques for Securely Delivering Rights Management Control Information Over Insecure Communication Channels,” issued Aug. 24, 1999 (“the '422 patent”), and/or U.S. Pat. No. 5,892,900, entitled “Systems and Methods for Secure Transaction Management and Electronic Rights Protection,” issued Apr. 6, 1999 (“the '900 patent”), both of which are hereby incorporated by reference in their entirety. In some embodiments the payload is encrypted or otherwise encoded as described in more detail below.
The system designer will typically want to control access to the information contained in the payload. That is, the system designer will want to control who is able to read the watermark and/or what they are allowed to know about the watermark-reading process. The system designer's choices on these issues may influence the nature of the encoding and embedding steps that are used to insert the payload into the substrate.
2.1. Privately Readable
One option is to make the payload privately readable. This can be done, for example, by encoding or inserting the payload using a secret key or technique. This type of watermark may, for example, be used for forensic purposes, where it is not necessary to delegate the task of detecting and/or extracting the watermark to potentially untrusted or insecure devices or entities. A privately-readable watermark may contain information such as the software's serial number, information about the user and/or the transaction by which the user acquired the software, or virtually any other type of information. In general, the payload can either carry this information explicitly, or carry an index into a separate database that stores the information.
2.2. Publicly Readable
A “publicly-readable” watermark is one which a user/client's device is capable of detecting and/or extracting—possibly on-the-fly—for purposes of e.g., authorizing certain uses of the watermarked item, providing an information channel, or the like. A publicly-readable (and/or publicly-writeable) watermark may, for example, be used in situations where a consumer's content-rendering device is expected to make decisions regarding the allowable uses of a piece of content based on the presence, absence, or contents of one or more watermarks. Thus, a publicly-readable watermark may be used in situations where the watermark payload consists of rules and controls that govern the content's use, or the like.
In general, watermarks intended for detection by client-side watermark readers will be more susceptible to certain attacks, since the client-side watermark reader will typically afford an attacker the opportunity to perform experiments, without risking detection, to identify the watermark and/or to determine how the watermark was embedded. In contrast, with a privately-readable watermark the attacker will typically not have a convenient, risk-free mechanism by which he can determine whether his attempts to identify and/or remove the watermark have been successful.
In general, a client-side watermark reader will either be a “black box” or a “white box.” A black box reader simply accepts content and user input, and returns the watermark payload or information indicating whether the watermark payload was detected. A black box reader typically relies on obfuscation and/or hardware or software tamper resistance mechanisms to shield the details of the watermark detection process from the user's view. In contrast, a “white box” reader is one for which the algorithmic details of the watermarking process have been published to the user, or included in hardware or software that can be readily examined and/or reverse-engineered. As a result, white-box readers typically rely on relatively strong watermarking techniques that cannot be easily compromised by a person with detailed knowledge of the watermarking algorithm.
3. Encoding and DecodingIn a general sense, watermark “encoding” is the process of determining how a watermark's payload bits are represented. The encoding process can, to a large degree, be considered independently of the medium into which a watermark is inserted, although the sizes of the marks may be governed somewhat by the substrate and the embedding techniques that are used.
A watermark payload may be encoded in various ways. For example, to facilitate robust protection and/or recovery of the payload, additional information can be added to the payload and/or the watermark container to provide registration; noise tolerance; resistance to deletion, cropping, correlation, and/or collusive attacks; resistance to forgery; and/or other functionality.
The decoding process is closely related to the encoding process. Decoding takes information and noise that were extracted from the substrate and transforms it back into the original payload. Thus, in a general sense, the decoding step can be thought of as the inverse or complement of the encoding step, as the decoding step reverses the work performed by, and the information inserted during, the encoding step to reconstitute the watermark payload from the encoded marks. If the encoding process involves a secret key (e.g., for anti-forgery or anti-collusion purposes), the decoding process will generally also use that key (or a related key) and possibly a database of encoded payloads to, e.g., recover watermarks that have been corrupted by collusion or cropping.
A variety of encoding and decoding techniques are set forth below, organized generally according to the functionality that they provide. It will be appreciated, however, that the categories given below are provided primarily to organize the discussion. The categories are not rigid, and many of techniques fit within more than one category and/or provide additional functionality.
3.1. Error Correction
In many cases, it will be desirable to detect and recover a watermark even if storage and transmission errors have corrupted the substrate and/or the watermark, and even if an attacker has tried to forge or remove the watermark by changing or deleting portions of it and/or the substrate in which it is embedded. To make a watermark withstand such threats, error correction techniques can be used, including without limitation, such well-known techniques as repetition, Hamming or other linear block codes, cyclic codes, quadratic residue codes, Golay codes, Reed-Mueller codes, Reed-Solomon codes, convolutional codes, trellis codes, and the like. A basic idea of such techniques is that by including redundancy in a communication stream, the corruption or loss of some of the information in the stream can be corrected or detected. The present invention applies this insight to the context of software watermarking by treating the watermarked substrate and/or the sequence of marks itself as the communication stream, and encoding the watermarks using error correction techniques to facilitate their recovery in the face of noise or malicious tampering.
As shown in
As another example, if each mark is relatively unique—as might be the case if each mark were generated using the sparse space encoding techniques described in more detail below—then even if an attacker were able to change or delete several copies of the mark, as long one copy remains (or even portions of one copy), it may be possible to recover the correct mark with a relatively high degree of confidence. Thus, mark repetition is particularly effective in resisting deletion, cropping, and forgery attacks, since if redundant marks are spread throughout the program it will be difficult for an attacker to inhibit watermark detection simply by removing a portion of the program or forging a few marks. As the number of redundant marks is increased, the effort required to find, remove, or forge each copy (or a majority thereof) will generally increase as well.
It will be appreciated that there are a variety of other ways to apply error correction techniques in the context of watermarking, and that for purposes of practicing the present invention any suitable technique or combination of techniques can be chosen. For example, multiple copies of each mark can be included in the program, as described above, and each mark may itself be encoded using error correction codes such as Reed-Solomon codes, Hamming codes, or the like. An advantage of special-purpose error correction/detection codes such as Reed-Solomon codes and Hamming codes is that the redundant information included in these codes is typically not as easily recognizable as repeated, verbatim occurrences of the mark, and thus marks encoded using these special-purpose codes will typically be less susceptible to certain attacks. In addition, special-purpose error correction codes typically require less overhead than simple mark repetition—that is, special-purpose codes may require less additional information to be inserted into the substrate for a given level of error tolerance. However, simple repetition will typically be somewhat easier to implement, and may thus be preferable for many applications.
3.2. Registration
Registration refers generally to the process of providing information to facilitate the location and retrieval of a watermark. Registration information can be provided in a variety of ways. One registration technique is to embed a suitably predefined sequence of bits in the substrate, the sequence indicating the location of the watermark. An illustrative implementation of this technique is shown in
To ensure that the tag does not collide with other values that occur in the program, the unwatermarked program can be checked for the presence of a proposed tag, and if an occurrence is found, another tag can be used instead. In other embodiments, tag sequences that collide with other values in the program are tolerated, and may even be desirable as a means of disguising the tags. In such embodiments, the tags could form part of a multi-part detection process in which a combination of tags and other registration information are used to recover watermarks from the program.
Another registration technique is to insert registration bits into the substrate as part of a watermark's payload. For example, a fixed (and preferably secret) tag can be added to each mark:
Mark=Payload Data+Tag
where “+” may comprise a simple concatenation or a more complex combination technique. As shown in
If the substrate is uniformly random, the inclusion of T bits of tag can reduce the probability of a false hit by 2−T, where a “false hit” refers to the mistaken determination that noise or other substrate data is actually a valid mark. If unique tags are chosen from a predefined set, tag repetition can be avoided, thus making it more difficult for an attacker to detect and/or remove the tags.
Registration information can also be provided by the container itself. For example, if it is known that a watermark is embedded as a predefined set of operands in an identifiable sequence of opcodes, the marks can be found by looking for the sequence of opcodes—the opcode sequence thus providing the registration information for the watermark. This technique is illustrated in
Marks can also be inserted without providing explicit registration information in the program. For example, marks can be stored at predefined locations in the program. The entity responsible for retrieving the watermarks can maintain a list of the locations at which the marks are stored for each instance. Marks are retrieved by consulting the list. The marks in different instances of the program can be stored at different locations, and a key can be maintained for each instance, the key indicating where the marks are stored. In such embodiments the external list (or key) effectively supplies the registration information.
It will be appreciated that a variety of related registration encodings could be used in addition to, or instead of, the techniques described above. For example, error correction techniques can be applied to the registration information to prevent its removal, and the resulting difficulty in extracting marks from the program. Or, a combination of several registration techniques can be used to provide greater resolution in locating a mark and greater resistance to certain attacks.
3.3. Encryption
As shown in
3.4. Salt
As seen in
Specifically, in one embodiment extra information, or “salt,” is used to make different copies of the same mark appear different. The salt may, for example, consist of a randomly chosen 16 or 32 bit value, or any other suitably-sized value. In one embodiment salt is simply added or concatenated to each instance of the mark, and the result is then scrambled. For example:
Mark=Encrypt(Salt+Payload Bits)
Since many encryption algorithms yield a random or effectively random output for each unique input, adding a different salt to each copy of the payload reduces the likelihood that different copies of the payload will encrypt to the same or similar values. Thus, S bits of salt can be used to provide approximately 2S unique copies of the payload. Because different copies of the same mark will now appear different, an attacker will find it more difficult to detect all copies of a given mark even if the attacker is able to deduce the identity of one such copy.
Salt can also be helpful in resisting forgery. If different copies of a mark are encoded using a different salt, as described above, an attacker might be able to set any one copy of the mark arbitrarily, but will generally find it difficult to set many copies of the mark to have different salts but the same payload, since the encryption technique and/or the key is secret. Thus, if an attacker tries to forge several copies of a mark, the salt recovered from each of the copies is likely to be the same. The correct value of the mark can then be determined using the error correction techniques described previously. For example, if a copy of a program contains three differently-salted copies of a mark (e.g., “Alice's Program”), and an attacker were to insert four additional copies of a single mark obtained from another program (e.g., “Bob's Program”), the correct value of the mark (i.e., “Alice's Program”) could be recovered by choosing the payload that appears the most times with different salts. Since, in this example, each copy of the forged mark has the same salt, that mark would be rejected in favor of the authentic mark.
3.5. Authentication
Digital signature techniques can be used to provide registration information and/or resistance to forgery or other attacks. A signature can be included in a watermark, or stored externally by an entity responsible for detecting the watermark. When a potential watermark is retrieved, it is rejected if the stored signature does not match the expected value.
In one embodiment the signature is a secret function of the payload and/or the salt, and can be formed using well-known digital signature techniques. For example, use could be made of the well-known Digital Signature Algorithm (DSA) or any of the other techniques described in Schneier, “Applied Cryptography,” 2d ed., pp. 483-502 (John Wiley & Sons 1996), which is hereby incorporated by reference. It will often be unnecessary to use public-key cryptography to create the signature, however, since the entity checking the signature will typically know the key that was used.
The general form of a signature-containing mark might be:
Mark=Encrypt(Salt-51 Payload|Signature).
The watermark decoder checks for the expected signature after decrypting the mark. Such an encoding provides a way to check each copy of the payload for validity, and also can be used to provide registration information when the container does not do so, as may be the case with a data-section watermark. If the container provides some relatively weak registration information, the signature can be used to filter out false hits. As with tags, T bits of signature can reduce the probability of a false hit by 2−T. To resist malicious tampering, in one embodiment the encryption of the signature depends on all other bits (salt and payload), so that any change to the encrypted watermark is highly likely to corrupt the signature upon decryption. This can be done in a variety of ways, including by using a block-based cryptographic algorithm with blocks big enough to include the entire watermark, by using a chained cryptographic algorithm such as DES-CBC with the signature placed at the end, and/or by using a hash-based scheme.
Another illustrative signature technique is shown below. In this example, the mark stores a plaintext version of the salt and an encrypted concatenation of the salt and the payload, giving the structure:
Mark=Salt+Encrypt(Salt+Payload)
When the mark is retrieved, the encrypted value is decrypted, and the decrypted payload is accepted if the decrypted salt matches the plaintext salt. Thus, the salt is effectively used as a signature to detect whether the mark or the salt have been modified. For security, it will generally be preferable for the payload to affect the encryption of the salt, and vice-versa.
A variety of other signature techniques could also be used. For example, the signature could be a predefined, fixed tag. This technique is effectively the result of combining tag-based registration and salt-based anti-correlation. The tag need not be secret since the encryption key is secret. For example, the tag could be all zeroes. The watermark detector decrypts a potential mark and checks for the tag. If the tag is present, the payload is accepted; otherwise, it is rejected. The technique is simple, yet powerful if the cryptographic algorithm is sufficiently secure. To the extent the tag is a known value, however, this technique may be prone to partially-known plaintext attacks on the cryptographic algorithm. If the tag is kept secret, a known-plaintext attack will generally not be possible, although a partially-fixed plaintext attack might be used. In another, slightly more complex, embodiment, the signature is computed by hashing the salt and the payload. Although any suitable hashing technique could be used, in one embodiment the hash is computed as the piecewise XOR of the salt and the payload. For additional secrecy, the hash could be computed using encrypted versions of the salt and the payload. Many other signature techniques could also, or alternatively, be used.
3.6. Sparse Space Encoding
Another encoding technique is to allocate watermark payloads randomly from a large space, thus making it difficult for an attacker to randomly guess a valid watermark. For example, a watermark payload could be represented as a 1024 bit string. Such a string represents 21024 different combinations. If, for example, only 17 million of those combinations are actually used, then the odds are quite small (approximately one chance in 21000) that an attacker will be able to guess or randomly generate a valid combination. Since the strings are preferably allocated randomly (or quasi-randomly), even an attacker with knowledge of one valid string will find it difficult to deduce the value of another. It will be appreciated that the bounds of the sparse space can be optimized for the particular application, there typically being a tradeoff between string size and resistance to attack, where longer strings will generally be more difficult to embed, but more difficult for an attacker to guess.
By using a sparse-space encoding technique, it can be made arbitrarily improbable that an attacker will generate a valid, forged watermark at random, and thus the presence of a valid watermark can give the content owner a reasonable degree of confidence that the watermarked piece of software is indeed the originally marked instance, or a copy thereof. Thus, sparse-space encoding can be used to protect against the unauthorized distribution of software (or other content), as the presence of a valid mark can be used to reliably identify the source of the unauthorized copies, as an attacker will find it difficult to forge a valid mark in an attempt to frame others or evade detection.
A related benefit of sparse-space encoding is that sparse-space strings are relatively resistant to deletion and/or cropping attacks. As shown in
Marki=Encrypt(subparti+positioni+signature(subparti, positioni))
where “+” can represent a concatenation or other suitable combination function. The position information allows the subparts to be stored in the program in any order, and the signature allows the marks to be inserted without additional registration information.
If a portion of the watermark is deleted or corrupted, the portion of the watermark that is recovered can be compared to a database of allocated strings, and the string with the maximal match can be determined. The watermark detection process is illustrated in
Referring once again to
Having recovered the original watermark 1334, the watermark detection agent can initiate appropriate action (1328). The action that is taken will typically depend on the reasons the watermark detection process was performed. For example, if copies of the program were being distributed without the software creator's permission, the watermark can be used to determine whose copy of the software was being distributed. The software creator or its agents could then contact that person (i.e., Alice) and/or take other action. As another example, if the program had been damaged inadvertently, the watermark could be used to confirm the owner's identity before sending a replacement program.
3.7. Collusion Resistance
If otherwise-identical instances of a program contain different watermarks identifying the particular program instance (“fingerprints”), the watermarked locations can be detected by simply comparing two or more instances of the program and noting the locations of the differences. As previously noted, such a collusive attack presents a potentially serious obstacle to the effective use of instance-specific watermarks.
As described below, the present invention provides systems and methods for encoding and embedding instance-specific watermarks in a collusion-resistant manner.
3.7.1. A Collusion-Resistant Code
Suppose a content provider wants to distribute a piece of software or other electronic content to u users. The provider embeds a distinct watermark in the copy given to each user. If some users collude to create a new copy of the content that contains a corrupted watermark, the encoding scheme described herein allows the content provider to infer the identity of at least one of the colluders. The longer the watermark, the more colluders it can resist.
In a preferred embodiment, the bits constituting the watermark are inserted at secret locations within the software and the content provider preferably uses a private decoder to identify the colluder(s).
3.7.1.1. High-level Structure of the Code
In a preferred embodiment of the collusion-resistant encoding scheme, a watermark is represented as a string of n symbols chosen from an alphabet of size q. As shown in
-
- 1. An outer code 1472, consisting of a string of n symbols chosen from an alphabet of size q.
- 2. An inner code 1474 consisting of a symbol represented as a string of b bits.
The two-layer structure of this code is similar to that of the Boneh-Shaw code for fingerprinting. See, e.g., Boneh and Shaw, “Collusion-Secure Fingerprinting for Digital Data,” pp. 452-65 (CRYPTO 1995)(also appearing in “Lecture Notes in Computer Science,” vol. 963 (Springer 1995)). The construction of the outer code is also similar the Boneh-Shaw code; however, the inner code of the present invention is much simpler. While this simplicity comes at the cost of increasing the length of the outer code, n, when resisting a large number of colluders; the code of the present invention may reduce the overall length of the code when resisting a relatively small number of colluders.
3.7.1.2. The Outer Code
The outer code is preferably random. That is, the watermark assigned to each user is a string of symbols selected randomly and independently from the alphabet. The content provider maintains a private database that associates user identities with the watermarks that are assigned to them.
Decoding of the outer code is preferably performed using a maximum-match technique. A watermark fr retrieved from a copy of the watermarked content may be potentially corrupted by colluders. It is compared with each assigned watermark fa by counting the number of symbols that match between fr and fa (i.e., the “match of fa”). The decoder outputs the identity of the user who was assigned the watermark with the maximum match.
For purposes of this discussion, a decoder is said to be in error if it does not output the identity of a colluder. As shown in Appendix A, the probability of decoder error, e, can be reduced arbitrarily by increasing the length n of the outer code, provided that the inner code meets certain criteria.
3.7.1.3. The Inner Code
A symbol is represented as a string of b bits. For each symbol position in the outer code (1 through n), a fresh set of q representations is generated to encode the q possible symbols in that position. Thus, there are n*q distinct representations in all. Each representation is generated by selecting bits randomly (or quasi-randomly). These representations are preferably known only to the content provider/watermark-encoder.
The inner code is decoded by finding an exact match. In one embodiment, if a symbol position in the retrieved watermark contains a representation that does not match any representation generated for that position in the database of assigned watermarks, the decoder returns an invalid symbol. Thus, in this embodiment error correction is not performed. In fact, since the outer decoder performs match operations on symbols, the inner decoder need not perform any operation at all.
As shown in Appendix A, the exemplary two-layer code shown in
3.7.2. Customization and the Benefit of Multiple Base Versions
The difficulty of obtaining multiple instances of a program in order to mount a collusive attack can be greatly increased by having many different versions of the original binary. For example, a binary customization tool can be used to transform a program into many distinct versions by rearranging basic blocks, applying obfuscation techniques, and/or by performing other customization techniques such as those described herein and/or in the Software Self-Defense application. Each version can, in turn, have its own distinct set of slots into which watermark values can be inserted, and can use different bit-representations for the symbols contained in those slots. If an attacker obtains two different versions of the same original binary, they cannot be easily compared to locate the slots, because the slots themselves (as well much of the rest of the binary) will be in different locations. In effect, the versions can be made too difficult to compare.
Although customization thus provides a powerful form of resistance to collusive attacks, in many situations it will be impractical to uniquely customize each instance of a program—especially in a commercial setting where numerous instances are distributed. Thus, in one embodiment of the present invention, practical protection from collusive attacks is obtained by creating a number of uniquely-customized program versions. In order to mount an effective collusive attack, the attacker will thus need to obtain two or more instances of the same program version, since comparing instances of different versions will, due to customization, yield little useful information to the attacker.
If there is only one version of the program, obtaining two differently-watermarked instances simply entails obtaining two instances of the program. However, if there are multiple program versions, the “birthday paradox” characterizes the probability of obtaining multiple instances of the same version.
The birthday paradox is the somewhat counterintuitive probabilistic observation that it is necessary to gather only 23 randomly-chosen people in order to have a greater than even chance of finding two with the same birthday (ignoring leap years and assuming all birthdays are equally probable). Applying this insight to collusion-resistant program customization, it can be seen that even if there are 365 different program versions, there will be a greater than even chance that an adversary who obtains 23 randomly-selected instances will have two instances of one of the 365 versions, and could thus mount a potentially successful collusive attack. This analysis is generalized below.
For n different versions, the probability of getting at least two instances of the same version after obtaining m instances is given by the formula:
1−n!/(nm(n−m)!)
The probability of getting at least three instances of the same version is given by the formula:
n−mm!*Sum(0 . . . k . . . m) Choose(n, m−k)*Choose(m−k, k)*2−k)
Table 1 shows the number of instances that an adversary would need to obtain in order to find two (or three) instances of the same program version with a desired probability. For example, as shown in Table 1, when there are 10,000 distinct program versions, the number of instances needed to mount a 3-colluder attack begins to become impractical, as an attacker (or group of attackers) would generally need to obtain 184 program instances for even a 1% chance of success. Thus, the program developer might use the information in Table 1, or a straightforward mathematical extension thereof, to choose the appropriate parameters for the two-layer encoding scheme that was described in the previous section. For example, the program provider can determine the level of collusion that is deemed to be probable given the number of customized versions that are produced, then select the parameters of a collusion-resistant encoding using this fact and an assessment of the level of risk that the program provider is willing to bear.
3.7.3. Layered Watermarks
As shown in
Although an attacker might be able to detect the instance-specific watermark using a collusive attack, such an attack would typically be unsuccessful in detecting the version-specific watermark, since it would be the same across all instances of that version of the program and would not stand out upon comparison of two program instances. Accordingly, this technique provides resistance to collusive attacks, and also provides a level of redundancy that is effective in resisting cropping and patching attacks.
It will be appreciated that this technique can be used to create any suitable number of watermark layers. For example, a program might contain three or more layers of watermarks, the watermarks linked together with pointers in the manner shown in
Thus, a variety of watermark encoding techniques have been presented. These techniques can be used in the context of software or any other suitable substrate, and can be used alone or in combination with each other. The next section describes techniques for embedding suitably-encoded marks into a piece of software.
4. Mark Placement and Detection4.1. Placement
There will typically be numerous locations in a piece of software or its environment in which watermarking data can be inserted. For example, marks can be placed outside the code or data sections, in dead code or data, and/or in inert code or data. Marks can alternatively, or in addition, be inserted by making peephole changes to effective code, by making refinements to data-types or operations, by modifying the static control-flow graph, by modifying the program's dynamic behavior, and so forth.
As described below, some placement techniques may require new resources to be inserted into the program, while other techniques use existing resources (e.g., techniques like setting scale bits, writing dead or inert code/data over existing NOPs, re-allocating registers, and the like). The placement techniques set forth below may also provide different capacities to hold data. For example, techniques such as setting scale bits, re-allocating registers, and using single-instruction inert code typically provide relatively fine-grained marks containing only a few bits each. Other techniques, such as those that use longer sequences of inert code, may be capable of containing a watermark's entire payload. In addition, placement techniques may differ in their symbol density (i.e., the average number of marks that can be inserted in a program of a given size). However, it will also be appreciated that many of the placement strategies described below overlap to some extent, or are closely related.
4.1.1. Introduce New Components
A general technique for watermarking a piece of software is to insert new code, data, or other components that may serve as watermarks, or may be subsequently modified to include watermarks. As described below, there are a variety of components that can be inserted for this purpose, and there are a variety of ways to actually insert these components.
4.1.1.1. Unused Components
One type of information that can be added to a program is code and/or data that are not used during the program's execution. This information can serve as a watermark, or can later be modified to include a watermark. A benefit of including a watermark in unused program components is that the addition of the watermark will generally not harm the performance of the program, although it will increase the program's size. A disadvantage of watermarking unused components is that an attacker may be able to identify code that is never executed, or data that are never used, and then simply alter and/or remove this code or data, thus removing any marks contained therein.
4.1.1.1.1. Unused Data
One of the simplest watermark containers is a static array of data stored in the data section of the executable. On most platforms, virtually all of the space created in this way is available for the watermark content. For example, the following macro definition could be used to insert an array of N marks into a program written in the C programming language:
Marks inserted in this manner will typically be able to withstand code optimization or instruction substitutions, will generate little if any runtime overhead, and will be largely platform-independent. Note, however, that if an array of 32-bit words is used, the layout of the bytes constituting each word will typically depend on the byte order of the platform. For example, the Intel® 80×86 architecture stores the least significant byte in the lowest address, while other platforms may have a different byte order. Thus, to locate and/or interpret the marks, the platform's byte-ordering scheme should be taken into account. These complications may be avoided by using an array of bytes rather than an array of words.
A data section watermark, such as the one shown above, may be somewhat susceptible to discovery by certain collusive and/or static analysis attacks since the data section of a program is often much smaller than the code section. Because current tools for customizing programs typically do not support data section rearrangement, it may be relatively difficult to defend against such attacks.
4.1.1.1.2. Unused Code Marks can also be placed in unused (or “dead”) code. In one embodiment, basic blocks are inserted containing code that is never executed, and marks are inserted into these blocks. The unused basic blocks can be inserted between other basic blocks in the program using a binary modification engine to correct references to the moved code, as described in the Software Self-Defense application, which was previously incorporated by reference. Opaque predicates can be used to disguise the fact that certain code is never executed. For example, a jump in the original program can be converted to an apparently conditional jump that always evaluates to a predefined value (e.g., “true”) at runtime, although an attacker may be unable to deduce this easily using static analysis.
Various techniques can be used to embed marks in unused code. For example, marks can be stored as immediate operands of instructions. In one embodiment the inserted code is made to look like real code by using, e.g., techniques described in the Software Self-Defense application and elsewhere herein.
Although an attacker may perform static or dynamic analysis to find unused code, or may reorganize basic blocks or insert null-effect instructions to displace code, these attacks generally require a binary editor and will thus be relatively costly and/or time-consuming to perform successfully.
4.1.1.1.3. Manipulating Tables, Debug Info, Relocations and/or Padding
Marks can also be placed in areas other than the code or data sections of a program. For example, marks can be placed in program headers, symbol tables, debugging information, jump or relocation tables, import/export tables, virtual function tables, or other locations. There are many such areas in the Microsoft PE binary format, and marks can be advantageously embedded therein using, e.g., a binary code manipulation tool.
For example, one technique is to add watermarking information between structures in the import table. Such structures are defined in the “Portable Executable and Common Object File Format Specification 4.1” (Microsoft, August 1994), and include the Import Directory Table, the Import Lookup Table, the Import Address Table, and the Hint/Name Table.
Another illustrative technique is to take advantage of ordinal-based addressing in import tables. Import tables typically have two addressing modes. In one mode, the import table references a function by storing a pointer to the function's name, while in another mode, the import table references a function by simply storing the ordinal value of the function's position in the table. Since ordinal addressing consumes less bits per table-entry than pointer-based addressing, watermarking information can be stored in the unused bits of table entries that use ordinal addressing. For example, ordinal values typically consists of 16 bits, plus a 1-bit flag indicating that ordinal-based addressing is being used, while a pointer typically consists of a 31-bit value, plus a 1-bit flag. Thus, ordinal entries include 15 unused bits into which watermarking information can be inserted.
It will be appreciated that there are many similar techniques for including watermarking information in tables, headers, and the like.
4.1.1.1.4. Add New PE Sections
Another watermarking technique is to simply add new sections to the portable executable file. The new sections can be used to store watermarking information. An advantage of this technique is that it can provide a large area for the insertion of watermarks. However, if an attacker discovers that the new PE section is unused, he might simply remove it. Accordingly, this technique is preferably used in connection with self-checking and other tamper-resistance techniques—such as those described in the Software Self-Defense application—in order to discourage such an attack.
4.1.1.2. Used Components
Code or data that is used at runtime, but that is ineffective in changing program behavior, can also be added to the program and watermarked. Such inert code/data sequences are effectively NOPs, and can take a wide variety of forms—a PUSH followed by a POP, for example. Marks can be stored in inert code as, e.g., immediate operands, opcodes, memory addresses, and the like. Additional null-effect instruction sequences are described in the Software Self-Defense application, which was previously incorporated by reference, and in commonly-assigned U.S. patent application Ser. No. 09/095,346, entitled “Obfuscation Techniques for Enhancing Software Security,” filed Jun. 9, 1998 (“the '346 application”) and in Cohen, “Operating System Protection Through Program Evolution,” Computers & Security, vol. 12, no. 6, pp. 565-584 (1993) (“the Cohen paper”), both of which are hereby incorporated by reference in their entirety.
Although any suitable null-effect sequences can be used, care should be taken to avoid unacceptably degrading the program's runtime performance. For example, the programmer or binary editor should be aware of inner loops or performance-critical basic blocks, and should avoid inserting time-consuming inert code sequences in those locations.
It will generally be relatively difficult for an attacker to detect and/or remove marks embedded in inert code or data, as such marks will survive a static or dynamic search for unused components. Although inert code/data marks may be susceptible to attacks that check for the presence of ineffective code, obfuscation techniques can be used to hide the fact that certain code/data is inert.
4.1.1.2.1. Inert Code
As mentioned above, a code-section watermark can be embedded in the immediate operands of inert instructions. The watermark is thus spread over non-adjacent slots with intervening opcodes.
Referring to
Memory address 1504 can be stack-relative or absolute. A stack-relative address will typically result from a macro such as the following:
This type of macro usually translates into {mov[sp+x], operand} or {mov[bp−x], operand}. Care should be taken to prevent the compiler from eliminating the macro code during optimization, and it may be desirable to avoid storing information in the address unless x is controllable or predictable. In any event, since x is likely to be a small integer, just like in many other naturally-occurring instructions, it will generally not help much with registration.
In contrast, an absolute addresses will typically result from a macro such as the following:
Note that {static int dummy=operand; } would not result in any code, since if the operand is an integer, it will simply be stored in the data section. If the macro's variables are defined as static variables, as shown above, then different instances of the macro will result in a unique locations in the data section corresponding to the macro's variable (e.g., the “dummy” variable shown above). In fact, as shown in
Referring to
As with other inert code watermarks, marks inserted in the manner shown in
It has been found that C-language macros such as those described in connection with
Referring back to
4.1.1.2.2. Watermark Generation Language
An exemplary method for making watermark containers, such as those described above, and/or watermark registration patterns substantially unique without having to store a key is described below. A formal language is used to describe a possible set of parameterized null-effect sequences, based on some atomic primitives. For example, the sequence PUSH imm32/Readjust-SP is an example of an atomic parameterized NOP (imm32 being the parameter). In the simplest case the language is like parentheses balancing, i.e., the primitives consist of components that are paired into elements that do something and undo it like the PUSH/Readjust-SP example. In addition, we can use the fact that the contents of the registers, memory, and/or stack can be interchanged as long as the state of the system (e.g., computer) is unchanged in the end. Using such a language, a generator and a parser can be written. The generator is operable to generate random instances that are unique for each slot. Examples of null-effect sequences that might form part of such a library include:
-
- PUSH reg; POP reg;
- PUSH EAX; MOV EAX, value; POP EAX;
- PUSH imm32; Readjust-SP;
- LEA reg,[reg−x]; LEA reg,[reg+x];
- XCHG reg1,reg2; XCHG reg2,reg1;
- AND reg, −1;
- OR reg, 0;
- NOP
Additional examples can be found in the Software Self-Defense application and the '346 application.FIG. 17A shows an example of the use of various null-effect primitives to create a unique null-effect pattern in watermarked program 1722.
4.1.1.2.3. Statistical Model of Watermark Language
To avoid detection, it is important for components that are added to a program to blend in with the rest of the program. Otherwise, an attacker might find the watermarks by creating statistical models of the executable code and looking for unusual code fragments. The present invention provides systems and methods for creating watermarks that blend in with the program into which they are inserted.
One technique for creating stealthy watermarks and/or watermark holders is to examine common compiler or programming idioms, and to model the watermark code after such idioms.
It will be appreciated that a number of variations could be made to the illustrative system shown in
Alternatively, or in addition, more sophisticated statistical modeling techniques can be used to characterize common sequences of code, thus enabling the generation of even more stealthy code sequences. For example, in one embodiment Markov models are used to analyze the common code sequences and idioms that appear in “normal” compiled programs. The insights gained from this modeling process are then used to select the types of code sequences and customizations that are used for purposes of watermarking, the goal being to generate and use code sequences that blend naturally into the rest of the program, and are thus resistant to statistical analysis.
A simple statistical modeling technique is shown in
As shown in
The effectiveness of the modeling technique can be enhanced by using something more detailed than an opcode for each node—for example, something like “AND with a 32-bit immediate operand, and 8-bit displacement address.” Thus, in one preferred embodiment, the nodes of the Markov model consist of “instruction, operand type, register use”, with each of these nodes having associated distributions of immediate operands, displacement addresses, etc. Alternatively, or in addition, these distributions can be associated with larger groups of nodes to get statistically better results. Thus, for example, the probability distribution of the jump location for conditional jumps might be X; the probability distribution of the immediate operands for logical operations might be Y, and so forth. The transition probabilities can then be determined empirically for a large piece of code. This can inherently model compiler idioms and provide a way to quantitatively say how likely it is that a sample piece of code was generated by a compiler. Of course, like any Markov model of a non-Markovian process, a great deal of potentially relevant (and/or important) information is thrown out.
Thus, it will be appreciated that statistical modeling can be done at different levels of complexity, depending on available resources, the level of statistical analysis that is expected from an attacker, and other factors. Moreover, it should be appreciated that there are a variety of sequence modeling techniques, and that any suitable one could be used without departing from the principles of the present invention, including Markov models such as those described above and variations thereof.
4.1.2. Replace or modify existing components
Watermarks can also be inserted into components that already exist in the program, thus obviating the need to insert and disguise new watermark containers.
4.1.2.1. Replacing Dead Code
Many common compilers align code on 16-byte boundaries. When functions do not align, the compiler typically pads up to the nearest boundary with RET or INT3 instructions that are never executed. For example, the Microsoft Visual C++ compiler often generates a lot of these padded regions, especially for functions and methods that consist of little more than a call to another function or method. These padded areas and unreachable blocks make good places to place watermarking bits using a binary code modification tool. The watermarks placed in these locations can take a variety of forms. For example, one technique is to insert arbitrary code. Another is to store a jump table. Since the compiler often stores jump tables after a RET instruction, this would be relatively stealthy and attack-resistant, since if an attacker removes all code or jump tables inserted after RET instructions until the next 16-byte boundary, the attacker will often remove some valid code or jump tables as well.
4.1.2.2. Alternate Instruction Encodings
Marks can also be embedded by making peephole changes to code that is executed at runtime. For example, scale bits can be manipulated, instructions or instruction sequences can be replaced with their equivalents, registers can be re-allocated, and so forth. Use of such techniques will often be advantageous in that they generally do not involve the addition of new resources or expansion of the program.
4.1.2.2.1. Manipulating the Instruction Format
One effective watermarking technique is to make use of redundant or complementary components that are peculiar to the instruction format of the platform on which the watermarked software is run. These redundant instruction components can be used to generate instructions that have the same effect on the program's operation, but which appear slightly different in the program's binary image. The Intel 80×86 instruction set presents many such opportunities for watermark insertion, due to the variety of idiosyncratic formatting options that have resulted from the processor's complex evolution, and the variety of design decisions and backwards compatibility requirements that this evolution entailed. For purposes of illustration, several examples of the watermarking possibilities offered by the Intel 80×86 instruction format are described below; however, it will be appreciated that there a wide variety of similar or equivalent ways to insert watermarks by exploiting the peculiarities of the Intel instruction format and/or the instruction formats of other platforms, any of which could be used without departing from the principles of the present invention.
To facilitate the discussion that follows,
4.1.2.2.1.1. Instruction Prefix Bits
As shown in
One such prefix is the bit pattern 001xx110, where xx are two bits that can be varied to select between segment override prefixes CS, DS, ES, and SS. If this prefix is added to an instruction for which the prefix is irrelevant—such as a NOP—the xx bits can be set to any desired value without affecting the program's operation. Thus, watermarks can be added to the program by, e.g., adding instructions for which the prefix bits do not matter and embedding a watermark in the prefix bits, and/or by looking for existing occurrences of this type of instruction and adding or changing the prefix bits as desired. The marks can be found by maintaining a list of the locations at which the prefix manipulations were performed, or by using other suitable registration techniques.
4.1.2.2.1.2. Direction Bits
Direction bits provide another opportunity to take advantage of the instruction formatting idiosyncrasies of the Intel 80×86 architecture. The opcodes of many two-operand instructions on the Intel 80×86 platform include a bit—the direction bit—that indicates which operand is the source and which is the destination. This may be useful, for example, if one of the operands is a register and the other operand is a memory location. However, if both operands are registers, for example, the direction bit is essentially redundant, since the direction bit can be set to an arbitrary value and the order of the registers in the machine language representation of the instruction can be flipped to preserve the original meaning of the code.
4.1.2.2.1.3. Scale Bits
Another watermarking technique takes advantage of useless bits in the SIB (scale-index-base) addressing mode found in Intel 80486 and later processors. In SIB addressing mode, if Index is the bit pattern 100, the SS bits are ignored. Thus, the SS bits can be used to store watermark information. The watermark information can be detected using an external database of locations and/or content. Simple disassembly will be able to locate the SS bits, which may obviate the registration issue. The stored database of content can then be used to link them up in the correct order.
This approach is advantageous in that no instructions need to be added to the program, as there will typically be plenty of such instructions already in the code. Moreover, since additional instructions are not being added, and the added bits are ignored, performance is generally not degraded. In addition, the watermark is quite stealthy since it does not disassemble into anything suspicious looking, and can thus be easily overlooked by an attacker. The primary disadvantage is that if an attacker discovers the hiding mechanism, it is relatively simple to remove the entire watermark. That is, this technique is prone to generalization.
4.1.2.2.2. Equivalent Forms of Instructions
Many instructions and instruction sequences can be expressed in any of several effectively equivalent forms. Thus, watermarking information can be stored in the form that is chosen. For example, if there are two ways to represent an instruction, the choice can be used to contain a bit of watermark information. For example, a “mov eax, imm8” instruction can be replaced with a “mov eax, imm32” instruction, as the second instruction will be able to handle whatever value was specified by “imm8.” One of ordinary skill in the art will appreciate that there are numerous other examples of such equivalent instructions and instruction sequences, some of which are set forth in the Software Self-Defense application, which was previously incorporated by reference herein. It will also be appreciated that this technique is related to the permutation techniques described below in connection with
4.1.2.3. Watermarked Booleans
Watermarking may advantageously be combined with any of several program and data obfuscation techniques, as described in the '346 application and in the Software Self-Defense application, in order to achieve stronger obfuscation and to make it more difficult to remove or modify the watermark without impairing the execution of the program. The kernel of the idea is to include parts of the watermark in computations of the program in such a way that changes to the watermark by an attacker will almost certainly disrupt the computation, but without unduly constraining or complicating the watermarking process. Any redundant representation of watermarks may be used, and the program variables may be of any type. However, a preferred embodiment uses boolean program variables to simplify the implementation.
For ease of explanation, a simplified scheme will first be described. The basic idea is to tie variables in the program to a watermark in such a way that random changes in the watermark are highly likely to cause the program to malfunction by misinterpreting the variables.
In an over-simplified scheme, the watermark can be stored as a constant in a known place. If a code rearrangement tool moves it, it can be found relatively easily, as described in more detail below. In the program, a number of boolean variables bi are chosen corresponding to the number of bits in the watermark, and each bi is associated with a bit in the watermark w[i], so that the “correct” value of the variable is the exclusive-or of its stored value and the watermark bit, i.e., bi+w[i] (where “+” is equivalent to XOR for one bit variables). Where the original program uses bi in an expression, it is replaced with bi+w[i], and where the original program has an assignment bi=e, it is replaced with bi=e+w[i]. Thus the program will still calculate its original result, whatever that was, but some of the boolean variables will be complemented as determined by the watermark. The result is a “hinted program” that can be watermarked with any desired watermark by setting W.
Note that this transformation of the program is obfuscating: it increases the apparent number of program variables to include the watermark W, and adds complexity to each computation that sets or uses the bi. However, the weakness of this over-simplified scheme is that the program will produce equivalent results regardless of what value the watermark has. Thus, an attacker could zero out the watermark constant, or replace it with any value, without affecting the operation of the program.
To protect against modification of the watermark, some form of redundancy can be used. For example, in a repetition code, for an N-bit watermark, 2*N bits can be stored. A simple code would just store the two repetitions in adjacent positions (or just store two copies of the watermark), but then it would be easy for an attacker to discover this relationship, and modify both consistently.
One way to make the relationship more obscure, while still making it easy to apply watermarks, is to pick two (obfuscation-time) functions f and g over 1 . . . N with disjoint ranges whose union is 1 . . . 2N, plus an N-bit obfuscation-time mask M. To apply the watermark, set W[f(i)] to w[i] and W[g(i)] to M(i)+w[i] if Where the original program uses bi in an expression, replace it with bi+W[f(i)]. Where the original program has an assignment bi=e, replace it with bi=e+W[g(i)]+M(i). As long as W is set as specified, the program will still calculate its original result, although some of the boolean variables will be complemented, as determined by the watermark of an individual instance. However, if an attacker changes a single bit in W, it will cause a boolean variable to be inconsistently set and read. If the variable affected the original computation, the computation will go wrong. (Even numbers of bits can be changed safely only if they maintain the invariant W[f(i)]=W[g(i)]+M(i).) The difference between the watermarker and the attacker is that the former knows f, g, and M, which appear nowhere in the program, and would be difficult to deduce, even if all other aspects of the scheme were understood.
It should be appreciated that the “variables” need not be data variables, but could also (or instead) encompass other characteristics of the program. For example, the logic at the end of basic blocks can be used to encode information (e.g., the sequence je A; jmp B; is equivalent to jne B; jmp A;, and thus information can be encoded in the choice of which of these sequences to use in a particular block).
An attacker who knows that precisely this watermarking algorithm has been used could defeat it by statically examining the code, and for each bi, observing the two indexes in W that are consistently associated with it. More realistically, the attacker can make a table of references to boolean variables that are near references to positions in W, and figure out the pairing from there. Although such an attack, if successful, would allow bit-by-bit modification of the watermark, it would typically have a significant cost in examining code. To make this attack more difficult, positions in W can be associated with other boolean variables in dead code or in don't-care tests.
Although this is not particularly robust against an attack that complements all of W, such an attack would typically allow the attacker to insert only one other watermark, and it can be detected by inserting an additional redundant bit in W.
A number of variations can be made to this technique. For example:
Associate more than one variable with each bit of the watermark.
- When modifying the original program, quasi-randomly choose between W[f(i)] and W[g(i)]+M(i) both for loading and for storing, thus making the pattern harder to recognize.
- Use more than 2N bits for W, and a stronger code than a repetition code, as discussed elsewhere in this disclosure.
- Vary the pattern of code substitutions. E.g., instead of bi=e+W[g(i)]+M(i), sometimes use:
and/or:
If the optimizer rearranges this code, so much the more obscure.
Redundancy in W can be used in conjunction with redundancy in the program variables, using techniques similar to those described in the '346 application. For example, a boolean value b can be represented by a collection of boolean variables, e.g., c1 . . . ck, and bits in the watermark can be used to specify the interpretation table (truth function) that tells which value each combination of the values of c1 . . . ck represents. If approximately half the combinations represent true, and half false, that still leaves 2k choose 2k−1 combinations available, enough to absorb more than 2k−1 bits of watermark. Virtually any 22
c1 . . . ck can be converted to a truth value whenever b is used in a computation and boolean values can be expanded again when they are stored to b. Alternatively, boolean computations can be carried out using multi-bit values; bits from the watermark can be used to select the representation to be used for each intermediate result, just as other bits are used to select the representations of the explicit program variables. In a preferred embodiment, each intermediate result is associated with a distinct part of the watermark's redundant representation.
Since there will be multiple ways to represent each truth value, there will be multiple possible “truth tables” for the boolean operations. These tables can be fixed at obfuscation time, or selected dynamically, using still more bits of the watermark's representation.
As an example, consider the case k=2. There are 6 ways (i.e., 4 choose 2) of allocating half the representations to true:
{00, 01}, {00, 10}, {00, 11}, {01, 10}, {01, 11}, {10, 11}
Arbitrarily pick and number four (22
0: {01, 11}, 1: {00, 01}, 2: {01, 10}, 3: {00, 11}
There are 24 valid four-entry two-bit tables for each of the sixteen combinations of input and output representations. For each negation in the program, we can choose one of its tables at obfuscation-time, and get the result by indexing this particular table by the two bits of the argument. There is no reason to store the (up to) sixteen tables contiguously; we could scatter them according to an allocation scheme that is only known at obfuscation time.
Alternatively, we could calculate the first bit and the second bit of the result in two separate computations. This would require twice as many four-entry one-bit tables. We could completely compute one before starting on the other, making the linkage between the two bits of the result harder to detect (particularly after an optimizer has gone over the code). Part of the (obfuscation-time) invariant would be that corresponding tables would be used for the two halves of each operation.
Correspondingly, for binary boolean operations, there are 216 possible valid sixteen-entry two-bit tables for each of the 64 (4 ×4×4) combinations of input and output representations. There is no need to store all of them. We can choose any “sufficiently large” subset at obfuscation time—that is, enough tables so that the number of times any one of them is used is small enough to make the attacker's task difficult. We need not store any that the program doesn't use.
Note that since we are dealing with boolean values, we don't have to use arithmetic to subscript into the tables. We can scatter the individual elements according to a scheme known at obfuscation time, and use conditionals to select the address.
There is a potential attack on the schemes as described. The weakness comes at each point in the program where an actual boolean bi is needed (e.g., to control a conditional or loop). The attacker can inspect the code that converts ci1, . . . , cik to bi. The code will unambiguously identify the equivalence sets representing true and false, and will reveal both the bits in W that are used to control the conversion and the locations of the associated bits ci1, . . . , cik. All of this information combined might provide leverage towards breaking the scheme.
A counter-attack is to chain the use of the bits in W, so that each W[i] contributes to determining the representation of more than one variable, and thus requiring a consistent set of changes to be made to the whole chain rather than to just the bits determining the coding of a single boolean. Although this generally does not complicate an attacker's analysis, it does impede an attacker's attempt to use the analysis of one variable to change the watermark in the associated bits.
Another counter-attack is to use a separately-determined representation for each such boolean. I.e., if the value is in a variable, first assign it to a distinct multi-bit temporary.
Note that converting from a regular boolean to a multi-bit version is not very revealing. Since we can, at obfuscation time, choose to use any one of 2k valid conversion tables, the code will reveal only one element in each equivalence set, rather than all of them. Again, if we are assigning one variable to another, we can pass it through a unique multi-bit temporary on the way.
Although these techniques could be readily applied by hand, in a preferred embodiment a class called WatermarkedBool is built that overrides all the boolean operations with their watermarked versions. This can be inlined to yield more efficient—and more obscure—object code.
4.1.3. Permutations
Marks can also be inserted by modifying program control structures. For example, code blocks can be duplicated, object files can be rearranged during linking, or other similar techniques can be used. Instances of the program will look different, and these difference can be used for purposes of identification. There are a wide variety of software components, structures, and operations that lend themselves to permutation, including without limitation, program basic blocks, the program linking order, sparse jump table indices, components in other tables, the order of null-effect instruction sequences, and the like. More examples are described in the Software Self-Defense Application and the '346 application, which were previously incorporated by reference.
A general technique for embedding watermark information using permutations will first be described, followed by several examples of how this technique can be applied to various program components. As shown in
It will be appreciated that the technique shown in
4.1.3.1. Basic Block Permutation
Since a major attack is based on reorganizing basic blocks, a solution is to factor out the linear layout of the basic blocks and look at the higher-level control-flow graph. The static flow graph consists of basic blocks (as vertices) connected by jumps and/or statically-known calls. A binary editor can compute such a graph. The graph can be used in at least two ways: as a watermark itself and/or as a registration mark. Both of these are independent of the linear layout of the basic blocks, and are therefore robust against basic-block reorganization by attackers.
Techniques for adjusting the static flow graph include: that are either not executed at runtime or have no effect. This is preferably done in a way that does not significantly degrade performance. See the Software Self-Defense application.
-
- Replicating some basic blocks in the image and, for jumps to such a block, choose the copy to jump to based on bit(s) in the watermark.
Of course, an attacker can use the same techniques to change the static flow graph—e.g., splitting, introducing, or replicating basic blocks—although this will generally require a relatively sophisticated binary editor. Another problem with this approach is that changes to the flow graph are relatively error-prone, and might result in poor debugging capabilities.
In one embodiment the static flow graph serves as a registration mark (the carrier signal) and the watermark is applied on top of that. Thus, reorganizing the basic blocks will not change the watermark per se. Equivalently, the basic-block layout can be normalized before reading the watermark. The problem is then reduced to recording some watermarking bit(s) in each basic block. This could be done using one of the schemes listed above. An attacker might still attempt to split, introduce, or replicate basic blocks; however, in this case it might still be possible to map the resulting static flow graph to the original graph (using, e.g., error-correcting techniques), since the resulting graph will generally be a refinement of the original graph.
4.1.3.2. Register reallocation
As mentioned above, register allocations are an example of a program component that can be permuted. Suppose a register R is live for a certain range of instructions and another register S is free in that range. In general, R may be replaced by Sin that range. A register can typically be considered free at a point Vin the program if the register is written at some point, W after V; the register is not read between V and W; and the control does not flow out between V and W. These conditions are sufficient but not necessary, though they may provide a good first-order approximation of a more flexible rule. See, e.g., Waite and Goos, Compiler Construction (Springer-Verlag, 1984).
In a preferred embodiment, modifications are used that are provably correct, do not require a lot of analysis to make, and that cannot be easily reversed. The last feature is important in protecting this scheme against attackers who know about the general technique. Simple instructions can often be inserted that make the reversal hard. For example, the instruction “mov unused_address, EAX” can be inserted to give the impression that EAX is in use at that point. Additional modification techniques are described in the Software Self Defense application.
4.1.3.3. Watermarking Compiler
Ordinary compilers make many decisions in the course of transforming a source program to machine code. Many of these decisions are made to produce better code (e.g., faster code, or code that uses less memory or fewer registers, etc.). For example, a compiler might select certain instruction sequences that execute more quickly or might allocate registers to minimize spill code. Other decisions that a compiler might make are somewhat arbitrary, such as picking an order in which to place code fragments (object modules) in an executable image. Thus, a compiler's decisions describe a lattice of possible programs, some of which are strictly better than others (e.g., faster and use less memory, etc.), and others that are not readily comparable (e.g., faster but use more memory).
A watermarking compiler can make some of its decisions in order to represent bits of the watermark, rather than purely for performance reasons. Thus the watermark is encoded in fundamental properties of the resulting object code, including but not limited to: instruction selection, spill code placement, register allocation, basic block ordering, procedure linkages (present or absent due to inlining or outlining), data representations, control structure, etc. Compiling the same program with a different watermark will result in different (possibly radically different) byte-code or machine-code. Watermarking during compilation has the advantage (over binary or byte-code watermarking) that the entire program structure is available in a convenient form for manipulation to structure a watermark into the resulting code.
4.2. Detection
Extracting a watermark from a piece of software is essentially the inverse of the process of embedding the watermark. The extraction process typically involves detecting the presence of the watermark, determining how the marks are embedded, retrieving the marks (and possibly noise), and relaying that information to the watermark decoder.
In one embodiment, authorized retrieval of a watermark makes use of secret information not known to attackers. These secrets can be used for both extraction and decoding. Extraction techniques can be categorized generally based on the type of secret information that is used, and where it is used. Two broad categories of extraction techniques are (i) embedding-based identification and (ii) encoding-based identification.
Embedding-based identification uses secret information from the embedding step to locate marks with reasonable accuracy. This information may take a variety of forms, including:
-
- Secret Information Independent of the Watermarked Program: Here, the secret is typically a secret key or other mechanism that makes it computationally infeasible for an attacker to recover the watermark. The secret information could also be a parameter used in generating the marks; e.g., the sequence of opcodes when the payload is stored in immediate operands, the locations of memory addresses in instructions that are used to store the marks, and so forth. Relying on this type of secret is usually prone to generalization attacks and/or information leaks. The resistance to generalization attacks for such techniques depends on the degree of parameterization. The higher this degree, the less identifiable the marks for attackers.
- Secret Information Specific to the Watermarked Program: The location of marks, the context surrounding the marks, and the like can be used to find otherwise unidentifiable marks that are resistant to generalization attacks. A disadvantage is that this approach generally entails storing secrets specific to each program in a secure database, the extraction process comparing the program with the secret stored for that program.
In encoding-based identification, the extraction process typically returns marks along with often significant amounts of noise using, e.g., publicly-known (or not-so-secret) placement information. It is then up to the decoding step to filter the information provided by the extraction step to retrieve the payload.
The first step in retrieving watermarks is to locate them. To that end, some container types provide registration. For example, the code-section watermark described in connection with
In addition, some content types provide registration. For example, signature-carrying content also provides registration. A pointer can be slid over the watermarked file byte-by-byte. For each position of the pointer, the data can be interpreted as the watermark; however, the payload is accepted only if the signature is consistent with the salt. This technique was illustrated in connection with
A general strategy to locate watermarks is to iterate over all container types. If a container type provides registration, the registration provided by the content, if any, can be ignored or used to filter out false hits. If the container does not provide registration, it should hold only those content types that do. In this case, the detector iterates over the potential content types for the given container type, and for each content type, uses the content-specific registration mechanism to detect the marks.
If the registration involves searching for a fixed pattern, we call it fixed registration, otherwise we call it variable registration. At retrieval, fixed registration involves pattern matching while variable registration involves applying a generic boolean function to a block of data. In the examples above, the code-section container provides fixed registration and the signature-carrying content provides variable registration. However, some content types may provide fixed registration as well. Fixed registration is simpler to implement and search for, but is more prone to correlation and generalization attacks.
A false watermark might occur because of accidental registration or malicious corruption. Accidental registration occurs when the registration is present naturally in the unprimed program. Malicious corruption occurs when an attacker discovers a watermark and is able to forge a valid watermark with different content.
The vulnerability of a registration technique to accidental registration may be measured as the probability p that a random block of data will pass it. For signature-carrying content with an s-bit signature, p is 1/2S (the probability that a decrypted s-bit value will match another s-bit value). If a file contains n bytes of random data, the expected number of accidental matches in the file is np. For a one megabyte file and a 32-bit signature, this number is 1/212. Even so, both fixed and variable registration can be tested against a stamped executable to detect accidental matches in advance. In both cases, the registration can be tuned to avoid them; e.g., the key used to encrypt the signature can be changed.
The presence of many watermarks in a file can be used to filter out false watermarks. The retrieval procedure can report the payload, the container type, the content type, and the count of copies found. If different payloads are found, the payloads with relatively small counts are likely to be false and can be rejected. Another criterion is the number of different container types bearing the same payload. When attackers discover one container type, they are more likely to discover all instances of that container type; so payloads appearing in only a small number of container types are more likely to be maliciously corrupted.
Yet another approach to locating watermarks is to keep a list of the locations at which the watermarks are stored. The detector locates the marks by consulting the list. This is a kind of “original-based” watermarking, in that information about the original program, or at least the watermarked parts of it, is used for reading the watermark. An advantage of this technique is that it does not require the addition of explicit registration information to the program.
Copies of each version are then distributed to consumers or other users. Each copy is individually watermarked with a unique value, or with unique information regarding the details of the transaction. List 2206 for each version of the program is also preferably associated with another list that contains the values of the watermarks that were actually inserted at the specified locations in each instance 2210 of that version 2204 of program 2202.
In one embodiment, a set of uniquely watermarked instances 2210 are created before the program is distributed. When a user purchases a copy of the program, the user is provided with a randomly selected instance from a randomly-selected version of the program. The identity of the instance (e.g., the value of its watermark) is maintained in a list, together with information regarding the consumer's identity and/or other details about the transaction. In other embodiments, the program instance is uniquely marked at the time of distribution. For example, upon receiving a request for a copy of the program, an instance-specific watermark can be inserted into a copy of a randomly-selected version of the program, the instance-specific watermark containing encoded information about the purchaser and/or the details of the transaction.
When a watermark needs to be recovered—for example, when it is discovered that a copy of the program is being distributed without the creator's permission—the suspect program is matched, in turn, against each of the lists in the database to determine where the stamped primers are located. Once a matching list is found, the watermark is extracted from the stamped primers, and the purchaser of that copy of the program is identified.
A method for comparing the suspect binary to the lists in one illustrative embodiment of the present invention is shown in
The search technique described above will work best on programs that are largely undamaged. If a damaged program or program fragment is encountered, it may be desirable to search the list database in a slightly different manner. For example, if only a fragment of the program is recovered, the database can be searched for the list that includes the largest fraction of matching prefix and suffix strings. This can be done by searching the program fragment for each entry of each list (which could be relatively time-consuming if there are many lists) and choosing the list for which the most matches are found.
Another approach is to build an additional data structure for each list, the data structure containing the fifty least-frequent prefix and suffix strings in the list (or simply fifty randomly-chosen prefix/suffix strings). Only a few primer lists would have non-negligible scores. Each 8-byte primer prefix/suffix pattern should be more or less random, and thus has almost no chance of appearing in the binary. If they were truly random, the odds would be about one in 243 (1013). Although it will be understood that they will typically not actually be random, as they represent instructions, addresses, and constants that are not particularly random, still, experiments suggest that the vast majority of 8-byte patterns in any particular executable appear only once, and that those patterns do not appear in other executables.
Thus, for example, if all the primer lists that have three or more matches are selected (five matches would be expected to occur in 10% of the suspect binary), it is unlikely that there will be very many—most likely under 1000. The same matching can then be performed against the full set of prefix/suffix patterns in those, e.g., 1000 primer lists. Having found the primer locations, we can then extract the watermark from the stamped primers and decode it—which may still be possible if the mark is encoded using redundancy and other error correction techniques. Or, if the mark itself were stored in the list. Identification of the version, and the extent to which the recovered watermarked fragments matched the stored mark, would allow a confidence interval to be constructed indicating the level of certainty that the recovered instance actually corresponds to the list stored in the database. If the database were maintained by a neutral, trusted third party (i.e., by an entity other than the program's owner), evidence of the similarity between the recovered program and the original instance could be used in identifying and prosecuting the person or entity responsible for distributing or modifying the program without the owner's permission.
For this two-pass statistical analysis, it is not necessary to use the relative location information about the primers, although in one embodiment it can be used as a confirmatory factor.
This model assumes that attacks do not involve further use of sophisticated binary modification tools. For example, rearranging the basic blocks a second time would almost certainly eliminate many of the patterns in the binary. However, such attacks are unlikely if obfuscations such as those described elsewhere in this document have been applied, as they will likely cause such tools to operate poorly, if at all, and when modifying binaries even a small error produces unusable output. Even if an attacker successfully rewrites the binary, unless he does so in a way that explicitly eliminates all of the watermarks, more advanced techniques (e.g., correlation) can be used to recover watermark data given a statistical understanding of the watermark alphabet.
Thus, an original-based watermarking scheme such as that described above may give the owner an added advantage over the attacker, since the owner knows where the marks are supposed to be and the attacker does not. The locations of the marks need not be embedded in the code, but can be stored separately. A disadvantage of such a scheme is its lack of generality; reading of marks is generally not possible on arbitrary code, only on code for which the appropriate data are available. This is not necessarily a disadvantage when there are only a few versions of the program, but with large-scale customization, the database overhead may become significant. Another potential disadvantage of this scheme is that managing all of the lists—especially for a program that is widely distributed—can be relatively cumbersome. However, as shown below, these costs will typically be manageable.
The following example provides some indication of the upper bound on the storage requirements and cost of an original-based watermarking scheme such as the one discussed above. Assume that for each program 2202 (i.e., release), ten thousand distinct versions 2204 are created through binary modification. As shown elsewhere herein, ten thousand versions is probably more than enough to deter plausible collusive attacks. The time taken to generate this many versions can be reduced by performing the customizations automatically and/or in parallel using a batch mode. Also assume that over a period of five years, there are one hundred different releases, each of which has ten thousand different versions. Thus, after five years, there will potentially be instances of one million distinct versions in the field.
Assume that each version reserves space for a ten kilobyte watermark—as might be the case if a particularly collusion-resistant and damage-tolerant mark were desired. If the watermark is divided into ten thousand, one-byte components, each of which is embedded in a separate location, then the list for each version of the program may include ten thousand entries, one for each component of the watermark. The list might also contain a copy of the eight bytes before the marked location, a copy of the eight bytes after the location, and a relative two byte offset to the next location. Thus, each entry in the list may consist of approximately 18-20 bytes of information. Since the list has 10,000 entries, storage for each version's list would be approximately 200 kilobytes.
Thus, over five years, one million of those 200 kilobyte lists—or 200 gigabytes—would be generated. Assuming a storage cost of five dollars per gigabyte (which will probably decrease over the five year period), the one million lists could be stored for approximately $1000. It may also be desirable to keep copies of each of the one hundred program releases and the customization parameters for each of the 1,000,000 versions, but this would be relatively small in comparison. Even if an entire copy of each of the 1,000,000 versions were maintained, the memory requirements—assuming a five megabyte program—would be approximately 5000 gigabytes.
5. Dynamic WatermarksIn contrast to static watermarks, such as those described above, which can be detected by analyzing the static image of the program, dynamic watermarks can be detected only (or most-easily) by analyzing the executable as it is running. For example, the program may produce a special output when presented with a special input, the special output serving as the watermark. Dynamic watermarking techniques are related to software “Easter Eggs,” which typically consist of humorous or unexpected information or behavior embedded in a program and accessible only by entering a very specific, and typically unusual, sequence of keystrokes or other commands. For example, Microsoft® Excel 97 contains an Easter Egg that can be found by opening a new worksheet, pressing the F5 key, typing X97:L97, pressing the enter (or return) key, pressing the tab key, then holding down the CTRL and SHIFT keys while using a mouse to click on the “Chart Wizard” icon on the program's toolbar. Upon completion of this input sequence, a primitive flight simulator is displayed. Located within the flight simulator is a sign showing a variety of messages and the names of the program's creators. Additional information on Easter Eggs can be found at http://www.eeggs.com.
Dynamic watermarks can be inserted in a variety of ways and can take a variety of forms. For example, in addition to marks that vary the program's output when presented with a special input, dynamic watermarks may also be encoded in, e.g., variations in the program's run-time performance, variations in the program's memory access characteristics, variations in the program's caching behavior, variations in the program's dynamic control flow, and/or other program characteristics.
For example, subtle changes could be made to the program's internal processing logic so that results would be invariant for “legal” or “expected” inputs, but would differ for special inputs or input sequences. It should also be noted that dynamic watermarking is a good candidate for combination with obfuscation, since obfuscation may include highly complicated calculations designed to make it difficult to determine what is going on. Minor changes in those calculations might have no effect on ordinary user-visible processing, yet cause differences when specific sequences are input into the program.
It will be appreciated that enabling a program to produce a special output or other dynamic watermark will typically entail making some changes to the static image of the program, and thus it would theoretically be possible to detect a “dynamic” watermark by analyzing the static program image. However, the idea behind dynamic watermarking techniques is that recovering the mark via static analysis can be made quite difficult, whereas detecting the mark with the special input can be quite simple. Thus, dynamic watermarking techniques make good candidates for use with in-the-field and/or real-time detection systems. The detection system will preferably record the special input in a protected and/or tamper-resistant environment, and can check for the presence of the watermark by applying the special input to the program and examining the program's response.
As mentioned, one possible dynamic watermarking technique is to design a program so that it reveals a watermark when presented with a special input. An advantage of this approach is that virtually any functionality-preserving transformation (e.g., basic-block reorganization) used by attackers will also preserve the watermark. Another advantage is that it may be much more difficult to detect the existence of a watermark that is not stored statically in the program.
Detection of the code that creates the watermark can be made quite difficult, especially if the code is obfuscated, since the program may include a number of code segments that perform complicated operations, some of which hide predicates, others of which generate a watermark. Since much or most of the precision of some obfuscated operations may be “wasted,” there will often be ample room for instance-based customization. For example, the program might calculate a multi-bit variable and then base an operation, such as a jump, on whether the variable is odd or even.
The strength of this type of watermarking technique can be increased by spreading the effects of the watermarking code beyond the generation of the watermark. For example, in the illustration given above, one instance of the program might check an obscure value to see if it is even and condition a jump on the result, as described above; while a second instance may condition the jump on the value being odd. Thus, in the first program instance the watermark is detected if the value is even, while in the second instance the watermark is detected if the value is odd. This would make it more difficult to strip out the watermark and would also make it more difficult to replace one watermark with another. Cleverly embedding the watermark deeply into the program can make it virtually impossible to remove, particularly since the watermark consists of a relationship between a particular input and a particular output, and the attacker will typically not know which input is used.
Dynamic watermarking generally requires a detailed understanding of the program's functionality, and is best carried out at the source-code level. As such, it is typically not feasible to dynamically watermark generic third-party software, since such software will usually be obtained in executable or object code form. However, it is typically unnecessary to hardwire the watermark in the source code and build it separately for different copies. The source-code can create some primed data structures in the image, which can subsequently be stamped to create the specific watermark.
6. Priming and StampingA variety of advantageous locations have been described in which to insert watermarks, and it will be appreciated that watermarks can be inserted into these locations using any suitable technique, including conventional watermarking and software editing techniques. A problem with conventional watermarking techniques, however, is that they often require significant computational power, time, and/or memory. This can be particularly unsatisfactory if one wishes to place a unique watermark or fingerprint in individual instances of a piece of software or other content, or if one wishes to delegate the responsibility for inserting such a watermark to another party.
The present invention provides systems and methods for reducing the computational resources needed to apply watermarks, and for facilitating more flexible relationships between the parties responsible for inserting watermarks into a given medium. Specifically, in one embodiment watermarks are inserted using a novel, hinted watermarking process that will, for convenience, be referred to as “priming and stamping.” Marks are inserted into the substrate in two stages. In the first stage, known as “priming,” parameterized holders are created and/or identified. During the second stage, known as “stamping,” marks are written into the “primed” holders.
Priming and stamping can be used to minimize the impact that watermarking individual program instances has on program development and debugging. For example, in one embodiment the source code need not be recompiled for differently watermarked copies; instead, the program can be primed before compilation and different marks can then be stamped into different copies of the compiled program, which will typically take much less time than compiling differently-watermarked versions separately. In addition, priming and stamping can be performed without the aid of special tools for analyzing or instrumenting executables, and typically does not require the rearrangement of compiled code.
The priming and stamping process is described in more detail with reference to
As shown in
In the second phase, the watermark payload is embedded in the program using the hints (or primers) that were inserted by priming step 2404. That is, primed program 2406 is stamped (2410) by replacing the primers with customized watermark data. As shown in
As shown in
It will be appreciated that primers can be inserted into the program in any suitable manner. While a combination of macros and inlined functions were used in
It will typically be desirable to use a library of several macros and/or inlined functions, since if one copy of the code is discovered it might be possible to discover other copies inserted using the same macro or inlined function. One general category of containers embeds its content in the data section of the executable, and another general category embeds its content in the code section. For example, the following would insert its content in the data section, whereas the inlined functions would insert its content in the code section.
In a preferred embodiment data section primers are implemented as macros rather than inlined functions, since different invocations of a macro result in separate static variables, while different invocations of an inlined function share a single static variable. Thus, a macro creates multiple copies of the primers, while the inlined function does not. It should also be noted that since the macro is enclosed in a block, it will not cause collision of variable names with the containing block. It may also be inserted multiple times within the containing block without fear of redefining names.
If primers are inserted using macros and/or inlined functions, it will typically be desirable to ensure that the pre-processor and/or compiler inserts enough copies of the macros and/or functions to provide adequate space for storing the marks during stamping. The appropriate number for a given application can be readily determined by simple trial and error experimentation.
In one embodiment the priming process also involves the insertion of source code to hold the watermark and to hide the “uselessness” of the watermark to the overall execution of the program. This code can be thought of as a “container” for the watermark. In general, a watermark container may hold its content in a sequence of possibly non-adjacent slots. At compilation, the content of the container is set to a special pedefined pattern (i.e., the primer), which helps locate the watermark container for stamping.
Watermarks inserted in this manner may have two parts: (i) modifiable content, which is stamped with customized data; and (ii) a fixed container which is set at priming and preferably not modified during stamping. The container serves to blend the marks into the program. It may also provide registration information for locating the marks.
The primer pattern that is initially filled into the watermark holder is used to identify the locations to stamp. The pattern is preferably long enough (e.g., at least 32 bits) that it is simple to find primers that do not occur naturally in the software. It will typically be important to ensure that the pattern used to locate the watermark holders does not result in false matches, since unintended stamping can corrupt the software. One technique for protecting against unintended stamping is to count the number of primers that were found, which should match the number that were originally inserted.
The pattern constituting the container may be used to locate the primer with greater reliability. For example, in the context of a code-section watermark, we look for the primer slots as well as the intervening opcodes in the container. An extension of this approach is to remember the locations where the primer can be found. The location information can be used to speed up the stamping procedure by avoiding (or reducing) the need for pattern matching.
6.1. When?
One of the powerful aspects of priming and stamping is that it enables operations performed at the source-code level (e.g., the insertion of inlined functions or macros) to hint the assembly code, thus enabling the entity in charge of stamping the code to quickly and easily find the locations that can be stamped and apply the watermark thereto. Thus, priming and stamping allows the watermarking process to be conveniently divided between several parties over a period of time.
The priming and stamping steps can be performed in variety of ways and at a variety of different times during a program's creation. For example, priming can be performed at the source code level, during compilation, and/or after compilation. In one embodiment the source code is primed with assembly language patterns and compiled. The patterns can be found in the object code or executable by performing byte-level pattern matching. In another embodiment the compiler itself can be modified to identify resources (i.e., prime the program) and/or to generate differently-stamped copies. Such a technique is able to generate highly stealthy marks (e.g., register re-allocation or placement of variables), although the insertion process can be relatively slow. In yet another embodiment the code is primed after compilation, but before linking. The code can then be linked and/or distributed to others and primed. Another option is to modify a standard linker to perform priming and/or stamping. In yet another embodiment, the program is primed and stamped in executable form (i.e., after the linking process).
Like priming, stamping can be performed in a variety of ways. For example, in one embodiment individual copies of a program are stamped with a unique watermark prior to distribution. Alternatively, or in addition, program copies can be stamped as part of the process of activating or installing the program on a user's computer. For example, the user could be prompted to connect via a network to a computer that supplies the stamps to a protected processing application on the user's computer that would apply them to the program. Although stamping could be performed in an obfuscated and/or protected environment on the user's computer to prevent giving away the location of the watermarks, stamping at the user's computer may be somewhat less secure than stamping the program before distribution to the user, as the user will initially have an unstamped version of the program (or at least portions thereof). However, this may not be a great concern in some applications.
After compilation (2704), the program executable can be customized (e.g., obfuscated), taking care to preserve the primers (2706). To facilitate this process, the positions of the primers can be made known to the customization tool, so that it can avoid altering them. This can be accomplished in a variety of ways. For example, the customization tool can access the primer reading tool directly (e.g., through DLL calls), and/or the primers can be marked with signal flags indicating that a particular section of code is not to be customized. In another embodiment, a primer reading tool is used to generate a file that provides the locations of the primers, and this file is provided to the customization tool. In yet another embodiment some or all of the primers are simply inserted after customization.
After customization,in one embodiment each instance of the program is given credentials. This can be accomplished, for example, by computing one or more hash values (using a suitable hashing algorithm, such as MD5 or SHA-1) for one or more program locations, preferably not including the primed regions. As shown in
Code 2604 may be encrypted, packaged, and sent to customers 2612, 2614 and/or distribution centers 2608 (2710, 2712). The appropriate patches 2606 for each customized instance of the program 2604 are stored at a server 2610 in a list 2616 (2714). Thus, when a customer installs program 2604, the appropriate patches 2606 can be supplied by server 2610. For example, as shown in
In another embodiment, the patches 2606 can be stored on, e.g., the disk on which program 2604 is stored, and the installation program can apply the appropriate patches. It will be recognized that if patch files are distributed from a server 2610, there will be a tradeoff between security and ease of installation. On the one hand, patch files should be relatively small in order to limit the communication overhead of transmitting them from the server to the client. On the other hand, better security can generally be achieved if the patch files include decoy blocks that contain no watermarks, or if the patch files include random intervals around the watermarks to mask the watermarks' exact locations.
Additional description of priming and stamping can be found in the Software Self-Defense application.
7. Combinations of TechniquesIt will be appreciated that the watermarking techniques described herein can be advantageously used in combination with each other and/or with the obfuscation, tamper resistance, and other software self-defense techniques described in the Software Self-Defense application and the '346 application. For example, as previously described, obfuscation mechanisms such as opaque predicates can be used to help disguise watermarks that are hidden in unexecuted code or unused data.
Obfuscation techniques can also be used to provide the watermarks themselves. If the program is obfuscated, e.g., in the manner described in the Software Self-Defense application, the pseudo-random nature of the obfuscation techniques will permit information to be embedded in the binary program by adjusting the choices made during the obfuscation process. That is, each choice of whether to apply obfuscation or not represents a bit of information (and choices of multi-bit values represent multiple bits), and the resulting program contains the encoding of all those bits. Recognizing such encodings can be difficult, in that it requires (at worst) a catalog of all the generated watermarked versions to compare against individually (or the ability to re-generate such a catalog at will). However, signature recognition and other pattern-matching techniques can substantially reduce the computational burden of recognizing such mark encodings even in the face of significant damage to the marked version.
8. Protection of watermarks
A variety of techniques can be used to protect watermarks from detection and removal. In addition to those techniques described previously, many of the software self defense techniques described in the Software Self-Defense application can be advantageously used for this purpose.
8.1. Self-Checking
One method of protecting watermarks from corruption or removal is to include code that performs self-validation at run time. For example, code can be inserted that computes the hash of a region of memory at run time, compares the computed hash value with an expected value, and invokes a tamper response mechanism if the two do not match. The self-validation test need not be focused solely on the watermarks, but can instead test a wide range of memory that includes one or more watermarks or portions thereof. The tests are preferably stealthy and recursive, such that tampering with one test is likely to cause another test to fail. Additional self-validation techniques are described in the Software Self-Defense application.
8.2. Obfuscation
Software obfuscation techniques such as those described in the Software Self-Defense application and the '346 application can also be used to protect watermarks from detection or removal. In addition to using specific obfuscation techniques and constructs directly in connection with encoding and embedding watermarks in a piece of software, the general application of obfuscation techniques will typically also help to protect the watermarks contained in the program, as the more difficult the program is to understand, the more difficult it will be for an attacker to identify the watermarks.
In addition, and as described elsewhere herein, obfuscation techniques can be specifically used to protect watermarks and/or to obscure their relation to the program. For example, obfuscation techniques such as opaque predicates can be used to make watermarks appear as though they affect the program's behavior, thus reducing the chances that an attacker will discover the watermarks by searching for useless code or data.
An example of an opaque predicate is a function or expression that always evaluates to a particular value or values—e.g., true or false—regardless of its input, but is coded such that it is difficult to deduce this. Such a function can thus be used in, e.g., a code branch to make it look like certain code or data might affect the program's behavior, when in reality, the code or data are never reached due to the fact that the condition never evaluates in that direction. Additional examples of opaque predicates and their use can be found in the Software Self-Defense application, the '346 application, and in the Cohen paper, each of which was previously incorporated by reference herein.
In one embodiment, a watermark and an opaque predicate are combined into a single standardized macro or inlined function so that the opaque predicate is executed in the scope of the watermark. The standardized interface also makes it easy to interchange the opaque predicates that are used. The following is an example of such a macro interface in accordance with an embodiment of the present invention.:
-
- int OpaquePredicate(int size, int*array);
Another issue is the choice of the obfuscation code for the branch that the opaque predicate never takes. In one embodiment the obfuscation branch loops back to the opaque predicate. Note that successive calls to the opaque predicates described above differ in the values of their static variables. In a preferred embodiment, the obfuscation code is tailored to look like useful code in the host program.
The code rearrangement and/or other obfuscation and tamper resistance techniques described in the Software Self-Defense application also provide powerful resistance to cropping and/or deletion attacks, as these techniques generally make identification of a useful part of the program more difficult.
Relatively weak obfuscation, tamper resistance, and/or watermarking techniques can be used to decoy the operation of more effective techniques. For example, decoys can be used to lure the attacker into making program modifications that will break the program or trigger detection of the attacker's activity. For example, having detected a weak watermark or obfuscation technique, the attacker might press forward with eradicating or counteracting it, and not realize that in so doing, he has triggered other, more subtle defensive measures. For example, when removing a weak watermark, the attacker could be lured into making changes to the program binary that would cause the program to fail built-in self-checks, crash or yield incorrect results, and/or trigger communication with an external detection agent.
8.3. Customization
Customizing different instances of a watermarked program makes it harder to identify or remove the watermarks. For example, as described elsewhere herein, customization can make a collusive attack much more difficult by making randomly-picked copies difficult to compare.
Since it may be relatively expensive for a company to generate a different customized copy of a program for each customer, a probability will exist that attackers will be able to get multiple copies of the program with the same customization. However, as shown above, the probability of getting c copies with the same customization decreases steeply with c. That is, it will typically be much more difficult to obtain ten copies of a program with the same customization than it will be to obtain two copies. Thus, it will usually be sufficient to resist only a small degree of collusion. On the other hand, the space overhead of anti-collusion encodings typically increases relatively steeply with the degree of collusion to be resisted, so it will generally be desirable to assure a relatively low degree of collusion by producing a sufficiently large number of differently-customized versions.
8.4. Stealth
Watermarks can also be protected by making the marks and/or their containers blend in with the rest of the program. As described above, watermarks and/or their containers can be made stealthy by using a variety of techniques. For example, watermarks and their containers can use common opcodes, opcode sequences, operands, addressing modes, prefixes, and the like. Statistical modeling techniques can be used to further ensure that the watermarks and containers look like the rest of the code/data in the program. In addition, stealth can be provided by making watermarks and/or containers relatively small. For example, a holder could consist of a single instruction. Stealth can also be enhanced by minimizing the range of possible values used for each container, given the constraints imposed, or made desirable, by other defensive techniques, such as those used to counter forgery or collusion.
8.5. Anti-Debugging
Attackers might attempt to use a debugging tool to analyze the structure and operation of a program in an effort to locate, remove, or forge watermarks. Thus, one way to protect watermarks is to include mechanisms that detect, hinder, and/or prevent the use of debuggers. A variety of such mechanisms are described in the Software Self-Defense application, any suitable ones of which could be used.
Although the foregoing invention has been described in some detail for purposes of clarity, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. It should be noted that there are many alternative ways of implementing both the processes and apparatuses of the present invention. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.
APPENDIX AHere we analyze the strength of the two-layer collusion-resistant watermarking code described above in Section 3.7.1.
The analysis that follows assumes generally that:
-
- The bits constituting the watermark (or “fingerprint”) are inserted at secret locations, such that an attacker can detect the location of a bit only by comparing copies that differ in that location;
- An attacker cannot alter fingerprint bits that are undetected. (Note, however, that in practice the analysis that follows will still hold true even if an attacker alters bits randomly, as long as the fraction of undetected fingerprint bits that are altered is small).
- The provider uses a private decoder to infer the identity of a colluder.
It will be appreciated; however, that while the following analysis is based on these assumptions, the practical encoding techniques to which the analysis relates can be used even if one or more of these assumptions is not met, or even if some of the conditions or “requirements” set forth below are not satisfied. While, in such a situation, the encoding scheme may not enjoy the same level of theoretical strength as one which satisfies the assumptions and requirements set forth herein, one of ordinary skill in the art will appreciate that in many cases the level of strength that such an encoding scheme is able to provide will, depending on the application and the expected sophistication of attack, be adequate. Thus, the following analysis should be considered illustrative and not limiting as to the scope of the present invention.
1. Analysis
Suppose c fingerprints are used in an attack to create a corrupted fingerprint. We will refer to the c fingerprints as the “colluding fingerprints.” The provider decodes the corrupted fingerprint successfully if some colluding fingerprint has a higher match than all non-colluding fingerprints.
It is possible for attackers to decrease the match of one colluding watermark at the cost of increasing the match of other colluding fingerprints. However, attackers need to minimize the maximum such match, so the strongest attack keeps the matches of all colluding fingerprints roughly the same. Assuming such an attack, it suffices to study the match of a randomly-chosen colluding fingerprint. Let,
fr=the corrupted fingerprint
fc=a colluding fingerprint, chosen randomly
fa=an assigned fingerprint, chosen randomly
For decoding to succeed, a symbol in fr should be more likely to match the corresponding symbol in fc than it is to match the corresponding symbol in fa. Let,
mc=probability that a symbol in fr matches the corresponding symbol in fc
ma=probability that a symbol in fr matches the corresponding symbol in fa
M(f)=match of f
If (mc>ma), it is possible to increase the number of symbols in a fingerprint, n, to arbitrarily increase the probability that the M(fc)>M(fa). In this case, the probability of decoder error can be reduced arbitrarily. Let,
Section 2, below, entitled “The Length of the Outer Code,” shows how e1 reduces as n increases. However, if mc is not greater than ma, increasing n will not help the code resist collusion.
Next, we compute mc and ma under various forms of attacks. For simplicity of analysis, we assume that, if attackers detect one bit in a symbol, they detect the entire b-bit representation. This may actually happen if the bits of a symbol are located together in the fingerprinted content. In any case, this assumption is conservative: without it, the code would be more secure.
Let,
X=multi-set of c symbols found in some random position of the colluding fingerprints
If all symbols in X are identical, the colluders cannot detect this symbol position, so the corrupted fingerprint fr contains the same symbol at that position. The fraction of symbol positions that remain undetected is expected to be:
h=1/qc−1
In an undetected position, fr matches fc perfectly and matches fa with probability 1/q. Therefore,
mc=h*1+(1−h)*mc′
ma=h*1/q+(1−h)*ma′
where,
mc′=probability that a detected symbol in fr matches the corresponding symbol in fc
ma′=probability that a detected symbol in fr matches the corresponding symbol in fa
If the colluders detect a symbol position, they can set the corresponding symbol in the corrupted fingerprint in the following ways:
Retain Attack: An attacker might retain a symbol from X. In this case, ma′=1/q and mc′=y/c, where y is the number of times the retained symbol occurs in X. The strongest such attack would minimize mc′ by retaining the minority symbol in X. If there were always a minority of 1, mc′=1/c. This suggests that if q<c, mc′ might be less than ma′, which might cause mc not to be greater than ma, causing the code to fail. This is the case when q=2 and c=3. In this case, detected symbol positions always have a minority of one, so:
mc′=⅓
ma′=½
h=¼
mc=¼+¾*⅓=½
ma=¼*½+¾*½=½
In fact, we have found through simulations that even when the expected occurrence of the minority symbol in X is greater than 1 (true for c>3), the code fails when q<c. On the other hand, if q≧c, we know that mc′≧ma, so me>ma, and the code is secure provided n is suitably large.
Forge attack: In a forgery attack, the attacker forges a symbol not found in X. However, the set of valid symbol representations at any position is private to the provider. Therefore, the colluders cannot forge a valid symbol representation except by chance. (If the colluders could forge a valid symbol, they would gain a significant advantage: ma′=1/q and mc′=0, causing the code to fail). Let,
Using the conservative value for g,
mc′=0
ma′=g/q=1/2b
Now we can compute the value of b needed to withstand attack.
mc=h
ma =h/q+1/2b
For mc>ma,
Therefore, a conservative value for b is greater than c*log(q).
Note that when q≧c, the minority-retain attack results in (mc′≧ma′) while the forge attack results in (mc′<ma′). Therefore, when q≧c, the forge attack is stronger.
2. The Length of the Outer Code
Here we show how e1 decreases with n. M(fc) is a binomial variable B[n, mc]. Similarly, M(fa) is B[n, ma]. For large n, B[n, p] is roughly normal, N[n*p, n*p*(1−p)]. If M(fc) and M(fa) are independent, their difference is roughly normal too, N[n*(mc−ma), n*(mc*(1−mc)+ma*(1−ma))]. Therefore,
Therefore, it is sufficient to set n as follows to keep probability of decoder error under e:
n>2*(mc(1−mc)+ma(1−ma))/(mc−ma)2*log(u/e)
Suppose b=c*log(q)+1. Then,
mc=1/qc−1
ma=1/qc+1/(2qc)=3/(2qc)
So a sufficient value for n is,
When q =c,
n=14*cc+2*log(u/e)
Note that the bit length of the watermark is n*b=14*cc+3*log(c)*log(u/e).
Claims
1.-44. (canceled)
45. A method for watermarking computer code performed by a computer system comprising a processor and a memory encoded with program instructions that, when executed by the processor, cause the system to perform the method, the method comprising:
- analyzing the computer code to identify a plurality of watermark locations;
- inserting a plurality of primer code sequences into the plurality watermark locations to generate primed computer code; and
- stamping the primed computer code by embedding a plurality of watermark payloads at the locations of the plurality of primer code sequences to generate watermarked computer code.
46. The method of claim 45, wherein analyzing the computer code to identify the plurality of watermark locations comprises determining a degree that an insertion of a watermark at the plurality of watermark locations would impact the performance of the computer code.
47. The method of claim 45, wherein analyzing the computer code to identify the plurality of watermark locations comprises determining whether the plurality of watermark locations are located in frequently-executed loops in the computer code.
48. The method of claim 45, wherein the plurality of primer code sequences comprise code sequences having a distinctive pattern.
49. The method of claim 45, wherein embedding the plurality of watermark payloads at the locations of the plurality of primer code sequences comprises replacing the plurality of primer code sequences with the plurality of watermark payloads.
50. The method of claim 45, wherein prior to stamping the primed computer code, the method further comprises applying at least one transformation to the primed computer code.
51. The method of claim 50, wherein the primed computer code comprises source code and the at least one transformation comprises compilation of the primed computer code into object code.
52. The method of claim 50, wherein the primed computer code comprises object code and the at least one transformation comprises linking the object code to form an executable.
53. The method of claim 50, wherein the plurality of primer code sequences are unaffected by the at least one transformation.
54. The method of claim 50, wherein the at least one transformation transforms the plurality of primer code sequences in a predefined way.
55. The method of claim 45, wherein the computer code comprises a plurality of macros and wherein analyzing the computer code to identify the plurality of watermark locations comprises identifying the locations of the macros in the computer code.
56. The method of claim 55, wherein inserting the plurality of primer code sequences into the plurality of watermark locations comprises processing the plurality of macros.
57. The method of claim 55, wherein the plurality of macros are selected from a library of macros.
58. The method of claim 57, wherein each primer code sequence of the plurality of primer code sequences are unique.
59. The method of claim 45, wherein the computer code comprises a plurality of inlined functions and wherein analyzing the computer code to identify the plurality of watermark locations comprises identifying the locations of the inlined functions in the computer code.
60. The method of claim 59, wherein inserting the plurality of primer code sequences into the plurality of watermark locations comprises processing the plurality of inlined functions.
61. The method of claim 45, wherein the computer code comprises at least one macro and at least one inlined function and wherein analyzing the computer code to identify the plurality of watermark locations comprises identifying the locations of the at least one macro and the at least one inlined function.
Type: Application
Filed: May 4, 2017
Publication Date: Oct 19, 2017
Applicant: Intertrust Technologies Corporation (Sunnyvale, CA)
Inventors: William G. HORNE (Lawrenceville, NJ), Umesh MAHESHWARI (San Jose, CA), Robert E. TARJAN (Princeton, NJ), James J. HORNING (Palo Alto, CA), W. Olin SIBERT (Lexington, MA), Lesley R. MATHESON (Campbell, CA), Andrew K. WRIGHT (Monroe Township, NJ), Susan S. OWICKI (Palo Alto, CA)
Application Number: 15/587,038
