1.6 Software Watermarking
There are various scenarios where you would like to mark an object to indicate that you claim certain rights to it. Most famously, the government marks all their paper currency with a watermark that is deeply embedded in the paper and is therefore difficult to destroy or reproduce. For example, if you found a torn or damaged part of a note, you could hold it up to the light and use the watermark to identify the original value of the note. Also, if a forger attempts to pay you using photocopied currency, the missing watermark will alert you to the fact that the currency is not genuine.
There has been much work in the area of media watermarking, where the goal is to embed unique identifiers in digital media such as images, text, video, and audio. In a typical scenario, Doris has an online store that sells digital music. When Axel buys a copy of a song, she embeds two marks in it: a copyright notice A (the same for every object she sells) that asserts her rights to the music, and a customer identification number B (unique to Axel) that she can use to track any illegal copies he might make and sell to Carol:
If Doris gets ahold of an illegal copy of a song, she can extract the customer mark B (B is often referred to as a fingerprint), trace the copy back to Axel as the original purchaser, and then take legal action against him. If Axel were to claim “Well, I wrote and recorded this song in the first place,” Doris can extract her copyright notice A to prove him wrong.
Media watermarking algorithms typically take advantage of limitations in the human sensory systems. For example, to embed a watermark in a piece of music, you can add short—and to the human ear, imperceptible—echos. For every 0-bit of the mark, you’d add a really short echo and for a 1-bit, you would add a slightly longer echo. To mark a PDF file, you’d slightly alter the line spacing: 12 points for a 0-bit, and 12.1 points for a 1-bit. To mark an image, you’d slightly increase or decrease the brightness of (a group of) pixels. In all these cases you also need to decide where in the digital file you will make the changes. This is often done by means of a random number generator that traces out a sequence of locations in the file. The seed to the generator is the key without which you cannot extract the watermark. So a typical watermarking system consists of two functions, embed and extract:
Both functions take the secret key as input. The embed function also takes the original object (known as the cover object) and the watermark (the payload) as input, and produces a watermarked copy (the stego object) as output. The extract function, as the name implies, extracts the watermark from the stego object, given the correct key. This is just one basic watermarking system, and we’ll discuss others in Chapter 8 (Software Watermarking).
As you see from the figures above, we also have to take the adversary into account. Axel will want to make sure that before he resells Doris’ object he’s destroyed every watermark she’s embedded. More precisely, he needs to somehow disturb the watermark extraction process so that Doris can no longer extract the mark, even given the right key. In a typical attack, Axel inserts small disturbances into the watermarked object, small enough that they don’t diminish its value (so he can still resell it), but large enough that Doris can no longer extract the mark. For example, he might randomly adjust the line spacing in a PDF file, spread a large number of imperceptible echoes all over an audio file, or reset all low-order bits in an image file to 0. Media watermarking research is a game between the good guys who build marking algorithms that produce robust marks and the bad guys who build algorithms that attempt to destroy these marks. In both cases, they want the algorithms to have as little impact on a viewer’s/listener’s perception as possible.
Of course, our interest in this book is watermarking software, not media. But many of the principles are the same. Given a program P, a watermark w, and a key k, a software watermark embedder produces a new program Pw. We want Pw to be semantically equivalent to P (have the same input/output behavior), be only marginally larger and slower than P, and of course, contain the watermark w. The extractor takes Pw and the key k as input and returns w.
1.6.1 An Example
Take a look at the example in Listing 1.6▸39. How many fingerprints with the value "Bob" can you find? Actually, that’s not a fair question! As we’ve noted, we must assume that the algorithms Doris is using are public, and that the only thing she’s able to keep secret are the inputs to these algorithms. But nevertheless, have a look and see what you can find. One fingerprint stands out, of course, the string variable "fingerprint"! Not a very clever embedding, one might think, but easy to insert and extract, and if nothing else it could serve as a decoy, drawing Axel’s attention away from more subtle marks.
Listing 1.6. Watermarking example.
import java.awt.*; public class WMExample extends Frame { static String code (int e) { switch (e) { case 0 : return "voided"; case 6 : return "check"; case 5 : return "balance"; case 4 : return "overdraft"; case 2 : return "transfer"; case 1 : return "countersign"; case 3 : return "billing"; default: return "Bogus!"; } } public void init(String name) { Panel panel = new Panel(); setLayout(new FlowLayout(FlowLayout.CENTER, 10, 10)); add(new Label(name)); add ("Center", panel); pack(); show(); } public static void main(String args[]) { String fingerprint = "Bob"; if (args[0].equals("42")) new WMExample().init(code(7).substring(0,2) + code(5).charAt(0)); int x = 100; x = 1 - (3 % (1 - x)); } }
What else? Take a look at the code method. What Doris did here was to encode the string "Bob" in base 26 as bob26 = 1 · 262 +14 · 161 + 1 = 104110, using a = 0, b = 1, ..., o = 14, ..., z = 25. She then turned 1041 into a permutation of the integers 0, 1, 2, 3, 4, 5, 6, getting
- 0 → 0, 1 → 6, 2 → 5, 3 → 4, 4 → 2, 5 → 1, 6 → 3
This permutation, in turn, she used to reorder the cases of the switch statement in the code method. To extract the mark, she would have to do the process in reverse. First, she would need to find the method into which the mark is embedded (the secret key would point out the code method), extract the permutation from the switch statement, turn the permutation into 1041, and finally, decode that as the string "bob". There are many algorithms that, like this one, are based on permuting aspects of a program to embed a mark. The very first published water-marking algorithm [104,263] (a Microsoft patent), for example, permutes the basic blocks of a function’s control flow graph. In Section 8.4▸486, we will discuss this further.
Now what about the statement x=1-(3%(1-x))? Here, Doris created a translation table from letters to binary operators:
+ |
− |
* |
/ |
% |
|
1 |
a |
b |
c |
d |
e |
2 |
f |
g |
h |
i |
j |
3 |
k |
l |
m |
n |
o |
4 |
p |
q |
r |
s |
t |
5 |
u |
v |
w |
x |
y |
6 |
z |
Thus, the three letters of the string "bob" turn into the operand/operator-pairs 1-, 3%, 1-, which when stitched together become x=1-(3%(1-x)). This is similar in flavor to an algorithm by Monden [252,263] et al., which we will talk about in Section 8.7.1▸505.
The three marks we’ve seen so far are all static, i.e., they’re embedded directly into the code of the program. In our example we’ve embedded into source code, but we could have used any convenient program representation, including binary code, Java bytecode, or any of the many intermediate code forms used in compilers. We will discuss static algorithms further in Chapter 8.
There is one final mark in the program, however, and this is a dynamic finger-print. What this means is that the fingerprint only appears at runtime, and only for a particular input to the program. When Doris starts the example program with the secret input key 42, the statement
new WMExample().init(code(7).substring(0,2) + code(5).charAt(0));
executes and displays the embedded fingerprint:
In Chapter 9 (Dynamic Watermarking), we will discuss these types of watermarks. In practice, of course, they are never as obvious as this: It’s too easy for Axel to find the code that would pop up a window with a string in it. Rather, the watermark is hidden somewhere in the dynamic state of the program, and this state gets built only for the special, secret input. A debugger or a special-purpose recognizer can then examine the state (registers, the stack, the heap, and so on) to find the fingerprint.
1.6.2 Attacks on Watermarking Systems
As in every security scenario, you need to consider possible attacks against the watermark. Doris has to assume, of course, that Axel will try to destroy her marks before trying to resell the program. And, unfortunately, there’s one attack that will always succeed, that will always manage to destroy the watermark. Can you think of what it is? To be absolutely sure that the program he’s distributing doesn’t contain a watermark, well, Axel can just rewrite the program from scratch, sans the mark!4 We call this a rewrite attack:
Axel can also add his own watermarks to the program. We call this an additive attack:
An additive attack might confuse Doris’ recognizer, but more important, it may help Axel to cast doubt in court as to whose watermark is the original one. A distortive attack applies semantics-preserving transformations (such as code optimizations, code obfuscations, and so on) to try to disturb Doris’ recognizer:
Finally, Axel can launch a collusive attack against a fingerprinted program by buying two differently marked copies and comparing them to discover the location of the fingerprint:
To prevent such an attack, Doris should apply a different set of obfuscations to each distributed copy, ensuring that comparing two copies of the same program will yield little information.
One clever attack that Axel may try to use is not an attack on the watermark itself. Rather, Axel could try to bring into question the validity of Doris’ watermark by pretending that the software contains his own watermark. Axel simply writes his own recognizer that “recognizes” this program as containing his mark. If he is successful, we could not tell which was the true recognizer and Doris would not be able to present a legally convincing claim on her own program.
In Chapter 8 and Chapter 9 we will describe many software watermarking algorithms. Some will be useful for watermarking entire applications, others are good for parts of applications. Some will work for binary code, others are for typed bytecode. Some will embed stealthy marks, some will embed large marks, some will embed marks that are hard to remove, and some will have low overhead. However, we know of no algorithm that satisfies all these requirements. This is exactly the challenge facing the software watermarking researcher.