FedShield-LLM: Secure Federated LLM Fine-Tuning

• FedShield-LLM is a federated learning framework that combines LoRA-based adaptation, dynamic pruning, and CKKS homomorphic encryption to secure model fine-tuning.
• It employs efficient parameter updates and encrypted aggregation to reduce communication overhead and defend against gradient and membership inference attacks.
• The system also integrates privacy-preserving threat intelligence to collaboratively detect and mitigate prompt-injection attacks across organizations.

FedShield-LLM is a federated learning framework for secure, scalable, and privacy-preserving fine-tuning of LLMs, designed explicitly for cross-silo and multi-organization deployments. This system integrates parameter-efficient adaptation (LoRA), aggressive model update pruning, and computation on encrypted model parameters using Fully Homomorphic Encryption (FHE, specifically CKKS) to address both privacy threats such as gradient and membership inference, and pragmatic constraints such as communication and compute bottlenecks. In parallel, complementary work extends the architecture with privacy-preserving fingerprinting, enabling collaborative detection and response to prompt-injection attacks across strict compliance boundaries. FedShield-LLM achieves high utility, robust privacy, and regulatory compliance in distributed LLM training and threat intelligence sharing (Gill et al., 6 Sep 2025, Mia et al., 6 Jun 2025).

1. Federated Fine-Tuning Workflow and Parameter-Efficient Adaptation

FedShield-LLM decomposes the federated fine-tuning of LLMs into the following core modules:

1. LoRA-Based Adaptation: The system attaches Low-Rank Adaptation (LoRA) adapters to selected weight matrices $W\in\mathbb R^{d\times d}$ (e.g., Q/K/V projections) in the base transformer model. During federated local training, only the LoRA parameters $\Delta W = AB$ with $A\in \mathbb{R}^{d\times r}$, $B\in\mathbb{R}^{r\times d}$, $r\ll d$, are updated, while $W$ remains frozen. Thus, each client’s payload per adapter is reduced from $d^2$ to $2dr$ parameters.
2. LoRA Pruning: After local LoRA training, parameters are flattened ($\Delta w_i$), and unstructured L1-norm pruning is applied at a dynamic rate $p_t$. The pruning mask $m_i\in\{0,1\}^{|\Delta w_i|}$ zeros out the $p_t$ fraction of smallest-magnitude entries, yielding $\Delta w_i^p=\Delta w_i\odot m_i$. The pruning schedule increases $p_t$ gradually, balancing convergence and communication/attack surface reduction.
3. Homomorphic Encryption of Updates: Pruned parameter vectors $\Delta w_i^p$ are encrypted using CKKS, which supports homomorphic addition. Clients generate keys, encrypt their (pruned) parameter updates, and transmit ciphertexts. The server aggregates encrypted updates without decryption, and a trusted party (or threshold key decryption) recovers only the final sum for global model updates.
4. Secure Cross-Silo Aggregation: Algorithm 1 specifies the protocol for client selection, pruning scheduling, training, encryption, and aggregation, updating the global LoRA adapters in each communication round.

This design is validated on Llama-2-7B/13B and diverse benchmarks, and shown to substantially reduce communication, maintain rapid convergence, and allow practical model update exchanges ($\sim$180MB/round at 13B scale with CKKS) (Mia et al., 6 Jun 2025).

2. Secure Computation and Privacy Protections

FedShield-LLM addresses major privacy threats in federated LLM fine-tuning with a multi-layered approach:

• CKKS Fully Homomorphic Encryption: Ensures semantic security under RLWE. The server aggregates only ciphertexts, making raw model updates computationally inaccessible to adversaries without the secret key.
• Pruning-Induced Sparsity: The sparse (pruned) update vector presents an underdetermined system on decryption, further obfuscating any individual client’s contribution.
• Resistance to Inference Attacks: The reduction in exposed parameter data and the IND-CPA security of CKKS safeguard against membership and gradient-inversion attacks. Theoretical analysis (Theorem 2, (Mia et al., 6 Jun 2025)) formalizes that any PPT adversary's advantage in reconstructing private client data is negligible, even when colluding.

Compliance with privacy regulations is strengthened by ensuring that raw data and full precision updates never leave organizational boundaries during the aggregation process.

3. Federated Threat Intelligence: Non-Invertible Fingerprint Sharing

To augment LLM security across collaborative and regulated settings, FedShield-LLM can integrate a federated, privacy-preserving threat intelligence protocol inspired by BinaryShield (Gill et al., 6 Sep 2025):

