Modelling Watermark Communication Protocols using the CASPER ...

Modelling Watermark Communication Protocols using the CASPER Modelling Language Christian Kraetzer, Ronny Merkel, Robert Altschaffel, Eric Clausing, Maik Schott, Jana Dittmann Department of Computer Science, Research Group Multimedia and Security Otto-von-Guericke-University of Magdeburg, Germany {kraetzer, merkel, schott, dittmann}@iti.cs.uni-magdeburg.de {robert.altschaffel, eric.clausing}@student.uni-magdeburg.de

ABSTRACT

1.

In cryptography it is common to evaluate the security of cryptographic primitives and protocols in a computational model, with an attacker trying to break the primitive or protocol in question. To do so formalisation languages like CASPER or CSP (Communication Sequential Processes) and model checkers like FDR (Failures-Divergences Refinement) are used for automatic or semi-automatic machine-based security verification. Here we transfer the idea of machine-based verification of the security of communication protocols from cryptography to the domain of digital watermarking based media security protocols. To allow for such a mainly automatic verification approach, we introduce and illustrate in this paper a six step procedure for the modelling and verification of watermark communication protocols based on application scenario descriptions. The six steps are: First, a modelling of the used communication network and application scenario (as a task) in XML-structures, second, a path search comparing the network and the task and identifying possible watermarking channels, third, a path selection selecting one watermarking channel from the identified alternatives for the protocol realisation, fourth, an automatic CASPER protocol generation from the selected alternative followed by manual adjustments (if necessary), fifth, the CASPER compilation into CSP and sixth, the protocol security (confidentiality, integrity and authenticity) verification via the FDR model checker.

According to [1] it is common in cryptography to evaluate the security of cryptographic primitives in a computational model, with an attacker trying to break the primitive in question. This security evaluation approach is in cryptography also extended to complete communication protocols, using e.g. formalisation languages like CASPER (see Lowe et al. [2]) or CSP (Communicating Sequential Processes [3]) and model checkers like FDR (Failures-Divergences Refinement; [4]) for machinebased security verification.

Categories and Subject Descriptors I.6 [SIMULATION AND MODELING]: I.6.4 Model Validation and Analysis; E.4 [CODING AND INFORMATION THEORY].

General Terms Design, Performance, Reliability, Security, Verification

Keywords Watermarking, protocol security, CASPER, model checking

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. MM&Sec’10, September 9–10, 2010, Roma, Italy. Copyright 2010 ACM 978-1-4503-0286-9/10/09...$10.00.

INTRODUCTION

In our paper we transfer this idea of machine-based verification of the security of communication protocols from cryptography to the domain of digital watermarking based media security protocols. Authors like [5] employ manual mathematic proofs to ensure security in watermarking based schemes. In contrast to their work we aim for a mainly automatic verification approach. Based on the procedure introduced, the scientific contribution of this paper can be summarised in the following three points: • We introduce a way to describe watermarking application scenarios and communication networks in XML-structures. This XML-based description allows for the automated evaluation of existing communication networks on whether a watermarking channel can be integrated or not by application of classical path search approaches from graph theory. In case it is discovered that no watermarking channel can be integrated in a given network (e.g. because no suitable cover-channels for a given capacity requirement exists or infrastructure requirements like the access to a PKI are not fulfilled) the path search can also indicate how to solve the problems found. • Based on the XML-based descriptions and the output of the path search a methodology for an automated translation of the watermarking protocols into CASPER is given. • After the translation into CASPER a watermarking protocol is compiled automatically into the CSP language. We show how the protocol can then undergo semi-automatic1 security verification by the model checker FDR, considering the confidentiality, integrity and authenticity of the communications.

1

Semi-automatic because sophisticated attacker models so far still need a manual definition of attacker properties and starting knowledge.

