A Functional Taxonomy for Software Watermarking Jas Nagra

  • Slides: 17
Download presentation
A Functional Taxonomy for Software Watermarking Jas Nagra, Clark Thomborson University of Auckland Christian

A Functional Taxonomy for Software Watermarking Jas Nagra, Clark Thomborson University of Auckland Christian Collberg University of Arizona 1

Why Build a Taxonomy? The first step in wisdom is to know the things

Why Build a Taxonomy? The first step in wisdom is to know the things themselves; this notion consists in having a true idea of the objects; objects are distinguished and known by classifying them methodically and giving them appropriate names. Therefore, classification and name-giving will be the foundation of our science. Carolus Linnæus, Systema Naturæ, 1735 (from Lindqvist and Jonsson, “How to Systematically Classify Computer Security Intrusions”, 1997. ) 30 January 2002 2

Software Watermarking Watermark: “Copyleft …” Unprotected Software Watermarking Process ¨ Authorship, Copyright ¨ Ownership

Software Watermarking Watermark: “Copyleft …” Unprotected Software Watermarking Process ¨ Authorship, Copyright ¨ Ownership ¨ Validity ¨ Licensed Uses 30 January 2002 Watermarked Software Copyleft … Recognisable mark; no change to function. 3

Taxonomy by Technology ¨ Static software watermarks: either in – Data (e. g. const

Taxonomy by Technology ¨ Static software watermarks: either in – Data (e. g. const string “Copyright …”) or in – Code (e. g. ordering of basic blocks). – Static SW watermarks are recognisable by a static analysis, e. g. grepping for strings. The recognition may involve cryptography. ¨ Dynamic software watermarks: – I/O behaviour (Copyright notice; “Easter Egg”), – Data structure, or – Execution trace (opcodes, addresses, …). 30 January 2002 4

Easter Eggs ¨ A special I/O sequence (a “secret key”) reveals the Egg: a

Easter Eggs ¨ A special I/O sequence (a “secret key”) reveals the Egg: a recognition system is distributed with the watermarked software. ¨ They’re fun to hide and to hunt. ¨ The hiding process is a security concern, as are the Eggs. ¨ See www. eeggs. com 30 January 2002 5

Goals of our Taxonomy ¨ Names should be – Precise // Concise // Already

Goals of our Taxonomy ¨ Names should be – Precise // Concise // Already familiar; ¨ Classification tree should be – Complete & unambiguous; – Well-balanced (not many criteria); and – Useful to (Technologists // Lawyers) (Experts // Novices). Two of our goals are internally contradictory, so we won’t find an optimal solution! 30 January 2002 6

Ambiguity of “Watermark” ¨ Should a watermark be visible to end-users? – Yes [Kaplan

Ambiguity of “Watermark” ¨ Should a watermark be visible to end-users? – Yes [Kaplan 1996] – Not usually [Lacy, Quackenbush, Reibman & Snyder 1998] – In some applications [Cox & Linnartz 1998] – No [Miller, Cox, Linnartz & Kalker 1999] – Yes, if it’s a “visible watermark”; no, if it’s an “invisible watermark” [Kutter & Hartung 2000] ¨ Our technological taxonomy has focussed our attention on technical detail (how it works) rather than on design goals (what it’s supposed to do). 30 January 2002 7

Ambiguity of “Watermark” (cont. ) ¨ Should a watermark be robust (survive common transformations

Ambiguity of “Watermark” (cont. ) ¨ Should a watermark be robust (survive common transformations such as copying, moving to a different location, compression)? – Yes [Kutter & Hartung 2000] – Yes or no, depending on the application [Miller, Cox, Linnartz & Kalker 1999] ¨ Carelessly drafted laws might forbid (or require) us to destroy (or preserve) any watermark used for “digital rights management”! ¨ The absence of robustness does not guarantee fragility!! 30 January 2002 8

Robustness and Fragility 1. List of Transformations: 1. Copying within a protection domain 2.

Robustness and Fragility 1. List of Transformations: 1. Copying within a protection domain 2. Copying into another domain 3. Deriving a substantially-similar work 4. Copying a short excerpt 2. A robust watermark will survive any transform with a small number. 3. A fragile watermark will be destroyed by any transform with a large number. 4. Some watermarks are neither fragile nor robust! (For example: WMs destroyed by some “class 1” transforms, but surviving some in class 4. ) 30 January 2002 9

Resolution of the Ambiguities ¨ Should a watermark be visible to end-users? – Yes,

Resolution of the Ambiguities ¨ Should a watermark be visible to end-users? – Yes, if it’s an assertion (e. g. of copyright or authorship) or an affirmation (e. g. of authenticity). – No, if its purpose is to permit or prevent an unauthorised use. ¨ Should a watermark be robust? – Yes, for affirmations and preventions. – No, for assertions and permissions. 30 January 2002 10

Types of Software Watermarks ¨ Visible robust watermarks: useful for assertion (of copyright or

Types of Software Watermarks ¨ Visible robust watermarks: useful for assertion (of copyright or authorship) ¨ Invisible robust watermarks: useful for prevention (of unlicensed use) ¨ Visible fragile watermarks: useful for affirmation (of authenticity or validity) ¨ Invisible fragile watermarks: useful for permission (of licensed uses). 30 January 2002 11

Authorship Marks (Assertion) ¨ An assertion of authorship, and its related copyright and moral

Authorship Marks (Assertion) ¨ An assertion of authorship, and its related copyright and moral rights, can be made in what we call an “Authorship Mark”. ¨ Visibility is desired, otherwise the end-user won’t be given notice. ¨ Robustness is desired, otherwise the authorship mark would not be present in a substantially similar work. 30 January 2002 12

Fingerprint Marks (Prevention) ¨ A publisher, distributor or other agent of the author might

Fingerprint Marks (Prevention) ¨ A publisher, distributor or other agent of the author might embed a unique “fingerprint mark” on each copy they sell or license. ¨ Fingerprints should be robust, ideally surviving even in modestly-sized excerpts. ¨ Fingerprints should be invisible, otherwise they will be easily removed by pirates, and they may annoy the end-user. ¨ Fingerprints will prevent unauthorised use, when suitable detection & response systems are in place. ¨ Used in the “Content Protection System Architecture” proposal from 4 C Entity. 30 January 2002 13

License Marks (Permission) ¨ Fragile marks, which are destroyed or suitably modified whenever a

License Marks (Permission) ¨ Fragile marks, which are destroyed or suitably modified whenever a copy is made, allow us to design a system that permits licensed use. For example: an object with a “copy-2” mark can be transformed into two objects with “copy-0” marks. ¨ License Marks are most useful in conjunction with Fingerprint Marks: the Fingerprint Mark indicates what sort of License Mark is required. ¨ License Marks should be invisible, so that they may resist attacks by pirates. ¨ LWMs (License Watermarks) are used with FWMs (Fingerprint Watermarks) in the Content Protection for Recordable Media proposal from 4 C Entity. 30 January 2002 14

Validity Marks (Affirmation) ¨ Visible, fragile marks can affirm, to the end- user, that

Validity Marks (Affirmation) ¨ Visible, fragile marks can affirm, to the end- user, that the software has not been modified in any important way since manufacture. ¨ VWMs for software typically designed to be fragile except for verbatim copying; a single-bit change will invalidate the VWM. ¨ Cryptographic signature algorithms are used to implement VWMs in Java and in Microsoft’s Authenticode. 30 January 2002 15

A Fifth Function? ¨ Any watermark is useful for the transmission of unrelated information

A Fifth Function? ¨ Any watermark is useful for the transmission of unrelated information (espionage, humour, …). 30 January 2002 16

Our Functional Taxonomy Goal: “… wisdom … by classifying [watermarks] methodically and giving them

Our Functional Taxonomy Goal: “… wisdom … by classifying [watermarks] methodically and giving them appropriate names. ” 30 January 2002 17