The architecture defining software watermarking approaches is characterized by a watermark W embedded into a program P in such a way that W can be reliably located and extracted from P, even after P has undergone semantics-preserving transformations such as code optimization and obfuscation. The watermark W should be stealthy, have a high data rate, and not affect the performance of P. Additionally, it must be demonstrated that the presence of W in P is a result of deliberate actions (Collberg and Thomborson, 1998; Thomborson et al., 2004).

The software watermarking architecture is driven by the implementation of the embedding and extraction functions, denoted as I(·) and E(·), respectively.⁵ The embedding is featured by P′=I(W,P,k), where I(·) inputs are the watermark W, the program P, and the program's owner cryptography secret key k. As a result, the watermarked version of the program, denoted as P′, is obtained. The extraction function, on the other hand, is featured by W′=E(P′,k), where W′ is the watermark extracted from P′. For the final assertion, ownership or lack of tampering is proven if both watermarks are similar enough, according to W≡W′. The operator ≡ considers inconsistencies in detection due to benign operations or attacks that do not impact software performance or the watermark recognition.

Software watermarking techniques can be classified into two categories: static and dynamic. Static techniques embed the watermark directly into the software's static artifacts, such as its source code, compiled binary, data files, or the application executable itself. There, the watermark remains as part of the software regardless of whether it is running or not. On the other hand, dynamic watermarking techniques store the watermark in the program execution state (Wu et al., 2024). Dynamic watermarks can be processed, verified, or executed during the runtime of the software or application. They are tied to the behavior or state of the application as it operates (Pieprzyk, 1999; Dey et al., 2019). Table 1 resumes the differences between dynamic and static software watermarking.

According to Collberg and Thomborson (1998), there are three types of dynamic software watermarking approaches: (i) Easter egg watermarking, (ii) data structure watermarking, and (iii) execution trace watermarking. Easter egg watermarking is based on activating a code fragment when the application is run using an unusual input. As a result, the software performs an action immediately perceptible to its users, such as displaying a copyright message, which makes the watermark's presence evident. On the other hand, data structure approaches are based on embedding the watermark in a specific program state, which is obtained when a particular input sequence is used. In this approach, the watermark is extracted by examining the current values of the variables after the input sequence has ended. The extraction can be done using a dedicated watermark extraction routine linked to the executing program or by running the program under a debugger. Given that no output is ever produced, it is not evident to an adversary when the special input sequence has been entered. Finally, execution trace approaches embed the watermark into instructions and/or addresses, as the program is run with a particular input. In that case, the watermark is extracted by monitoring (statistical) properties of the address trace and/or the sequence of operators executed.

This research aligns with dynamic software watermarking, particularly dynamic data structure watermarking, as it proposes an approach that generates and validates watermarks as part of the software's runtime behavior to verify the authenticity of input parameters for functions. Since static watermarking requires embedding the watermark in the source code or compiled software itself, which does not contribute to solving the targeted problem, it is excluded from this work.

When designing a software watermarking approach, certain conditions must be fulfilled, regardless of whether the technique is static or dynamic. As previously mentioned, the watermark W must be embedded into the program P, ensuring its detectability despite benign operations such as code optimization and obfuscation. Besides detectability, other requirements must be fulfilled, such as stealthiness and a high data rate Ma et al., (2019). These are all requirements that work in favor of the watermarking tradeoff between data rate (or capacity), robustness, and stealthiness (or imperceptibility) (Cox et al., 2007; Pérez Gort et al., 2021). It is paramount to avoid collusion with the program performance by ensuring that the watermark does not alter its size or significantly impact its execution time (Alitavoli et al., 2013; Kumar et al., 2015).

In addition to the above requirements, this research also considers the blindness property, which applies broadly to watermarking irrespective of the protected digital asset. A watermarking technique is blind if the watermark extraction does not require access to either the original (unwatermarked) content or the watermark payload itself (Halder et al., 2010; Pérez Gort et al., 2017). Techniques lacking this property are non-blind. Ensuring blindness reduces the risk of unauthorized detection or removal, because the detector does not need to store or transmit the original content or embedding materials, thereby lowering the likelihood of sensitive information leakage.

Despite the requirements, watermarking techniques must guarantee resilience against attacks aiming at removing the watermark to allow adversaries to claim software ownership or perform tampering without being noticed. According to the related literature, some of the more relevant attacks are Myles and Collberg (2006) and Dalla Preda and Ianni (2024):