Our approach for modelling watermark communication protocols has to face the following restrictions: • The approach requires definitions of watermarking characteristics (transparency, robustness, capacity, etc) which can be easily compared in the path search based evaluations performed in our approach. This is non-trivial problem since in the watermarking domain such comparisons tend to be rather abstract even for simple characteristics. As an example the invertability of a watermarking scheme shall be discussed: in a naïve model this characteristic would be modelled as a binary value – either a scheme is invertible or not. I reality the existence of inversion attacks makes this simple model obsolete. One possible set of definitions that could be applied for our paper is found in the profile based benchmarking approach introduced by Lang in [6]. In his publication all watermarking characteristics are mapped by transfer functions onto a co-domain in the closed interval [0,1] with a value close to 0 indicating the worst case and 1 the perfect case. • Besides the watermarking characteristics our approach also needs a model for the security of the watermarking components. • Infrastructure requirements for the approach (e.g. access to public key infrastructures (PKI) for asymmetric watermarking schemes) need to be modelled for an automatic evaluation. • CASPER constructs agent based communication security models. An agent in the CASPER notation is a communicating entity represented by a CASPER process which can act independently to other entities, send and receive messages, possesses variables and can perform checks. Amongst other drawbacks CASPERs agent based approach limits the number of communicating entities to a well defined set which allows for no dynamic changes of the communication network. • All communication protocols in CASPER are strictly sequential, no parallel tasks and information flows are allowed. • The CASPER notation offers a relatively small and specific number of constructs, which allow only a certain amount of mechanisms to be modelled. An asymmetric key scenario in cryptography can be easily modelled with these constructs while e.g. the embedding by a digital watermarking algorithm needs do be projected by the use of similar constructs since it was not directly foreseen by the authors of CASPER. • The model checker used in the security evaluation (FDR) practically limits the network size that can be evaluated. So far no exact figures exist on how many agents and protocol steps FDR can handle. To find an estimate for those figures in the context of watermark communication protocol modelling is one of our important steps for future work. This publication is structured as follows: Section 2 introduces our modelling and protocol generation procedure. Section 3 describes the network- and task modelling as well as the path search and path selection being the first three steps of the procedure in detail. In section 4 basic concepts employed in CASPER are summarised as a prerequisite for the following section. Section 5 describes, with the protocol generation and adjustment as well as CASPER the compilation and verification using FDR, the steps four to six of the procedure. The paper is completed in section 6 by a summary and indications for future work.

2. MODELLING, PROTOCOL GENERATION AND TEST PROCEDURE In this section we show the procedure for automatically deriving a watermark communication protocol from the (XML-based) descriptions of an application scenario and a network. Figure 1 gives an overview over the procedure as well as the semiautomatic testing of different attacker scenarios. The individual steps in the procedure are described in detail in sections 3 and 5 of this document. Step 1: Network and task modelling XML-files Step 2: Path search

Exit: No path exists

list of solutions (XML) Step 3: Path selection best solution (XML) Step 4a: CASPER protocol generation spl-file Step 4b: CASPER protocol adjustment spl-file Step 5: CASPER compiler CSP-file Step 6: FDR (model check)

Result: Protocol and sec. statement.

Fig. 1: Procedure for watermark protocol generation and verification

The first step in the procedure is the modelling of the application scenario (task) and the network as XML-structures. The second step is a classical path search that determines all paths in the network that fulfil the requirements specified in the task (e.g. capacity, transparency, etc. requirements or the connectivity to required infrastructure like a PKI). The procedure stops at this point with an error message if the path search can not determine at least one suitable path. The output of the path search is returned

in form of a list of solutions in XML. The third step – the path selection – is then used to select one solution for the given task.



The fourth step receives the selected solution as a XML structure and translates it into CASPER notation. Here first an automatic translation is used to generate and translate everything that can be done automatically. Then certain aspects have to be modelled/adjusted manually (e.g. the attacker knowledge, which could be initialised with defaults like Kerckhoffs-compliance or be modelled specific to the application scenario). For details of this translation process see section 5.2 of this document.

5000

After the CASPER protocol description is generated and adjusted it is compiled into CSP in the fifth step of our methodology. The output of the compilation is then verified using the model checker FDR, which returns a statement on the security of the protocol. If the model checker finds no possible attacks against the security aspects required in the application scenario2 then the procedure finishes at this point with a CASPER protocol and a positive security statement. If the model checker finds possible attacks then either the protocol has to be adjusted (back to step 4) or the selected path has to be discarded and the next possible solution has to be evaluated (back to step 3). If necessary this has to be repeated until all identified solutions have been checked.

3. DESCRIPTION OF NETWORKS, TASKS AND PATH SEARCH / SELECTION As a necessary prerequisite this section covers the network and task modelling, the path search and the path selection as the first three steps of the procedure introduced in section 2.

3.1

