💻 computer science

S3CDM: A secret-sharing-scheme-based cyberattack detection model and its simulation implementation

This paper presents S3CDM, a secret-sharing-scheme-based cyberattack detection model designed to identify unauthorized activities and protect sensitive data in large organizations, which is implemented and validated on the Google Cloud Platform using Docker, Python, and PostgreSQL.

Original authors: Chi Sing Chum, Jia Lu, Claire Tang, Xiaowen Zhang

Published 2026-04-15

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Chi Sing Chum, Jia Lu, Claire Tang, Xiaowen Zhang

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Big Idea: Don't Put All Your Eggs in One Basket

Imagine you are the owner of a very valuable treasure chest (your Secret). In the old days, you might have given the only key to your most trusted guard. But what if that guard gets bribed, hacked, or goes rogue? The whole system fails.

This paper proposes a new way to protect that treasure. Instead of giving one person the whole key, you cut the key into pieces and give a piece to several different people. To open the chest, you don't need just one person; you need a specific group of people (say, 2 out of 3) to bring their pieces together to reconstruct the key.

This is called Secret Sharing. The authors built a system called S3CDM (Secret-Sharing-Scheme-based Cyberattack Detection Model) to stop bad guys, especially "insiders" (people who already have access but shouldn't be doing what they are doing).

How It Works: The "Secret Recipe" Analogy

Think of the secret not as a key, but as a secret recipe for a delicious cake.

The Dealer (The Head Chef): This is the system that takes the secret recipe and chops it up into ingredients.
The Controllers (The Sous Chefs): These are the different computers or people in the network. Each one gets a bag of ingredients (a "share").
The Node (The Oven): This is the machine that actually does the work (like switching a network path or unlocking a door).

The Rule: The Oven won't turn on unless it receives a signal that proves the recipe has been reconstructed. To reconstruct the recipe, the Head Chef needs to collect ingredients from at least two of the three Sous Chefs.

If a hacker hacks one Sous Chef, they only have one bag of ingredients. They can't bake the cake (they can't unlock the system). They are stuck.

The Problem: The "Broken Road"

The paper also solves a tricky problem: What if the road to the Oven is broken?

Imagine the Head Chef tries to send the "Go Ahead" signal to the Oven, but the direct road is blocked (maybe a cable is cut, or a server is down). In a normal system, the Oven would never get the message, and the system would fail.

The S3CDM Solution:
The system is smart. If the direct road is blocked, it finds a detour.

The Head Chef sends the message to Sous Chef B.
Sous Chef B sees the message is meant for the Oven, so they pass it along to the Oven.
The Oven gets the message, even though the direct road was broken.

This is called Routing. The system constantly checks the "traffic map" to find the best path, or a backup path, to ensure the message gets through.

The "Bad Guy" Scenario (Insider Threat)

The paper focuses heavily on Insider Threats.

Scenario: A hacker gets inside the network and takes over one of the Sous Chefs (Controller).
Old System: The hacker now has the key. They can tell the Oven to do whatever they want (steal data, shut down the power grid).
S3CDM System: The hacker has one bag of ingredients. They try to tell the Oven to open up. The Oven says, "I need a signal from the Head Chef, and the Head Chef needs to verify that two Sous Chefs agree."
Result: The hacker can't do it alone. The system detects that the request is incomplete or suspicious and blocks it.

How They Built It (The Lab)

The authors didn't just write this on paper; they built a working model in the cloud (Google Cloud).

The Dashboard (UI): A colorful screen where you can see all the Sous Chefs, the Head Chef, and the Ovens. You can click buttons to "break a road" or "hack a chef" to see what happens.
The Backend: The code running in the background that actually cuts the secrets and checks the math.
The Database: A notebook that writes down every single request, who approved it, and if it failed.

Why This Matters

In our digital world, we trust computers to run our banks, power grids, and hospitals. If one computer gets hacked, the whole thing can crash.

This model says: "Don't trust just one computer."
By splitting the power among many computers, and making them work together to make decisions, it becomes incredibly hard for a single bad actor (or a single broken wire) to cause a disaster.

Summary in One Sentence

The authors built a digital security system where no single person or computer can make a dangerous change alone; they must team up with others to prove they are trustworthy, and if a direct connection breaks, the system automatically finds a detour to keep things running safely.

1. Problem Statement

The paper addresses the critical challenge of cyberattacks, with a specific focus on insider threats. Traditional security models often rely on a single entity or controller to manage access keys or make critical decisions. This creates a "single point of failure" where a compromised insider or a hacked controller can manipulate the system, forge signals, or execute unauthorized actions without detection.

Core Issue: Relying on a single trusted entity is risky in complex network infrastructures (e.g., cloud systems, critical infrastructure).
Goal: To design a system that prevents unauthorized activities by distributing trust and requiring consensus among multiple components before executing critical actions, thereby detecting and mitigating insider threats.

2. Methodology: The S3CDM Model

The authors propose the Secret-Sharing-Scheme-based Cyberattack Detection Model (S3CDM). Instead of a single controller sending a direct signal, the system splits a "secret" (representing an authorization key or action index) among multiple participants (controllers).