Other attacks have been defined as particular implementations or extensions of the previously mentioned ones Dey et al., (2020). For example, local modification attacks modify the code similarly to how watermark insertion is performed. Thus, it can be defined as a refined version of a distortive attack. The code reordering attack modifies the code by reordering large independent pieces of it. The code addition attack works by adding a piece of code to the program that should either not be executed or do nothing, thereby preserving the program's functionality. Additionally, the code decompilation attack involves decompiling and recompiling the code. In contrast, the code compression attack modifies the code using compression tools, reducing the code size and adding a decompression routine to it (Stern et al., 2000).

Other attacks are more focused on targeting the engines used for watermark identification. This is the case of the recognition attack, focused on modifying or disabling the watermark detector to obtain misleading results (Chroni and Nikolopoulos, 2011). There is also the protocol attack, which describes cases where the owner lacks complete security over the choice of the recognition (or extraction) engine and the secret keys involved in the watermark synchronization.⁶ In such cases, the adversary can proceed by using a fake secret key that purports to prove the existence of his watermark in the unmodified program using the program owner's recognition function (Collberg et al., 2007).

Some attacks focus on the type of watermarks. For example, fingerprinting approaches, which mark different copies of the same asset with distinct watermarks, must be resilient to collusion attacks. They are based on combining non-intersecting parts of different copies of the same digital asset, to make it impossible to recognize any of the watermarks embedded in each copy (Dalla Preda and Pasqua, 2019).

Increased resilience to attacks can be achieved by increasing watermark capacity. However, this can compromise its imperceptibility and provoke he technique to interfere with the software's correct functioning. No single technique can guarantee robustness to all attacks. Instead, better results can be obtained by combining different security approaches simultaneously (Bender et al., 1996; Collberg and Thomborson, 1998). Regarding watermarking, the best possible results can be achieved by creating a technique that can withstand the attacks expected in the scenario in which it will be used.

Dynamic data structure watermarking requires setting up the program in a way that allows specific values representing the watermark to be computed at runtime. These computations are triggered only under specific execution conditions, such as certain inputs or execution paths. The watermark is encoded into the control or data flow, which often requires the insertion of new functions or procedures, additional data structures, or conditional logic to hide and trigger watermark behavior. Although the watermark is revealed dynamically during execution, setting up that watermark requires injecting code. This can be improved if the injected code is done in a stealthy or obfuscated manner. Generally, the modifications made to the program code are non-trivial, as they are designed to be challenging to detect and remove. Considering this, a general description of the architecture of data structure dynamic software watermarking techniques is depicted in Figure 1.

In Figure 1, P represents the program acting as a carrier. Inside P, the block named “Watermark Encoding” represents the scattered code injected and obfuscated to build W after a particular set of inputs I is given to the program. Notice that in this case, we model the secret key k as part of I, which is not necessarily always the case.

After P is executed, the Controller, considered an external application, accesses the memory and tries to detect W from it. Finally, a secret code computed using the detected watermark is compared with the one expected to be generated for the correct input, and a final assessment is provided regarding the integrity and authenticity of I.

The architecture of the approach proposed in this work is built based on dynamic data structure watermarking. In this case, the Controller is embedded in the program P as scattered and obfuscated code. Since the main goal is to validate I for the function F, P can be stored and deployed in a more secure environment. Nevertheless, this is not a requirement.

The logic of the Controller is placed between the “Watermark Encoding” logic and F execution. After an outcome is obtained, if the secret code built with the detected watermark matches the expected value (i.e., the parameters are considered authentic), the process flow is given to F with the input set I. This call is denoted F^I. On the contrary, if the parameters are considered non-authentic, alternative processing is performed, either by ignoring F call or by passing other parameters to it to indicate the required alternative processing. This stage for F calling is defined as F^ϕ. The entire architecture of this approach is depicted in Figure 2.

In this work, the watermark is built based on the principles introduced in Collberg and Thomborson (1998). Based on the premise that W is a set of mathematical structures, and p a predicate such as ∀w ∈ W:p(w), we need to choose p and W such that the probability of p(x) for a random x∉W is small. Thus, p is typical for W, but atypical outside of it. An example to illustrate the selection of W and p is considering W to be the set of even numbers from 1 to 100 (formally, W = {x ∈ ℤ⁺|1 ≤ x ≤ 100∧x mod 2 = 0}), and p(x) the predicate “x is divisible by 2”. Considering that, after picking a random value x ∈ {1, ..., 100}, if x is odd, p(x) is false. Thus, p is rare outside W.