Network and Task description (step 1)

In step 1 of the introduced procedure for protocol generation (see section 2) the communication network and task have to be modelled. Here we propose, for the sake of clarity and because this data has to be machine parse-able, to use XML structures. A simplified version3 of the used structure is illustrated by the following example:

Alg1 PKI1 …

…

A B

…



Each of the nodes/agents in this structure is specified with an ID (e.g. A), the cover channels it has access to, the watermarking algorithms known to the node (e.g. Alg1) and the node communication throughput in Bit/s (). For the accessible cover channels () the type (in this example a data stream with ID Cover1), the cover channel capacity and the unit it is measured in (here Bit/s). After these required blocks the infrastructure component accessibility would be specified for each node (in the given example the access to a PKI called “PKI1”). Additionally to the nodes in this XML-structure the connections (logical channels ) between the nodes are specified as source/destination tuples. A different XML structure describes the characteristics of the watermark algorithms available. The used structure is illustrated by the following example:





A Cover1 data stream 1000 bps

Alg1 data stream 0 12.5% low high symmetric …

2

Complex application scenarios require multiple model checker runs using different attacker models and –starting knowledge.

3

In our implementations we use XML schemes, which allow the specification of mandatory and optional fields, data types, etc. For the sake of accessibility in this paper we use simplified XML examples.



…

Each watermarking algorithm () is specified by an ID, the cover type it can embed into, the embedding capacity offered (in percent of the cover size), robustness and transparency characteristics (for this example simplified to “low” and “high” respectively, a more comparable description could for example be based on [6]), as well as a key scenario. Other non-security watermarking characteristics which are relevant for the application scenario at hand could be handled the same way. What is still missing in our realisation is the model for the security of the watermarking components introduced as a requirement in section 0. This model is one focus of our future work; nevertheless we would include in our description here some observations on where in the procedure such a model would be required. This model could be included into the watermarking algorithm description and contain information about known vulnerabilities (against attacks), known or estimated security levels, etc. The evaluation of these characteristics could be integrated into two different stages of the procedure shown in figure 1: either in step 2 & step 3 (the path search and selection) or in step 4 & step 6 (the CASPER modelling and FDR checking). Both alternatives have their specific advantages and drawbacks. If the evaluation of the security of the algorithms is included into the path search, like to other watermarking characteristics, then the number of evaluation runs for the FDR would be much lower. If this evaluation is included into the CASPER modelling (as checks) and verification with FDR, then all security evaluations (communication security as well as watermarking security) would be performed as one functional block. In the future work our next considerations will be focussed on this matter. Here we define the terminology which is required for the following processes, especially the path search: A subtask is a specific part of the overall application scenario (or task) of the form “Find a path to transmit data from a source node to a destination node (over a connection of nodes with identical or better characteristics than source and destination) with predefined watermark characteristics and fulfilling the algorithm requirements defined for the watermarking algorithm.” Thereby we basically split the task into blocks (the subtasks) by their functionality or capabilities. The main reason for this division into subtasks is that this allows us to change on processing agents between cover channels and watermarking algorithms. An brief example can illustrate when to split into subtasks and when not: In a simple watermark signature chain where each station either simply forwards the media file or adds its own ID to the watermark already embedded into a media file, a new subtask is generated each time the channel characteristics change (e.g. the capacity required increases by the adding of an additional ID). In this example no new subtask would be generated if an agent just forwards the marked cover without any modifications. Like the network description presented above, the task description given for an application scenario is transformed into an XMLbased structure to allow for an automatic matching against the network/node properties. An example for such a task description is as follows: A B

n 32 …

…



The task is therefore described as a collection of subtasks with a source , a destination and a list of required characteristics (e.g. access to an PKI, capacity, etc).

3.2

Path search (step 2)

In the second step of the procedure a path-finding process using a simple Depth-First-Search algorithm ([7]) is applied to the complete network with all its logical connections to determine all physical paths from the source to the destination node. Subsequently the nodes directly involved in each subtask are checked for a common watermarking scheme, i.e. they are checked for whether they have access to at least one common embedding and extracting algorithm plus the corresponding keys. When a common watermarking scheme is found the search for an adequate cover channel can be initiated. So every node on every found path is checked for available cover channels with the cover type defined by the chosen watermarking scheme. A path that satisfies the subtasks demands (taken from the XML task description) is considered for usage when all nodes on a specific path have knowledge of a matching cover channel with sufficient capacity. Finally it is checked whether the connections between the subtasks and their composition also fulfil the overall task requirements (e.g. the overall channel capacity of a node is not exceeded).