• PII Redaction and Embedding: Each suspicious prompt undergoes aggressive PII removal (e.g., Microsoft Presidio), with placeholders preserving functional structure. The sanitized prompt $x_p$ is encoded as a semantic embedding $e = f_\mathrm{embed}(x_p) \in \mathbb{R}^d$ using models such as ModernBert or OpenAI text-embedding-3-large.
• Binary Quantization and Randomized Response: Embeddings are converted to sign-bit (binary) vectors; then, a randomized response mechanism is applied with per-bit flips determined by privacy budget $\alpha$, ensuring $\alpha$-local differential privacy ($$\forall b,b',o, \Pr[M(b)=o]/\Pr[M(b')=o]\leq e^\alpha$$).
• Similarity Search and Matching: Organizations share only the resulting non-invertible, DP-protected fingerprints (no raw prompts/embeddings). Cross-organization matching is achieved via Hamming distance thresholding; the pipeline supports highly efficient, sub-second similarity search at corpus scale (38$\times$ faster than cosine over dense embeddings).
• Federated Aggregation and Budget Management: DP-protected fingerprints can be shared through a secure aggregator or peer-to-peer with secure multiparty computation for match-finding. Privacy budgets are tracked under composition, and no raw samples are exposed, maintaining compliance and auditability.

4. Scalability, Utility, and Empirical Results

FedShield-LLM and its threat-intelligence extension achieve competitive or superior empirical performance:

• Communication Efficiency: LoRA adapters and pruning reduce per-client uploads from the full transformer parameter count ($P$) to $O(dr)$, further halved at 50% pruning.
• Computation Overhead: CKKS encryption requires $\sim$15s/client (encryption) and $<$1s (decryption); overall per-round computation remains practical for cross-silo deployments.
• Text Generation Quality: Across benchmarks (Alpaca-GPT4, FinGPT-sentiment, MathInstruct, Medical flashcards), average BERTScore (precision/recall/F1) on reasoning tasks is highest for FedShield-LLM (0.6738/0.7012/0.6865), versus DP-LoRA (0.6287/0.6031/0.6130) and Vanilla-FL (0.5683/0.5867/0.5756).
• Threat Signal Detection: In prompt injection detection with federated fingerprinting (V-Paraphrase, $\alpha$=2.0), BinaryShield achieves F1=0.94, outperforming SimHash (F1=0.77), with 64$\times$ storage and 38$\times$ search speedup over dense embeddings.

Method	Precision	Recall	F1
Vanilla-FL	0.5683	0.5867	0.5756
DP-LoRA ($\epsilon=2$)	0.6287	0.6031	0.6130
FedShield-LLM	0.6738	0.7012	0.6865

5. Compliance Boundaries, Governance, and Limitations

The FedShield-LLM architecture enforces strict compliance boundaries by:

• Never exporting raw prompts or high-dimensional embeddings beyond local control.
• Restricting cross-organization sharing to non-invertible, DP-protected fingerprints and encrypted model updates.
• Supporting per-organization privacy budget management, federated auditing, and scoping of metadata sharing.
• Accommodating model-adaptive extension, including local embedding model retraining and federated averaging of model-update deltas under DP as needed.

Limitations identified include the absence of Byzantine robustness or poisoning resistance in the current protocol, reliance on high-bandwidth infrastructure for encrypted payloads, and an IID data distribution assumption; directions for future work include robust aggregation, structured pruning, quantized FHE, and adaptation to non-IID client scenarios (Mia et al., 6 Jun 2025).

6. Integration of Model and Threat-Intel Privacy Infrastructures

FedShield-LLM enables the unified deployment of federated model training and secure threat intelligence exchange:

• Local Generation: Each organization independently redacts PII, produces embeddings and DP-protected fingerprints, and fine-tunes models using LoRA with FHE-sealed updates.
• Federated Aggregation and Search: Secure, privacy-preserving match-finding for attack fingerprints can be performed via cryptographic protocols, while encrypted model updates circulate in the federated learning process.
• Global Threat Repository: A global aggregator collects and disseminates only DP-protected signatures; no private or proprietary model data or prompts are exchanged.
• Compliance and Adaptivity: Policy infrastructure governs per-organization privacy budgets ($\alpha$), metadata usage, and evidence-based audit trails.

A plausible implication is that the combination of these architectures positions FedShield-LLM as both a federated model refinement solution and a collaborative, privacy-first threat detection network for LLM-driven applications facing cross-organizational security and compliance challenges (Gill et al., 6 Sep 2025, Mia et al., 6 Jun 2025).