Although W can be embedded in the topology of any data structure built dynamically in the memory, graphs are particularly a good choice, considering that code that manipulates dynamic graph structures is hard to analyze due to pointer aliasing effects. Due to this, semantics-preserving transformations that make fundamental changes to a graph are more complex to construct Collberg and Thomborson, (1999).

One of the advantages of targeting high-level programming languages is that there is high coverage to pass values in I that will contribute to the creation of W. Every object can be dynamically created and stored on the heap, and references can be used to develop pointer-like structures. The defined references can be traversed similarly in a graph or another structure storing a different representation of a predefined graph, such as a linked list. This work applies steganography principles to hide in I the values that will trigger the dynamic construction of W. Formally, I is composed of a set of input parameters i_l:l ∈ [0, |I|), along with the secret key k.

The construction of the proposed approach requires adjusting to the highest possible level of abstraction, resorting to using references and objects instead of raw pointers and memory, utilizing custom classes to simulate nodes and graphs, among other strategies. All watermarking functionalities embedded into the program must be integrated and dispersed throughout the main logic of the code. Further robustness can be added by obfuscating the code. Nevertheless, higher resilience must be focused on the data structure in memory that stores the watermark.

The parameter authentication approach uses the watermark to verify the authenticity of input parameters, essentially treating the watermark as a covert integrity check. It utilizes a hidden heap-based watermark graph that is only constructed when the program receives the correct input parameters. Later, the program can: (i) decode the watermark at runtime, (ii) verify that the decoded value matches the expected ones, and (iii) proceed only if the input is considered authentic due to the triggering of the correct watermark.

An important feature of the watermark encoding is the addition of fake values into I. They are called “fake”, considering that they do not originally belong to I but are introduced to support the construction of the watermark. If these values are not contained in the set of parameters, the instance of I is reported as non-authentic, considering that the correct watermark cannot be reconstructed. The fake values constitute watermark hints, which are initially computed from the binary notation of a secret integer code ζ (denoted by ζ₂) that represents the watermark in numeric format. Next, ζ₂ is used to build Π, which is scattered into I using the secret key k to guarantee the synchronization whenever extraction is required. Finally, when the program receives the parameters, the fake values are extracted from I to rebuild Π and get the code for checking the authenticity of I by building the watermark and comparing it with the original one.

There are different alternatives to synchronize the watermark hints Π in I. The most appropriate choice depends on the data types present in I and the design priorities of the system architecture. Priorities can focus on making hints unnoticeable or ensuring their preservation despite updates to parameter values, which in fact transitions from steganography to watermarking principles Katz et al., (1996); Barán et al., (2001). Nevertheless, our proposal focuses on making the presence of hints unnoticeable, since any change made to the input parameters must compromise the hints so that tampering can be detected. Some of the alternatives to implement the hints synchronization are: (i) positional (index-based) encoding (Katzenbeisser and Petitcolas, 2016), (ii) value modification based on less significant bit (lsb) encoding (Cox et al., 2008), (iii) spread spectrum embedding (Barni et al., 2001), (iv) statistical property encoding (Sion et al., 2003), and (v) redundant data slot (Provos and Honeyman, 2003).

We use the case of a function receiving an array of integers to model and validate our approach. We implement the hints synchronization using lsb encoding based on difference expansion (Gupta and Pieprzyk, 2009). This approach guarantees high capability for the hints encoding as well as reversibility, which ensures that once the hints are extracted, the parameters are restored to their original values. Consequently, if the parameters are considered authentic, the function can proceed to compute an authentic result that is not affected by the presence of the watermarking mechanism.

A more detailed description of the approach is provided below, outlining the procedures that define the watermark encoding and the controller. Algorithm 1 defines the watermark encoding, using as input the secret key k, the input set I, and the length of the secret code's binary notation ζ₂ (denoted by η). First, it uses k to compute a seed utilizing a pseudo-random number generator implemented by the function PRNG(·) (see line 1). Then, the seed is used by the function KEYED_PERMUTATION(·) to produce a permutation of the ⌊|I|/2⌋ disjoint pairs in I, which determines the pair order for difference expansion (see line 2). The function returns the keyed deterministic permutation index list ℙ={pi∈ℤ+|0≤i<⌊|I|/2⌋}. The permutation is reproducible for the same inputs to KEYED_PERMUTATION(·), unpredictable without the seed, and aligns with deterministic pseudorandom function (PRF)-driven derivations in cryptographic standards (Barker and Kelsey, 2012; Pornin, 2013).