3.3

Path selection (step 3)

The path selection step (as the third step in the procedure) identifies from all found solutions the one which is the most suitable based on a cost function. How to define suitable cost functions have to be derived from the given application scenario is considered here a topic for future research. The path-selection-process returns a XML-structure , showing possible paths of the given network which satisfy the task requirements. An example could look like: 0.8 A B ... Cover1 data stream

ID_A ID IDA Alg1 data stream 0

The protocol description in CASPER is structured into eight well defined blocks. These blocks are named #Free Variables, #Processes, #Protocol Description, #Specification, #Actual variables, #Functions, #System and #Intruder Information. The right order of these blocks is needed for the compiler but is of no importance for the understanding of the protocol modelling process. A very simple example of an agent A sending a message mes to an agent B using a symmetric encryption is given in table 1. Part

Topology

1

#Free Variables

Attack scenario descr.

… yes

A,B : Agent

yes

mes : Message



Skey : Agent → SharedKey

n

InverseKeys = (Skey,Skey)

…

2

SENDER(A,mes) knows Skey

…

REICEIVER(B) knows Skey

…

If there is no block for a computed there is no path in the network fulfilling the given task requirements and therefore no watermarking protocol can be developed. In any other case a separate CASPER protocol representation can automatically be designed for each alternative and different security aspects can be verified. Furthermore, different attacker scenarios defined by the knowledge of the intruder can be simulated. Each alternative consists of several representing the subtasks. For each subtask a is transferred from a node to a node using the watermarking algorithm under the requirements , being routed over the nodes (which do noting else but passing the marked cover on and in no way change it). At least one needs to be present for each alternative.

4.

3

CASPER ([2], [8], [9]) as a protocol modelling tool offers the possibility to represent the design of a protocol in a human- and machine-readable format, which can then be compiled into Communication Sequential Processes (CSP; [10], [3], [9]) notation to be verified by the FDR (Failures-Divergences Refinement; [4]) model checker. If FDR returns a negative statement while running the verification process, a possible attack on the communication scenario is found. With the usage of this procedure, the security aspects of confidentiality, authenticity and integrity of messages communicated in a designed protocol can be evaluated in an automated way.

#Protocol Description 0.

→A : B

1. A→B : {mes}{Skey(A)} 4

#Specification Secret (A, mes, [B])

5

#Actual variables NodeA, NodeB, Trudy : Agent Mes: Message

6

#Functions symbolic Skey

7

CONCEPTS IN CASPER MODELS

In this section we introduce the basic concepts used in CASPER based modelling, the limitations of this language and a description of the modelling and checking process.

#Processes

#System SENDER(NodeA,Mes) REICEIVER(NodeB)

8

#Intruder Information Intruder = Trudy IntruderKnowledge = {NodeA,NodeB}

Table 1: CASPER model of an agent A sending a symmetrically encrypted message to B

In the #Free variables section all the variables (including the agents) used in the protocol are specified together with all functions. The given example specifies two variables A and B which are of type Agent and a data-object mes of type Message. A function Skey is also given assigning an object of type SharedKey to an Agent. A pair of inverse keys need to be specified for each protocol meaning that the two functions specified in brackets

