Watermarking
in [Embedded]
|
From: Oliver Betz on 15 Apr 2010 03:31 Hello Don, >>> Anyone with FIRST HAND experience deploying watermarking >>> technologies? Comments re: static vs dynamic techniques? >> >> has your hardware external program memory or do they run from internal >> flash? If the latter, distribute encrypted binaries. > >Encrypting tries to *prevent* counterfeiting. That's not the >goal as far as I understand, that's exactly the goal. You don't want someone to change the "watermark". > (too often, there are ways to access internal resources >by exploiting something in the device). These exploits are likely more expensive than circumventing the other watermarking methods cited in this thread. >Stated goal is to track where "copies" came from. Presumably, >prosecute the source of the leak -- who probably doesn't That's trivial if you distribute encrypted files. The ID ("watermark") can be in the encrypted file ((part of) the cipher's initialization vector) and in the application showing up somewhere in the user interface or the update routine (e.g. boot loader). Oliver -- Oliver Betz, Munich despammed.com might be broken, use Reply-To:
From: D Yuniskis on 15 Apr 2010 11:41 Hi Oliver, Oliver Betz wrote: > >>>> Anyone with FIRST HAND experience deploying watermarking >>>> technologies? Comments re: static vs dynamic techniques? >>> has your hardware external program memory or do they run from internal >>> flash? If the latter, distribute encrypted binaries. >> Encrypting tries to *prevent* counterfeiting. That's not the >> goal > > as far as I understand, that's exactly the goal. You don't want > someone to change the "watermark". Let me rephrase: encryption prevents copying (which would be an added bonus!) The goal here is not to prevent but, rather, to *track* where a copy originated. Preventing copying is often harder to accomplish; and, is very obvious to the potential copier that you have taken measures to try to thwart that. OTOH, watermarking need not "announce" itself to the thief. He perceives a copyable product. He makes his copy and his copy *works*, etc. >> (too often, there are ways to access internal resources >> by exploiting something in the device). > > These exploits are likely more expensive than circumventing the other > watermarking methods cited in this thread. For "small fish", you are correct. But, for big players, you would be surprised at how quickly and easily a product can be copied -- *if* you don't have to understand how it works! (I won't go into that here; google is your friend :> ) >> Stated goal is to track where "copies" came from. Presumably, >> prosecute the source of the leak -- who probably doesn't > > That's trivial if you distribute encrypted files. The ID ("watermark") > can be in the encrypted file ((part of) the cipher's initialization > vector) and in the application showing up somewhere in the user > interface or the update routine (e.g. boot loader). OK, so you are watermarking *then* encrypting. But, you still need a robust means of watermarking the executable (that can't be easily altered, thwarted, etc.) *That's* the issue I am trying to address.
From: Oliver Betz on 15 Apr 2010 14:34 Hello Don, >>>>> Anyone with FIRST HAND experience deploying watermarking >>>>> technologies? Comments re: static vs dynamic techniques? >>>> has your hardware external program memory or do they run from internal >>>> flash? If the latter, distribute encrypted binaries. >>> Encrypting tries to *prevent* counterfeiting. That's not the >>> goal >> >> as far as I understand, that's exactly the goal. You don't want >> someone to change the "watermark". > >Let me rephrase: encryption prevents copying (which would It makes it harder to copy the whole device or disassemble the executables, but we make accessible (encrypted) firmware files freely to our customers. Therefore... >be an added bonus!) The goal here is not to prevent but, >rather, to *track* where a copy originated. Preventing >copying is often harder to accomplish; and, is very obvious >to the potential copier that you have taken measures to >try to thwart that. OTOH, watermarking need not "announce" >itself to the thief. He perceives a copyable product. >He makes his copy and his copy *works*, etc. ....that's also true for our devices (unless you mean by "copyable" that the customer is also allowed to copy the hardware). [...] >OK, so you are watermarking *then* encrypting. But, you still >need a robust means of watermarking the executable (that can't >be easily altered, thwarted, etc.) *That's* the issue I am trying >to address. Since the executable is not directly accessible to the customer, I simply could put a notice e.g. in the boot message. The customer only sees the encrypted file and the bootloader will not accept it if it's changed. Oliver -- Oliver Betz, Munich despammed.com might be broken, use Reply-To:
From: George Neuner on 15 Apr 2010 19:30 On Sun, 11 Apr 2010 17:17:15 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >Hi, > >Anyone with FIRST HAND experience deploying watermarking >technologies? Comments re: static vs dynamic techniques? > >Also, any FIRST HAND (not hearsay) experiences with its use >in litigation -- that you can *discuss* openly? Or, pointers >to cases of interest? I only know (first hand) of two and >technology has changed considerably in the years since... > >Any pointers to (market) perceptions of watermarking? > >Comp.realtime included as to any insights regarding how >RT characteristics could be exploited to provide other >watermarking opportunities (not typically available to >non-RT applications). > >Finally, any pointers to techniques to circumvent these? >And, the effort required? > >Thx, >--don I've been following your conversation with whygee. No watermarking scheme is foolproof or unforgeable, and marking an executable is harder because it isn't possible to fuzz code like data. I've read about "functional marking", changing the program's runtime behavior based on some key ... for example, strobing indicator lights in a pattern that's hard to discern by eye but could be clearly seen using a movie camera. But I don't see an easy way to do something that would remain non-obvious if the program were disassembled. I agree with whygee that the best way to mark an executable is to abuse equivalent code sequences. However, I think it should be done *after* compilation, using a patching tool and starting from the unaltered binary. I also agree that the patches should be based on some (well distributed) customer id - perhaps a crypt hash on the customer information. You want to substitute code sequences of equal length (unless PIC code makes it unnecessary). As an stupid example, it won't do any good to replace an addition with a subtraction if you then also need to set/clear a carry bit for the subtract instruction to work. You need to find a set of substitutions that are safe to make and which won't affect other code, but it helps that the substitution sequences can be specific to the binary being marked. In many ISAs it does not affect the length of the code sequence to negate a comparison by reversing the operand order and then to branch on the negative result. Obviously you don't want to do this just anywhere because it potentially could mess up a multi-way branch, however, you can safely negate/reverse any 2-way branch. During coding, you could manually tag good candidates with a label and then pick the labels out of a map file or assembler listing of your release compile. George
From: whygee on 15 Apr 2010 20:10
Hello, George Neuner wrote: > I agree with whygee that the best way to mark an executable is to > abuse equivalent code sequences. However, I think it should be done > *after* compilation, using a patching tool and starting from the > unaltered binary. In practice, post-patching is more difficult than source-code #defines. My previous idea does not make any assumption about the target architecture and C does not use carry bits so there is no risk of borking the binary. Sure, it is a bit more cumbersome for the source code but I have done worse... A "macro" could help there : #define ADD_IMM(src, imm, dest, define) \ #ifdef define {dest = src + imm;} #else {dest = src - (-imm);} #fi (a m4 script could be better) To help "calibrate" the detection routines, it sounds interesting, after the source code is ready, to compile with all #ifdef set, and make another binary without any #ifdef. The "XOR" of the two results will show where all the ADDs are, with the added bonus that the -imm xor imm will show up as plain 0xFF(FF(FFFF)) :-) plus a bit before for the opcode. That would be an interesting hack to try... Now, looking at code I wrote today, I see very few constant adds. But I see a fair amount of constants, which opens another door... For example, imagine a system call : syscall(42) 42 can be decomposed in myriads of ways, both by addition and substraction, or even XOR or AND. You need 2 operands and 1 operator. Store the 2 operands in volatile ints (so they are not optimised away), they provide one int of entropy (the other int is a linear combination based on the first int). Two more bits are provided with the combining operation : and, xor, add, sub. Here again, macros and/or m4 will be useful. A sed script can even parse the C files and build a .h from the macro names it has found. And it's still independent of any ISA. OK, I stop here, I feel too tired to think right, but you see the idea (I hope) > George yg -- http://ygdes.com / http://yasep.org |