After obtaining the permutation index list ℙ, we proceed with the detection and extraction of the hints from I to assemble Π. This is done by the function HINTS_DETECTION(·) that takes as input I, and ℙ (see line 3). Notice that for the synchronization to be successful, the same permutation had to be used to embed the hints into I. Nevertheless, as previously mentioned, as long as KEYED_PERMUTATION(·) is used with the same parameter values, this is guaranteed.

Algorithm 2 breaks down the logic of HINTS_DETECTION(·). It takes as input the parameters described above and returns an ordered hint set as Π. The operations depicted in this algorithm correspond to the extraction of bits based on the difference expansion method. Therefore, an even number of items is required in I. Thus, if an odd number of values is contained in I, one parameter is not involved in the synchronization.

First, Π is allocated as an array of ⌊|I|/2⌋ bits with all entries initialized to 0 (see line 1). The number of elements in Π is defined by |I|, which denotes the cardinality of I. The symbols ⌊·⌋ denote the floor function, used in case I is composed of an odd number of elements. ℙ is utilized to partition I into adjacent pairs (x, y) = (I_2p, I_2p+1) (see lines 3 and 4). Scanning pairs in this order, we read the bit embedded by difference expansion and store it into b_p (see line 5).⁷ Finally, the bit b_p obtained for the current pair of values is added to the position indexed by p in Π (see line 6).

After obtaining Π, line 4 of Algorithm 1 computes ζ₂ using the function CODE_BUILDER(·) that takes as input Π, η, k and ℙ. Considering this approach is symmetric, the key supplied to CODE_BUILDER(·) must match the key used when encoding the watermark hints in I. Algorithm 3 breaks down Code_builder(·), which assembles its output by mapping each index in ℙ to a target position in ζ₂ via a keyed, uniform index function, defined as KEYED_INDEX(·) (see lines 5 to 7). First, the binary arrays ζ₂, ones, and zeros, each of length η, are initialized with 0 (see lines 1 to 3). The arrays ones and zeros are used to check if, for the same position in ζ₂, different bit values are identified in Π, which basically means data tampering is being performed in I. The bit targeted in Π can be obtained after knowing its index, which is extracted from ℙ (see lines 5 and 7). Depending on the value of the bit selected from the p−th position in Π, the variables ones and zeros (counting the number of bits with 1 and 0 values for the matching position j, respectively) are incremented by one (see lines 8 to 11). Once all indices from ℙ are considered, the consistency checking of the values detected for each position in ζ₂ proceeds (see lines 12 to 21).

Consistency at position j is established by inspecting the tallies in ones and zeros for that index. If ones[j]>0 and zeros[j] = 0, we set ζ₂[j]←1 (see lines 15 and 16); if zeros[j]>0 and ones[j] = 0, we set ζ₂[j]←0 (see lines 17 and 18). Otherwise, either no votes (ones[j] = zeros[j] = 0) or a discrepancy (ones[j]>0∧zeros[j]>0), we treat the event as potential tampering and resolve it with a keyed tie-breaker KEYED_BIT(·) (see lines 20 and 21). This yields a deterministic, key-scoped bit that prevents chance agreement on manipulated inputs while remaining reproducible during verification. The generative key-based routines KEYED_PERMUTATION(·), KEYED_INDEX(·), and KEYED_BIT(·) are described in Section 4.5.

After the function Code_builder returns ζ₂, the code is represented in base-6 notation (denoted by ζ₆) by a simple base change operation performed by the function BASE_CONVERT(·) (see line 5 of Algorithm 1). Next, the graph representing the watermark is generated by the function ENCODE_WATERMARK(·) taking as input ζ₆ (see line 6).