applied to the same identity should return keys inverse of each other. In the current example Skey is inverse to Skey representing a shared secret in a symmetric key scenario. The #Processes section describes the agents participating in the protocol. Each agent is represented by a process (i.e. SENDER, RECEIVER) including a variable of type Agent as input and additional variables (i.e. mes). The keyword knows tells the program which functions and data-objects are known by this process. In the given example both agents know the function which assigns them their symmetric keys. The block #Protocol description represents the communication steps of the protocol, each line representing one step. In our example, agent A is told by the environment about the existence of an agent B in an initialisation step 0. He then sends it's value of mes to agent B in step 1. Before the sending he encrypts it with his key Skey(A). The incorporation of infrastructure mechanisms like a Public Key Infrastructure (PKI) or a Time Server (TS) can be modelled in CASPER in two different ways. The less complex way is to assume that an agent has acquired a timestamp or the public key of a communication partner automatically. In this case he would only add the timestamp as another data item to be transferred to the receiver or respectively use the public key to embed the watermarking message. The second, more complex way, would also allow for the acquisition process of a timestamp or a public key to be checked for security flaws. To do so the acquisition process of a timestamp or a public key would be modelled by using additional agents acting as time- or key-servers. In such a scenario each request to and answer from such a server would be modelled as a separate communication step in the #Protocol description section. Security aspects to be checked are defined in the #Specification section. The keyword Secret in our example states that the message mes is a secret only known to agent A and is in addition only allowed to be known by agent B. If any other agent gains access to this secret during the protocol run this is returned as a possible attack. Another important statement in the #Specification section is of the form Agreement(A,B,[mes]). It can be used for verifying either the entity authenticity4 or the data-origin authenticity regarding the communication partners. In the case of the communication partners being directly connected to each other (with no additional node in between) FDR checks whether A and B completed a protocol run with each other (both agreeing on the value of the transmitted mes) concluding that they are correctly authenticated (here entity authenticity) to each other. In the case of nodes in between A and B forwarding the watermarked cover, CASPER requires all nodes to know each other and checks only if A and B agree on the message mes. In this case, the data-

4

Entity authentication in this context means that a message received is proven to be coming directly from the claimed entity (in our case a specified agent) whereas data-origin authenticity only verifies that the message originated from the specified agent (but could be relayed, delayed, replayed and/or routed over a man in the middle).

origin authenticity is validated stating that agent A was once the originator of this message. In the #Actual variables block certain values are allocated to the variables, i.e. NodeA is the specific value of the variable A. A possible intruder also needs to be specified here for the first time. The functions can be either explicitly defined in the #Functions section or, if no precise definition of the return value is needed, be represented as a symbolic function (as seen in the example). In the #System block the specific values of the variables given in this scenario are handed to the agents. The block #Intruder Information defines the intruder and his knowledge. In the given example - according to Kerkhoff's law - he has all the knowledge except the secret key and the message (which is explicitly defined as being secret in the #Specification block). By changing the information specified in the eight CASPER blocks, different topologies as well as different attacker scenarios can be defined. In our approach the topology of the network is given by the network and task description of the application scenario (see section 3) and therefore only the different attacker scenarios for the selected network paths need to be evaluated. By changing the #Specification block, different security aspects can be checked, while by changing the #Intruder information, different attacker scenarios can be modelled.

5. CASPER BASED WATERMARK MODELLING Based on the procedure introduced in section 2, the first three steps introduced in section 3 and the prerequisites on CASPER presented in section 4, this section addresses the steps 4 to 6 of the procedure. We show how to automatically transfer possible paths identified in section 3 into a CASPER notation for the evaluation of selected security aspects.

5.1 Simulating a watermark message and watermarking algorithms in CASPER Since CASPER at this point offers no special constructs for representing digital watermarks and the corresponding embedding and retrieving functions, an approximated representation needs to be developed from the given constructs. We therefore assume that an agent embeds a message mes with an (optional) overhead oh (which might be needed for certain watermarking schemes, i.e. in hierarchical watermarks) into a cover cov using a given watermarking algorithm. By sending the message, the overhead and the cover object as three different items to the receiving agent, the transfer of the watermarked cover is emulated in CASPER. The receiver then assumes the message overhead and the cover to be the result of (an emulated) extraction process. This very simple approximation shows similar properties than a real watermarking scheme: A possible intruder can only be prevented from accessing the watermark message by the usage of a key for embedding. This can be approximated in CASPER by the encryption of the watermark message and the overhead by this key. An intruder now still has access to the cover object (since it is not encrypted in our emulation) but he can not read the

watermark message or the overhead. Similarly, a non-invertible watermarking scheme can be emulated by sending a changed cover (new cover variable) to the receiver. In this case a reconstruction of the original cover during the detection process won't be possible. To extend our example from section 4 from sending a simple message from A to B to sending an invertibly watermarked cover producing an overhead we have to add a variable oh to represent the overhead created by the embedding algorithm and a cover cov to the model. We also change the #Protocol description block by using the symmetric key the agents know already to encrypt the message and the overhead since they are embedded with a key and not extractable without it:

#Free Variables .,.,. : Agent . : . . : . _skey : Agent → SharedKey InverseKeys = (_skey,_skey) #Processes SENDER(.,.,.) knows _skey RECEIVER(.) knows _skey FORWARDER1(.) #Protocol Description

A→B : {mes,oh}{Skey(A)},cov To check for specified security aspects the #Specification block is used. Unfortunately the set of constructs given by CASPER for this purpose is very limited. We can use the Agreement construct to make sure that A and B agree on the value of a given message to test either the entity authenticity (if they are directly connected to each other) or the data-origin authenticity (if they are not directly connected to each other). Using the #Specification constructs of CASPER we can also model other security aspects such as keeping the embedded watermark confidential by using the Secret construct. The specific terms used for verifying the security aspects of confidentiality, authenticity and integrity using watermarks are given in section 5.3.

5.2 Automated CASPER modelling using XML-input (step 4a) As the fourth step in the procedure for protocol generation we can model a CASPER protocol in an automated way from the specific tasks and networks given. For that purpose we use the block returned by the path selection in step three. In the examples in this paper we show the translation of an block of a given which contains exactly one . Each additional can be modelled in a way which is similar to the one given with a few additional adjustments. I.e. some variables or functions might have been specified already in former blocks and therefore do not need to be specified again. Each additional can be modelled in exactly the same way as described, each producing a new CASPER model. Table 2 shows the first part of a template for the translation of our example consisting of one . Please note that we use here a . notation to address certain tags within the XML-structure, which is the input of the translation. So if we refer to . the ID of a message is returned, if . is referred, the data type of the message is retuned.

0. →. : .,. 1. →. : . 2..→. : {.}{_skey(.)}%temp,< Cover>. 3..→. : temp%{.}{_skey(.)},< Cover>. Table 2: Template for the transformation of one into CASPER notation – part 1

The CASPER code generated follows the structure described in section 4. The names and types of used variables are translated from the block of the XML-representation. In our example an invertible blind watermarking scheme is modelled sending the cover together with the encrypted watermark (simulating the being embedded state) from the source to the destination node, routing it through one untrusted computer. The watermarking algorithm is not producing any overhead in the example. Furthermore a symmetric key is used for embedding and extracting. The translation template can be easily extended by optional components such as an overhead (produced by the watermarking algorithm ), another variable for the changed cover (if a non-invertible watermarking algorithm is used), an arbitrary number of additional routing computers or the application of a watermarking scheme using asymmetric keys. It is to note that for the design of the CASPER protocol only the blocks #Free variables, #Processes and #Protocol Description need to be translated from the XML-representation (as shown in table 3). The #Actual variables, #System and #Functions sections are then derived from the information given in these blocks: #Actual variables Node1,Node2,Node3,Trudy : Agent Variable1 : . Variable2 : . #System SENDER(Node1,Variable1,Variable2) RECEIVER(Node2) FORWARDER1(Node3) #Functions symbolic _skey Table 3: Template for the transformation of one into CASPER notation – part 2

Besides the derivation from the #Free variables, #Processes and #Protocol Description blocks, there is also the possibility to specify the values of variables directly in the solution block of the XML-representation, e.g. in the . tag. Having specified these first six CASPER blocks in a completely automated way, the topology of the given network path is modelled successfully.

5.3

CASPER model adjustment (step 4b)

In step 4b of the procedure different attacker scenarios can be introduced to be verified in step 6 using FDR. For this purpose the #Intruder information block is used to specify the knowledge of a possible attacker and the #Specification block to represent the security aspects to be checked. The #Intruder information block can be automatically created giving the intruder a standard set of knowledge. This could be - according to Kerkhoff's law - all the information which is not explicitly specified as secret or a key not supposed to be known by the intruder. Also other possible scenarios could be specified here, i.e. a case where the intruder learned a secret key by means of social engineering: #Intruder Information Intruder = Trudy IntruderKnowledge = {Node1,Node2,Node3,Trudy,Variable1}

For verifying the authenticity of a sender by means of watermarking, the message embedded by (i.e. the ID of the source node) needs to match the extracted message at . For this purpose the Agreement statement of CASPER is used. In case that the communicating agents are directly connected to each other, the entity authenticity can be tested. In case they are indirectly connected to each other (for example with forwarding nodes in between) the data-origin authenticity can be checked. The Agreement statement is the same in both cases, checking if and agree on the watermarking message representing the ID of the sender: #Specification Agreement(,,[]) Table 6: Template for the transformation of one into CASPER notation – part 4 – specification block

