Watermarking
in [Embedded]
|
From: D Yuniskis on 17 Apr 2010 15:16 Hi Oliver, Oliver Betz wrote: >>>> 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. >> Presumably (though not a guaranteed fact), all of your images >> are identical (i.e., the *decrypted* version). I.e., if I > > yes, I don't use any "watermarking". OK. So, if someone copied one of your devices, you would have no way of knowing which particular device was the source of the copy (?) >> picked up 2 of your devices and reverse engineered them, I >> would see two things identical "under the hood", right? > > yes (if they have the same firmware revision). > >> So, if I *copy* the device-as-ready-to-accept-an-encrypted-image, >> I can use any of your future released images. And, you can't >> tell *which* particular device I used as the template for my >> original "copy". >> >> The goal here is to acknowledge that copying *is* possible >> (and affordable). But, to try to track where a "leak" > > but I expect copying to be as expensive as reverse engineering any > watermarking you are thinking about. No. Copying doesn't require an understanding of the product, its internals, etc. Folks who "specialize" in copying need not have any knowledge of the industry that the device is serving, "why" it does what it does, etc. All they need to do is reproduce what has been given to them. They can "copy" a medical device today and a consumer video game tomorrow. They aren't trying to enhance the item they are copying. Nor are they trying to disguise their actions. E.g., someone who counterfeits paintings need not have any appreciation for "art". > Have you any numbers about the cost to get the content of a flash > microcontroller if it's "copy protection" is used? For example, we are > using Freescale 9S08, S12, Coldfire V2 and I could also imagine to use > a STM32. No idea. In the 80's, you could get a "generic" design copied for ~$50K. That was a *lot* less than it cost to create the design in the first place! But, all you got was a *literal* copy of the design (photoplots for the boards, bills of materials, ROM images, etc.). Even full custom LSI wasn't "off limits" -- getting photomicrographs of the dies, etc. Of course, technology has moved forward. Lithography is now finer. You can't photograph "flash contents", etc. But, *tools* have also progressed. And, there are now new labor markets that can be tapped for these activities. Look at how "secure" the various "security technologies" have proven to be. Look at the tools available to students in labs nowadays (how long did the XBox's "security" stand up to "not for profit" attack?). Relying on schemes to *prevent* copying is a losing battle. Instead, it seems vendors turn to litigation to discourage ex post facto this copying. So, the trick is, to come up with a way that makes it hard for the thief to claim he as an "original creation". And, find ways to put pressure on folks who might "leak" a design to a competitor/counterfeiter ahead of its formal market introduction. I suspect Apple has every preproduction iWhatever *seriously* accounted for!
From: George Neuner on 17 Apr 2010 21:36 On Fri, 16 Apr 2010 11:08:33 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >George Neuner wrote: > >> 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. > >No, I am not talking about anything that has to be obvious >to a "special observer" -- other than an observer that >can disassemble (meaning "decompose into small physical >pieces") the device in question and compare it to a >"template" suspected of being the original for the copy. > >What you want is something that an observer with two (or >more) instances (avoiding the term "copy") of an executable >will recognize as "different" -- but, won't be able to easily >figure out how to convert either of them into "yet another" >instance that retains all of the original functionality. That is a *very* different thing than watermarking ... watermarking is simply a scheme to identify the source of an item that may be counterfeited. >> 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 > >But those are trivial to identify. I.e., they have to >occupy the same space in all "incantations". They will >tend to be confined to very small pieces of memory >(huge code sequences get harder to manipulate while >still satisfying any control transfers out/in). And, >they will tend to be simple -- analysis will make it >readily apparent that the changes are "meaningless": >"Here he adds 5; there he subtracts -5. <shrug>" Making it variable is possible but creates a problem identifying the watermark. Again, I think you're after something different. > >> 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. > >But, you see, that is exactly the sort of thing that makes >this approach trivial to circumvent. It isn't trivial ... if you start with a well distributed customer id (say a crypto hash of the customer info) which is 160..256 bits long and only patch locations corresponding to '1' bits in the hash, a counterfeiter would need many samples of patched executables to unravel the scheme. Even having the unaltered binary would not help much. And the scheme can be made more complicated by using bits of the customer id in groups and skipping over potential patch points based on them. >Imagine, for example, compiling each instance with a different >compiler and linkage editor. Or, with a different level >of optimization. etc. (this won't work, either, because it >can make *big* changes to the performance/requirements of >the device). I.e., in each case, its the same "product" >but the code images look very different. > >> 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. > ><frown> I don't see this as a realistic way forward. It >puts too much burden on the developer. And, doing it >as a post process means the tools *developed* to do it >would be complex -- would they introduce bugs, etc. > >I think, for a given, known toolchain, you could get >the results I need just by clever manipulations of the >sources -- *without* the participation or consent of >the developer (i.e., by fudging things that he >technically "can't control" as inherent in the >language specification). > >I think I'll try wrapping some preprocessor directives >around select code sequences and building some M4 macros >to massage the sources as I would think they could be. >Then, look at the results. I think that is a non-starter ... unless you use inline assembler you'll be working against the compiler. See my post to whygee. George
From: George Neuner on 18 Apr 2010 01:38 On Sat, 17 Apr 2010 12:38:19 +0200, whygee <yg(a)yg.yg> wrote: >George Neuner wrote: >> On Fri, 16 Apr 2010 02:10:18 +0200, whygee <yg(a)yg.yg> wrote: >>> 42 can be decomposed in myriads of ways, >> >> And any way that statically leads to 42 can be optimized away by the >> compiler. Do you seriously think that if you write >> >> syscall( 40 + 2 ) >> or >> syscall( (~0xD6) + 1 ) >> >> that the addition(s) or complement will be done at runtime? > >no, I intended to put the 2 constants in "volatile int"s. > >volatile int const42_1=40, const42_2=2; >... >syscall (const42_1 + const42_2); OK. The next question is, how do you "read" such a watermark to discover the source of a stolen executable? AFAICS, with your method a copy would need to kept for comparison. With the system I am thinking about, the customer id can be recovered directly from the suspect executable. YMMV. I see it as a horrible maintenance problem generating different code for each client - it's bad enough dealing with platform differences. Patching a function watermark into the release executable after the fact also bothers me, but less than having lots of, otherwise unnecessary, conditional code in the source. George
From: Oliver Betz on 18 Apr 2010 05:12 George Neuner wrote: [...] >YMMV. I see it as a horrible maintenance problem generating different >code for each client - it's bad enough dealing with platform ack, IMO that's the main problem. Such a method is only viable for very small production volumes and expensive devices. Oliver -- Oliver Betz, Muenchen (oliverbetz.de)
From: Oliver Betz on 18 Apr 2010 05:12
Hello Don, [...] >> yes, I don't use any "watermarking". > >OK. So, if someone copied one of your devices, you would have >no way of knowing which particular device was the source of >the copy (?) no, I don't care. Nobody did so till now and there is also some other specific knowledge he needed to be successful. "Watermarking" would be much more effort for us than advantage since we sell to many customers and also via dealers. [...] >> Have you any numbers about the cost to get the content of a flash >> microcontroller if it's "copy protection" is used? For example, we are >> using Freescale 9S08, S12, Coldfire V2 and I could also imagine to use >> a STM32. > >No idea. In the 80's, you could get a "generic" design copied Not a valid comparison. Let's talk about the current flash devices I cited. If you tell me what it costs to get a Flash ROM image from one of these, we can continue the effort / benefit discussion. [...] >Look at how "secure" the various "security technologies" >have proven to be. Look at the tools available to students >in labs nowadays (how long did the XBox's "security" stand >up to "not for profit" attack?). Also not a valid comparison, tha attack is not applicable to flash based devices without external memory. >Relying on schemes to *prevent* copying is a losing battle. As I wrote earlier, I just want to make copying so expensive that it's no more interesting compared to "develop from scratch". Oliver -- Oliver Betz, Muenchen (oliverbetz.de) |