Model Watermarking

A robust watermark must be imperceptible to ensure it does not degrade the primary task performance of the watermarked model. This is measured by fidelity, the minimal performance difference between the original and watermarked models on their intended task (e.g., classification accuracy). The watermark should be embedded in a way that is orthogonal to the main task's feature space.

• Key Metric: The drop in test accuracy on clean data should be statistically negligible.
• Technique: Watermarks are often embedded in low-magnitude parameters or via regularization that minimally perturbs the decision boundary.

The watermark must be robust against intentional and unintentional removal attempts. This is a primary defense against model theft, where an adversary may try to fine-tune, prune, or compress a stolen model to erase the owner's signature.

• Robustness Targets: The watermark should survive model fine-tuning, parameter pruning, and model compression techniques like quantization.
• Embedding Strategy: Robustness is often achieved by embedding the watermark deeply into the model's functional behavior, such as by using a set of trigger samples that cause a specific, hard-to-remove output pattern.

Each watermark must be unique to a specific model instance, deployment, or client cohort, enabling precise attribution. It must be verifiable by the model owner using a secret key or a set of private trigger inputs.

• Verification Process: The owner presents the secret trigger set to a suspect model. If the model outputs the pre-defined, unique signature (e.g., specific labels), ownership is proven.
• Federated Context: In federated learning, watermarks can be uniquely tailored per client or per training round to trace the source of a leak.

Capacity refers to the amount of information (bits) that can be reliably embedded into the model without breaking fidelity. Overhead refers to the computational cost of embedding and verifying the watermark.

• Trade-off: Higher capacity allows for more complex signatures (e.g., client IDs, timestamps) but risks greater fidelity loss.
• Federated Consideration: The embedding process must be lightweight enough to run on edge devices and the verification must not require retraining or excessive server resources.

The watermarking mechanism must be cryptographically secure. The secret key or trigger set used for embedding and verification must remain confidential with the model owner. An adversary with knowledge of the watermarking algorithm or trigger set could remove the signature or frame an innocent party.

• Security Assumption: The scheme relies on the Kerckhoffs's principle—security should depend solely on the secrecy of the key, not the algorithm.
• Threat: A collusion attack, where multiple watermarked copies are compared to infer and remove the signature, must be considered in design.

Watermarks are categorized by how they are embedded:

• Parameter-Based Watermarks: A signature is directly encoded into the model's weight values (e.g., in specific neurons or via regularization). These can be fragile to model modification.
• Functional Watermarks (Backdoor-Based): The model is trained to exhibit specific, secret behaviors when presented with a set of trigger inputs. This is highly robust as the behavior is woven into the model's function. For example, images with a specific pixel pattern always map to a pre-chosen label.

In federated learning, functional watermarks are often preferred due to their robustness against averaging and client-side manipulations.

A class of server-side algorithms designed to produce a correct global model update even when a fraction of participating clients are malicious or faulty. Unlike standard Federated Averaging, these methods filter out adversarial updates.

• Core Function: Statistically identifies and mitigates the influence of outliers in client updates.
• Examples: Krum, Bulyan, Trimmed Mean, and Median Aggregation.
• Threat Addressed: Directly counters data poisoning and model corruption attacks from adversarial clients.

Cryptographic protocols that allow a server to compute the sum or average of client model updates without learning any individual client's contribution. This protects client data privacy during the aggregation phase.

• Mechanism: Often uses multi-party computation (MPC) or homomorphic encryption.
• Key Benefit: Prevents the server from performing model inversion or membership inference attacks on individual updates.
• Limitation: Protects privacy during aggregation but does not by itself provide robustness against Byzantine clients.

The application of formal differential privacy (DP) guarantees to the federated learning process. Noise is added to updates or the final model to prevent leakage of individual training data points.

• Local DP (LDP): Clients add noise to their updates before sending them to the server.
• Central DP: The server adds noise to the aggregated global model update.
• Privacy Accounting: Tracks cumulative privacy loss (epsilon, delta) across training rounds.
• Primary Defense: Against membership inference and reconstruction attacks.

A dynamic defense mechanism where the central server assigns a credibility score to each client based on the historical consistency and quality of their updates. This score weights their contribution in future aggregation rounds.

• How it works: Updates deviating significantly from the consensus or exhibiting high loss are penalized.
• Objective: To gradually reduce the influence of free-riders, slow poisoners, or clients with very poor-quality data.
• Contrast with Watermarking: Proactive, continuous reputation management vs. watermarking's forensic, post-hoc ownership verification.

Server-side techniques that analyze and modify client updates before aggregation to remove malicious signals or excessive noise.

• Gradient Inspection: Analyzing update statistics (norms, distributions, angles) to detect anomalies.
• Update Sanitization: Applying defensive transformations like gradient clipping (bounding the norm) or noise addition.
• Purpose: A first line of defense against obvious poisoning attempts and a method to enforce differential privacy guarantees.

Strategies to prevent or remove hidden triggers implanted in a federated model by adversarial clients. A backdoor causes the model to misbehave only on inputs containing a specific trigger pattern.

• Threat Model: A client poisons its local data to associate a trigger (e.g., a pixel pattern) with a target label.
• Defenses: Include robust aggregation, trigger pruning, and model fine-tuning on clean data.
• Relation to Watermarking: Both involve embedding a signature, but a backdoor is malicious and stealthy, while a watermark is a legitimate ownership marker.