Verifying integrity is quite similar to verifying authenticity. Using the same Agreement construct it only needs to be specified which parts are to be checked for integrity from the mere message (similar to verification of authenticity) to the overhead or even the cover: #Specification Agreement(,,[]) Agreement(,,[]) Agreement(,,[])

Table 4: Template for the transformation of one into CASPER notation – part 3

Table 7: Template for the transformation of one into CASPER notation – part 4 – specification block

In the given example Trudy does not know _skey because he doesn’t have the symmetric key. Whether he has knowledge of the message specified by Variable2 or not is dependent on whether the message is specified to be secret in the #Specification block or not. It is to note that the watermarking algorithm is assumed to be always known by the Intruder in our model. If the Intruder can learn the secret key, he can decrypt the message transferred which would be similar to extracting the watermark, this leads to a possible attack shown by CASPER.

It can be seen in the given design of the verification statements that verifying data-origin authenticity is a subset of verifying integrity. This is indeed true because verifying the data-origin authenticity with the help of watermarking schemes is identical to verifying the integrity of the authenticity information given in the watermark. In case a network offers different possible to fulfil a given task, each alternative can be modelled and checked with CASPER and FDR, making the best choice concerning not only the quality by some abstract quality function, but also security.

The security aspects to be checked are defined in the #Specification section of the CASPER programme. They can be given in an XML-block, manually specified or set to a default value. Security aspects can be checked either for a complete alternative or a single step. In the former case the verification of a security aspect is given for the complete path through the network from sender to receiver, even if the watermarking algorithm or cover is changed or if additional information is embedded. In the latter case only one subtask is checked representing a watermark being transferred from one trusted computer to another one using the same watermarking scheme and cover and nothing is extracted or added on the way. For verifying the security aspect of confidentiality, the Secretstatement can be used to test if the embedded message is a secret between the source and the destination node: #Specification Secret(,,[]) Table 5: Template for the transformation of one into CASPER notation – part 4 – specification block

5.4 Compilation into CSP (step 5) and checking with FDR (step 6) After compiling the CASPER source code into CSP it can be checked using FDR. In our example the confidentiality is to be checked using the secret-statement: Secret (A, mes, [B]) In case there are no flaws in the protocol concerning the confidentiality of the message transmission, FDR answers “No attacks found”. In this case we can assume that no attack is possible in the given system under the given assumptions. As mentioned already depending on the application scenario it might be of importance to test several different attacker scenarios which could occur as well as different security aspects. To show a possible attack on our example protocol we change the intruder knowledge. In this attacker scenario the intruder has learned the secret key, i.e. by social engineering: IntruderKnowledge = { … ,Skey} FDR now reports a possible attack on the protocol:

Top level trace:

The error message of FDR shows a typical “Man-In-The-Middle” attack on a possible watermarking protocol. Even if the attacker (Trudy) cannot change the watermark itself (as the data-origin authenticity has been verified before) Trudy can still conduct a replay attack by delaying or resending the watermarked cover.

NodeA believes Mes is a secret shared with NodeB

6.