The generation of the watermark is based on the graph representation of base-6 numbers presented in Collberg and Thomborson (1999). Algorithm 4 details the construction of the graph G from ζ₆. For this, ζ₆ is treated as an array of μ elements. The algorithm receives ζ₆ (which can also be used to obtain μ), and returns the head node N₀ of a circular list representing the graph. The watermark construction works by building a circular singly linked list of μ nodes N₀, …, N_μ−1, where each node has two pointer fields: next and digit. The next field forms a ring, according to N_r.next = N_{(r+1) mod μ} with r ∈ ℤ⁺|0 ≤ r ≤ μ−1. The watermark is encoded solely by the digit pointers: if ζ₆[r] = 0 then N_r.digit = null; otherwise N_r.digit = N_{(r+ζ6[r]−1) mod μ}. Intuitively, the digit is the forward offset along the ring: 1= self, 2= next, 3= next–next, and so on (with modulo wrap-around); 0 is indicated by the absence of a pointer.

In the algorithm, all nodes are allocated with fields next, digit (see line 1). Next, the circular link between the nodes is created (see lines 2 and 3). Then, the values of the digit pointers are computed and assigned to each node depending on each value stored in each position of ζ₆, according to the criteria previously described (see lines 4 to 9). Finally, the head node of the structure representing the watermark is returned (see line 10).

The entire watermark graph can be traversed from any head node. Given access to the first node, the decoder assumes the structure matches the circular list described above. Algorithm 5 describes the function DECODE_WATERMARK(·), used for the decodification. It takes as input a head node, denoted as N0′ (assumed to be the entry of the graph) and the length μ of the code expected to be extracted from the identified watermark. First, the function creates and initializes ζ₆ as an array of μ items (see line 1). Then, it sets N0←N0′ (see line 2). Next, it proceeds to create the circular list used to represent the graph. This is done by following next pointers for μ steps to collect the nodes in order from N₀ to N_μ−1 (see lines 3 and 4). It is important to notice that the selection of N0′ only rotates the sequence and thus does not affect the recovered digits.

Next, the algorithm proceeds to decode each digit locally. For the position r, if N_r.digit = null then ζ₆[r]←0 (see lines 6 and 7). Otherwise, it starts at N_r and advances along next, counting steps s until the digit target is reached, and returns ζ₆[r]←s+1 (so 1= self, 2= next, 3= next-next, etc.) (see lines 9 to 17). The algorithm also uses a guard s>μ that flags an invalid structure (e.g., broken ring or unreachable digit) and prevents non-termination (see lines 15 and 16). Finally, after considering all nodes, if no error is reported, the recovered ζ₆ is returned (see line 18).

Algorithm 6 defines the process executed by the Controller. It takes as input the assumed initial node N0′ from which the watermark is accessed, and the code ζ, which is used for comparison in assessing the authenticity of the parameters. According to the methods previously described to build Π from I, ζ is obtained and passed to the Controller based on blind principles, without requiring the original set of parameters, which would increase the risk of exposure of the protected content, offering unnecessary opportunities to malicious actors of intercept the data and compromise our approach's performance, and therefore, the security it provides. Nevertheless, ζ can be obtained from P or a second program deployed in the environment. Static watermarking techniques can be used to store ζ in P if required.

As depicted in Algorithm 6, the Controller starts by converting ζ into ζ₆ in order to obtain μ, which is required to build the code from the watermark (see lines 1 and 2). Next, using the function DECODE_WATERMARK(·), it proceeds to decode the watermark from the node N0′ (see line 3). Then, it converts ζ6^ into ζ^, which is the alleged secret code in decimal notation (see line 4). Finally, if ζ=ζ^, the authenticity of the parameters is verified and the process informs P that there is no risk in executing F with I (as previously defined, F^I) (see lines 5 and 6). On the other hand, if ζ≠ζ^, the alternative flow is invoked to address the lack of authenticity in the parameters. Therefore, the Controller instruct P for the execution of F^ϕ instead (see lines 7 and 8). Calling F^ϕ does not necessarily mean the execution of the function. It can also refer to the execution of an alternative logic in P. Since the Controller instructs P and does not pass parameters to it directly, I is not considered among the inputs of Algorithm 6.

It is important to note that watermark encoding and detection occur during program execution. Furthermore, the combination of static and dynamic approaches can increase resilience to our proposal. The parameter authentication approach has some features that contribute to its success. The input is never directly compared to a plain value in P. No visible hash or key is checked; only graph logic is used. Operations such as reverse engineering become more challenging, especially when the node structure is obfuscated and the watermark construction is triggered only under certain conditions.