A. Core Cryptographic Mechanisms

The model utilizes two types of secret sharing schemes:

Shamir's Secret Sharing: Based on polynomial interpolation. It is a $(t, n)$ -threshold scheme where $n$ is the total number of participants and $t$ is the threshold required to reconstruct the secret.
Hash Function-Based Scheme: An alternative scheme proposed by the authors (referencing [4, 5]) designed for efficiency.
- Setup: A dealer generates random shares ( $s_i$ ) for $n$ participants.
- Access Structure: Defines "minimal authorized subsets" (groups of size $t$ ).
- Recovery: Participants in an authorized subset concatenate their shares, hash the result ( $H(M_{priv})$ ), and XOR it with a public control value ( $c_i$ ) to recover the secret ( $h$ ).
- Advantages: This hash-based approach is "perfect" and "ideal" (shares are the same size as the secret), computationally faster (no polynomial interpolation), and flexible regarding the number of participants.

B. System Architecture & Logic

The model operates on a Software Defined Network (SDN) concept where controllers and nodes interact via "tickets" (messages).

Action Database: A hierarchical database stores rules for requests.
- Level 0: No restrictions (direct approval).
- Level 1: Restricted requests requiring specific permissions.
- Level 2: Critical requests requiring Secret Sharing. The request is not a direct command but an index pointing to a secret that must be reconstructed by a subset of controllers.
Detection Logic: If a controller is compromised, it cannot forge the secret alone. If the reconstructed secret does not match the database entry, the system flags an unauthorized activity.

3. Implementation Details

The authors implemented a full simulation of S3CDM on the Google Cloud Platform (GCP) using a microservices architecture.

Frontend (UI): Built with React.js and Bootstrap, running on an HTTP server. It allows users to configure schemes, view shares, and simulate network conditions.
Backend (Python): Comprises four distinct microservices:
1. Dealer: Generates secrets/shares, distributes them to controllers, and performs secret recovery.
2. Controller: Holds a share, initiates requests, and responds with shares when requested. Can be simulated as "compromised" (by altering the share).
3. Node: Executes the actual action (e.g., system command) only upon successful secret recovery.
4. Name Registry: Acts as a dynamic DNS and routing service. It uses Dijkstra's algorithm to find the shortest path between services. It handles "broken paths" by rerouting traffic through intermediate nodes (e.g., if Dealer $\to$ Node is broken, it routes via Node A $\to$ Node B).
Database: PostgreSQL stores the Action Database (rules), Audit Logs (recovery attempts), and Share configurations.
Containerization: Docker is used to manage the lifecycle, scaling, and networking of the services.

4. Key Contributions

Novel Detection Model: Integration of secret sharing schemes directly into the cyberattack detection workflow, shifting from "single-point authentication" to "multi-party consensus."
Hybrid Scheme Support: The model successfully implements and compares both traditional Shamir schemes and a custom, efficient Hash-based scheme.
Dynamic Routing & Fault Tolerance: The inclusion of a Name Registry with path-weighting allows the simulation of broken links and traffic congestion, demonstrating the system's ability to maintain integrity even when communication paths are disrupted.
Comprehensive Simulation Platform: A fully functional, open-access (via the provided link) web-based UI that allows users to visualize and interact with the secret sharing process, including simulating compromised controllers and broken network paths.

5. Results & Demonstration

The paper demonstrates the system's feasibility through a specific Use Case: Simulating a Broken Path.

Scenario: The direct link between the Dealer and Node-2 is disabled (simulating a network failure).
Process:
1. Controller 1 initiates a Level 2 request.
2. The Dealer attempts to route the recovery result to Node-2.
3. Due to the broken link, the Name Registry reroutes the message through an intermediate Node (e.g., Node-5).
4. Node-5 forwards the message to Node-2.
5. Node-2 successfully receives the recovery result, validates the secret, and executes the action.
Outcome: The system successfully recovered the secret and executed the action despite network fragmentation, proving the robustness of the routing mechanism and the security of the multi-component authentication.
Security Verification: The UI allows users to "change a share" to mimic a compromised controller. In such cases, the secret recovery fails, and the system logs the failure, preventing the unauthorized action.

6. Significance

Insider Threat Mitigation: By requiring multiple independent components to reconstruct a secret, the model significantly raises the bar for insider attacks. A single compromised insider cannot trigger critical actions.
Scalability and Flexibility: The hash-based scheme allows for an arbitrary number of participants without the computational overhead of polynomial interpolation.
Educational Value: The project serves as a practical teaching tool for cybersecurity, cryptography, and cloud computing, bridging the gap between theoretical secret sharing and real-world implementation.
Future Directions: The authors plan to enhance the system with automated audit analysis to identify compromised controllers based on recovery failure patterns and to implement share validation before reissuing new shares.

In conclusion, S3CDM provides a robust, flexible, and demonstrable framework for securing complex network infrastructures against both external attacks and internal threats by leveraging the mathematical guarantees of secret sharing schemes.