Checking assertion SECRET_M::SECRET_SPEC [T= SECRET_M::SYSTEM_S Attack found:

The intruder knows Mes System level: CASPER> 0.

->

NodeA

: NodeB

1. NodeA -> I_NodeB : {Mes}{Skey(NodeA)} The intruder knows Mes Table 8: Example FDR output in case of a possible attack (known secret key)

The output shows that a possible intruder Trudy can intercept the message from A to B by claiming to be B (represented by the term I_NodeB) and with the knowledge of the secret key is now able to retrieve the content of the message. Also the data-origin authenticity of our example can be checked with the corresponding Agreement statement (Trudy not knowing the key): Agreement(,,[]) FDR responds with “No attacks found” stating that the data-origin authenticity is verified. However, by establishing a direct connection between A and B (by excluding the forwarder) FDR can now also evaluate the entity authenticity resulting in the following error: Checking assertion AUTH1_M::AuthenticatePROCESS1ToPROCESS2Agreement_ Mes [T= AUTH1_M::SYSTEM_1 Attack found: Top level trace: Node2 believes (s)he has completed a run of the protocol, taking role PROCESS2, with Node1, using data items Variable2 System level: Casper> 0.

→ Node1 : Trudy

1.Node1 → I_Trudy : {Variable2}{Alg1Skey(Node1)}, Variable1 1.I_Node1 → Node2 : {Variable2}{Alg1Skey(Node1)}, Variable1 Done Table 9: Example FDR output in case of a possible attack (man-in-themiddle)

SUMMARY AND CONCLUSIONS

In this paper we transfer the idea of machine-based verification of the security of communication protocols from cryptography to the domain of digital watermarking based media security protocols. The three main contributions of this work are: a) a method for describing watermarking application scenarios and communication networks in XML-structures for the automated evaluation on whether a watermarking channel can be integrated or not, b) a methodology for the automated translation of the watermarking protocols into CASPER notation, and c) an indication on how the protocol then can undergo semi-automatic security verification by the model checker FDR, considering the confidentiality, integrity and authenticity of the communications in the protocol. To achieve these results we introduce and illustrate a six step procedure for the modelling and verification of watermark communication protocols based on given application scenario descriptions. Further work in this field should include research on the following topics: • The path selection step (as the third step in the procedure) identifies from all found solutions the one which is the most suitable based on a cost function. A procedure for modelling appropriate cost functions in dependency of the goals of the application scenario has to be specified. • Integration of the model for the security of the watermarking components (see section 3.1). • To overcome some of the limitations of CASPER identified, appropriate language constructs might be added to this language and compiler (for which the Haskell source code is available) to facilitate the application in modelling watermarking protocols instead of cryptographic protocols. • The model checker used (FDR) practically limits the network size that can be evaluated. So far no exact figures exist on how many agents and protocol steps FDR can handle. The identification of these figures would be necessary for allow for any generalisations on the scaling behaviour of the approach. • If the result of the security evaluation by FDR is negative (possible attacks have been found) the output of the verification process can be used to harden the protocol. Methods for the automatisation of this process are still required.

ACKNOWLEDGMENTS The effort for this publication was in part sponsored by the Air Force Office of Scientific Research, Air Force Material Command, USAF, under grant number FA8655-09-M3061. The U.S. Government is authorized to reproduce and distribute reprints for Government purpose notwithstanding any copyright notation thereon. The views and conclusions contained herein are those of the author and should not be interpreted as necessarily representing the official policies or endorsements, either

expressed or implied, of the Air Force Office of Scientific Research or the U.S. Government.

REFERENCES [1] S. Katzenbeisser: Computational Security Models for Digital Watermarks. In Workshop on Image Analysis for Multimedia Interactive Services (WIAMIS 2005), 2005. [2] G. Lowe: CASPER: A Compiler for the Analysis of Security Protocols. Journal of Computer Security, Society Press, 1998. [3] A. W. Roscoe: Model-checking CSP. In A classical mind: essays in honour of C. A. R. Hoare, Prentice Hall International (UK) Ltd., 1994. [4] FDR user manual. Formal Systems (Europe) Ltd.. http://www.fsel.com/documentation/fdr2/html/ [5] J. Dittmann, S. Katzenbeisser, C. Schallhart, H. Veith: Ensuring Media Integrity on Third-Party Infrastructures. In 20th IFIP International Information Security Conference (SEC2005), Springer, 2005.

[6] A. Lang: Audio Watermarking Benchmarking – A Profile Based Approach. PhD Thesis. Otto-von-Guericke-University Magdeburg, Germany, Dept. of Computer Science, ISBN: 978-3-940961-22-8, 2007. [7] T. H. Cormen, C. E. Leiserson, R. L. Rivest, and C. Stein: Introduction to Algorithms. 2nd ed. MIT Press and McGrawHill, ISBN 0-262-03293-7. Section 22.3: Depth-first search, pp. 540–549, 2001. [8]

G. Lowe, P. Broadfoot, M. L. Hui: CASPER - A Compiler for the Analysis of Security Protocols. User Manual and Tutorial, Version 1.5, Oxford University Computing Lab, December, 2001.

[9] P. Ryan, S. Schneider, M. H. Goldsmith: Modelling and Analysis of Security Protocols. Addison-Wesley Professional, ISBN-13: 978-0201674712, 2000. [10] C. A. R. Hoare: Communicating Sequential Processes. Prentice Hall International, 2004.