This solution can be applied to tamper detection, where any modification of the input parameters renders the detected watermark invalid. Furthermore, since cryptographic hash functions are computationally efficient, this approach requires minimal computational resources. Finally, metadata for additional validation, such as timestamps or user IDs, can be considered when building W, thereby increasing the meaningfulness and robustness of the proposal.

Three critical functions are essential for the correct functioning of the parameter authentication approach. They are KEYED_PERMUTATION(·), KEYED_INDEX(·), and KEYED_BIT(·). Although their goal is briefly mentioned when presenting the approach, this section describes them in more detail.

We start from the basis that dynamic watermarking techniques have not been applied for this goal before. We selected Python 3.12.7 for implementing our approach, considering its extensive use in developing solutions that address the challenges we mentioned earlier. The development environment was Spyder 5.5.1 Integrated Development Environment (IDE) from the Anaconda Navigator 2.6.4 Python distribution. The runtime environment consisted of a PC equipped with an Intel i7-7700K processor, clocked at 4.20 GHz, 32.0 GB of RAM, and running Windows 10 (AMD64) Pro OS.

We selected five Python functions implementing different functionalities to validate our approach. Each function takes an array of integers as input, but the acceptable range of values depends on the specific logic implemented. A brief description of each function is provided below:

For each function, we use five different sets of parameters, each consisting of an array of 32 integers. Each parameter is identified by a name that links it to the function on which it is used. The structure of the set name is I_F−D where F ∈ {A, B, C, D, E} identifies the function and D ∈ {1, 2, 3} denotes the parameter set for that function. According to this, I_A−3 denotes the third set of parameters for the function F_A (a.k.a total_revenue_cents(·).

Table 2 summarizes the characteristics of each dataset used as input for each function. It contributes to understanding the range of values that each function handles and the differences across the cases analyzed. Specifically, for each array, the table reports the maximum value (column MAX), the minimum value (column MIN), the average (column AVG), and the standard deviation (column STD_DEV). These statistics provide insight into the variability and distribution of values within each dataset.

The validation of the proposed approach is guided by the research questions introduced earlier. This section presents the results that address the first question: “Does the proposed approach detect tampering of input parameters with a high true-positive rate and low false-positive rate across representative workloads?” To answer this, it is first necessary to define: (i) how to compute the true-positive rate (TPR) and what qualifies as a high value, (ii) how to compute the false-positive rate (FPR) and what qualifies as a low value, and (iii) which representative workloads are suitable for validating the proposal.

The true-positive rate (TPR) measures the proportion of tampered inputs that are correctly detected as tampered. In this work, it is computed according to Equation 1, where TP denotes the number of tampered cases correctly identified and FN the number of tampered cases missed (Fawcett, 2006; Sokolova and Lapalme, 2009). In our context, a high TPR indicates near-exhaustive detection of tampering and should be defined a priori. We formally adopt TPR≥0.99 as the threshold for a high TPR, given the importance of ensuring the proper functioning of the proposed approach.

The false-positive rate (FPR) measures the proportion of authentic inputs that are incorrectly flagged as tampered. In this work, it is computed according to Equation 2, where FP denotes the number of authentic inputs incorrectly classified as tampered and TN the number of authentic inputs correctly classified as not tampered (Fawcett, 2006; Sokolova and Lapalme, 2009). In our context, a low FPR indicates rare false alarms and should be defined a priori. We formally adopt FPR ≤ 0.01 as the threshold for a low FPR.

Finally, we define a representative workload as a curated set of inputs and execution conditions that faithfully reflect the system's intended use. Such a workload should preserve the statistical properties of the data, the shape and scale of inputs, and the mix of operations exercised by the application. It should also include both benign variations (e.g., reordering, padding) and adversarial perturbations consistent with the threat model, all under reproducible settings.

In our evaluation, the five previously introduced functions constitute the representative workload. Together they span order-insensitive aggregation (as in F_A), a robust order statistic (as in F_B), rate/threshold computation near decision boundaries (as in as in F_C), vectorized boolean flagging (as in F_D), and multi-level classification on time series (as in F_E). This set covers both order-insensitive and order-sensitive behaviors, single-output and vector outputs, and varying sensitivities to bit-level edits and structured tampering, while also admitting benign controls (e.g., pure reordering) to estimate the FPR. Instantiated across multiple scales and data distributions, these functions provide a realistic and reproducible proxy for the target application domain, thereby satisfying the representativeness required by the first research question.

To evaluate the performance of our proposal in detecting data tampering, we conducted 15 experiments per function. Each function was tested with its corresponding datasets, applying five different degrees of data modification. We deliberately selected the smallest possible number of elements and applied minimal changes to stress-test our approach, assessing whether tampering could still be detected even when the modifications were so slight that they sometimes did not alter the function's output. Tampering was introduced by pseudo-randomly selecting between one and five input values and modifying the least significant bit (lsb) of each chosen value.

The results are presented in Table 3 for each function (column F) and its associated dataset (column I). They are organized into four groups of columns: Tampering Detected, TPR, FPR, and Output Modified. Binary outcomes are denoted as ✓ (yes) and ✗ (no). Within each group, five columns correspond to the number of array items pseudo-randomly selected for lsb modification. The Output Modified column illustrates that tampering does not always lead to changes in the function result. Nevertheless, detecting such tampering remains essential to uncover potential vulnerabilities, prevent unauthorized access or data leaks, and mitigate the risk of future output changes if function logic is modified under approved requirements.

As shown in the table, tampering was successfully detected in every case, thereby fulfilling the requirement established by the first research question: demonstrating that the approach achieves TPR = 1 and FPR = 0. Detection was achieved even in cases where the modifications did not affect the output that the function would have produced on untampered data. This highlights another strength of our approach. Nevertheless, it is important to note that this behavior depends heavily on the function's requirements and implementation. For example, the output of F_A was always different, since it performs a summation of all input values. By contrast, F_B, which computes the average of the input values and returns a rounded result, is less likely to change under small modifications. Finally, changes in the outputs of F_D and F_E were rarely detected, as their results only vary when tampering affects values close to the classification boundaries defined by the functions.

The results presented in this section correspond to the experiments conducted to address the second research question: “Does integrating the approach preserve the functional output of protected functions when the input parameters are authentic?” To answer this, we obtained the outputs of each function using the various datasets and compared them with the outputs obtained after confirming that no tampering occurred and the input parameters were restored. Success is defined as confirming that the outputs remain unchanged. Additionally, we provide the outputs that each function would produce if the input parameters were not restored after decoding the watermark, allowing a comparison of the distortion introduced by retaining the watermark hints.

Table 4 shows the outcomes of functions F_A, F_B, and F_C, for each input set, both before and after applying our approach. The group labeled After contains two columns: Encoded, which refers to parameters still containing the watermark hints (not restored to their original state), and Restored, which contains the data after extracting the hints, restoring the parameters, and verifying the authenticity of the watermark. Values in the Encoded column include a number in parentheses representing the difference from the output obtained before embedding the watermark hints.

The table shows how distortion can result in different outputs. However, in some cases, no distortion occurs because increases in certain values are compensated by decreases in others during the embedding of the hints or due to the way the function processes the input. This behavior is observed in all cases of function F_B, for example. Additionally, the results from these experiments confirm that our approach does not interfere with the outputs of the functions, as evidenced by the comparison between the Before and Restored columns.

Table 5 shows the results obtained when applying our approach to the function F_D with its corresponding inputs. Each output is presented in two columns, T and F, containing the number of true and false values in the boolean list returned by the function. Notice that in the Encoded column, the function's outputs sometimes remain unchanged. Additionally, because the output consists of a group of values, any distortion introduced by embedding the watermark hints is compensated across the different elements of the group (for example, under the Encoded column, values in T offset those in F). Finally, the fact that our approach does not interfere with the function's accuracy is evident from the matching values in the Before and Restore columns.

Table 6 shows the results of the experiments performed for F_E with its corresponding inputs. In this case, the function returns three integers, shown in columns N, H, and C, which stand for “normal”, “high”, and “critical”, respectively. We can see that sometimes the encoding does not alter certain outputs (e.g., under the Encoded category, column C for dataset I_E−1, and column H for dataset I_E−2). Additionally, also in this case, it is clear that the distortion introduced by embedding the watermark hints is compensated across the different elements in each output. Finally, we can see that once the hints are extracted from I, the restored parameters allow the computation of the same results as those obtained with the original set of inputs.

As shown in the previous tables, we can confirm that our approach does not interfere with the outputs of the functions. This is ensured by the reversibility provided through difference expansion. When obtaining ζ, the set of input parameters is restored to its original state. If ζ does not match the expected value, the watermark is not recognized, and an alternative flow is triggered, allowing P to take control and manage the process in a customized manner. Conversely, if the parameters are considered authentic, F is executed with authentic inputs, producing accurate results. This conclusion is supported by the fact that none of the experiments resulted in variations in the functions' outputs when the parameter authentication approach was applied.

This section addresses the third research question: “Does integrating the approach impose a bounded, predictable overhead in code size and execution time, with runtime scaling linearly in input size across representative workloads?” Here, we present the results of a set of experiments that evaluate the impact of our approach on the protected software. We report the effects on software size and how processing time is affected. These experiments allow us to quantify the overhead introduced by the watermarking mechanism and assess its practicality in real-world applications. By analyzing both memory footprint and execution time, we provide a comprehensive view of the trade-offs involved in applying our method.

We evaluated the robustness of our approach to code transformations by considering the last research question: “Are authentication decisions robust to compiler/interpreter optimizations, code obfuscation, common refactoring, and heterogeneous runtime environments?” First, we checked whether the proposed approach is invariant under a simple interpreter optimization pass by running each program in three modes: default (python), optimized (python -O), and docstring-stripping optimized (python -OO). For each mode, and for each workload program, we execute the pipeline with identical inputs, comparing the results on tampering detection, and encoding/decoding times. The expectation is functional invariance (identical decisions and recovered codes) and only minor timing drift due to bytecode differences.

Figures 5–8 show that, under all three interpreter modes, the encoding and decoding curves retain the expected linear trend in the input size (|I| for encoding the watermark hints, and μ for the watermark graph G). Optimization mostly produces modest timing shifts without changing qualitative behavior. The small deviations shown in the figures are consistent with bytecode changes, allocation and cache effects, and the removal of assertions/docstrings.

Crucially, optimization does not alter security outcomes. The tampering decisions are identical across all all three interpreter modes. Thus, the approach is robust to common compiler/interpreter optimizations. Its scalability (O(|I|)/O(μ)), encode > decode gap, and correctness are preserved, while performance differences remain bounded and predictable. This supports deployability in optimized production configurations without weakening authentication guarantees.

We further assessed robustness to code-level transformations by applying: (i) lexical/minification changes (identifier renaming, removal of whitespace and docstrings), (ii) bytecode wrapping and encryption via a runtime loader, and (iii) native compilation and packaging to an executable. In parallel, we enacted common refactorings that preserve semantics, including function extraction/inlining, module reorganization, dead-code removal, and reorderings that do not affect data or control dependencies. For each transformed artifact, we ran the full pipeline with identical inputs, keys, and PRNG seeds, verifying tampering detection results, effects on the workload functions, and timing profiles. Across all obfuscation levels and refactorings, authentication decisions and recovered tags remained identical to the baseline, and the encode/decode time curves preserved the same linear trend with only bounded drift, mirroring the behavior observed under the -O/-OO optimization experiment.

In terms of robustness against the major categories of attacks described in Section 2.4, specifically subtractive, distortive, and additive, it is important to emphasize that the proposed approach follows the principles of a fragile watermarking technique. Its primary objective is not to remain undetectable under all possible modifications but rather to act as a sensitive safeguard against unauthorized operations. By detecting even minimal alterations to input parameters, the technique ensures that users are alerted whenever data authenticity may be compromised. Table 8 summarizes the overall resilience of the approach against these classical attack types.

Our solution demonstrates strong resistance to subtractive attacks because the correct watermark cannot be identified or reconstructed unless the precise input parameter values are used to achieve synchronization. Any attempt to remove or bypass the watermarking logic without providing the expected parameters will therefore fail, preventing the protected function from executing successfully.

This same principle underlies the approach's resilience to distortive attacks. Any modification to the software code or data aimed at undermining watermark detection will lead to the construction of an incorrect watermark, automatically triggering a suspicion of tampering. This behavior aligns with the core purpose of fragile watermarking, which is to flag even subtle unauthorized distortions as potential integrity violations.

Finally, the approach also provides strong protection against additive attacks. The reconstruction of the watermark code is only possible when all bits derived from the secret integer code match precisely. As demonstrated in our experiments, altering even a single bit results in a chaotic reconstruction, producing a watermark that no longer corresponds to the original. Consequently, any attempt to embed an additional watermark is treated as tampering and is reliably detected.