SST Testbed

Overview

SST Testbed is an open-source, extensible platform for evaluating the security and resilience of embedded, resource-constrained networked systems. It supports replay attacks and denial-of-service (DoS) attacks — including distributed (DDoS) variants — through configurable CSV input files and lightweight shell scripts.

SST Testbed won 1st place in the Embedded System Software Competition (ESSC) at ESWEEK 2025.

Publication: C. Beltran Quinonez, D. Kim, and H. Kim, "SST Testbed: An Experimental Platform of Attacks and Defenses for Networked Embedded Systems," in Proc. 2026 IEEE International Conference on Industrial Technology (ICIT), 2026. DOI: 10.1109/ICIT64854.2026.11490150

Source: examples/SST_Testbed/ in iotauth/sst-c-api

Background

The growing prevalence of IoT devices introduces significant security challenges: constant connectivity and limited resources make them vulnerable to network-level attacks. SST Testbed addresses the lack of open-source security testbeds designed for constrained environments by providing a practical, reproducible environment for attack simulation and defense evaluation.

SST Testbed builds on the Secure Swarm Toolkit (SST) C API. Auth acts as the Key Distribution Center (KDC), providing authentication and authorization services. The testbed can run entirely on workstations or be deployed to resource-constrained hardware such as Raspberry Pi boards without modifying attack logic.

Workflow

The testbed workflow has five stages:

1. Setup — Specify the number of clients and attack type in an input CSV file; run clients_dos_setup.sh to initialize the environment.
2. Generate Testbed — graph_generator.js produces the network topology; config_generator.js creates per-entity config files (credential paths, Auth IP/port, Auth ID, entity name).
3. Execution — run_clients.sh launches the specified number of clients and the server, each loading its config file.
4. Attack Simulation — Clients carry out the attack scenarios defined in the CSV.
5. Deployment — Artifacts can run in simulation (ns-3) or be deployed directly to embedded devices.

Supported attacks

Attack	Target	Mechanism
Replay	Server	Manipulates the per-message sequence number to replay previous messages.
DoSK	Auth	Floods Auth with excessive session key requests, exhausting key-provisioning capacity.
DoSM	Server	Floods the server with a large volume of encrypted messages once a session is established.
DoSC	Server + Auth	Repeatedly connects to the server, consuming connection-table resources and triggering Auth key requests each time.
SYN flood	Server	Sends TCP SYN packets without completing the handshake, filling the target's half-open connection table.

All attacks except SYN flood are driven by CSV input files so scenarios are fully configurable without recompilation.

Experimental results

The testbed was evaluated across three hardware configurations (workstation + Raspberry Pi 4B boards):

Attack	Max latency increase	Min throughput
DDoS Key (DoSK, 100 attackers)	85×	1.1% of baseline
DDoS Message (DoSM, 100 attackers)	301×	~0% of baseline
DDoS Connect (DoSC, 100 attackers)	9.6×, 90% connection failure rate	1.2% of baseline
DDoS SYN flood	6.0×	17.3% of baseline

Prerequisites

Same as the C Guide, plus:

• Java 11 or newer (for Auth)
• Maven (for Auth)
• Node.js and npm (for graph/config generation)

Install on Ubuntu:

sudo apt-get update && sudo apt-get install -y \
    openjdk-11-jdk maven nodejs npm \
    openssl cmake build-essential pkg-config libssl-dev

Install on macOS:

brew install openjdk@11 maven node openssl cmake pkg-config

Clone and build

Clone iotauth with submodules (sst-c-api is a submodule at entity/c/):

git clone https://github.com/iotauth/iotauth.git
cd iotauth
git submodule update --init

Build the SST Testbed binaries:

cd entity/c/examples/SST_Testbed
mkdir build && cd build
cmake ../
make

For debug output:

cmake -DCMAKE_BUILD_TYPE=Debug ../
make

Run examples

Start Auth

cd auth/auth-server
mvn clean install
java -jar target/auth-server-jar-with-dependencies.jar \
    -p ../properties/exampleAuth101.properties

1. Basic messaging (no attacks)

Optionally edit csv_files/basic_messages.csv:

<sleep_ms>,<message>
1000,hello from client
500,another message

Run the server and client:

# Terminal 1
./entity_server ../../server_client_example/c_server.config

# Terminal 2
./entity_client ../../server_client_example/c_client.config \
    ../csv_files/basic_messages.csv

2. Replay attack

Edit csv_files/replay_attack.csv (third column is Replay, fourth is sequence-number modification):

<sleep_ms>,<message>,Replay,seq--
<sleep_ms>,<message>,REPLAY,seq++
<sleep_ms>,<message>,replay,seq=12

./entity_client ../../server_client_example/c_client.config \
    ../csv_files/replay_attack.csv

3. DoS attacks (single client)

DoSK — flood Auth with key requests (fourth column = number of requests):

<sleep_ms>,<message>,DoSK,10000

DoSM — flood server with messages (fourth column = number of messages):

<sleep_ms>,<message>,DoSM,10000

DoSC — flood server with connections (fourth column = number of reconnects):

<sleep_ms>,<message>,DoSC,10000

Run with the corresponding CSV file:

./entity_client ../../server_client_example/c_client.config ../csv_files/dos_attack_key.csv
./entity_client ../../server_client_example/c_client.config ../csv_files/dos_attack_message.csv
./entity_client ../../server_client_example/c_client.config ../csv_files/dos_attack_connect.csv

4. DDoS attacks (multiple clients)

First stop the single-client Auth and regenerate Auth databases for multiple clients:

cd entity/c/examples/SST_Testbed/clients_dos_attack
./clients_dos_setup.sh <num-clients> -p <password>
# e.g., ./clients_dos_setup.sh 10 -p mypassword

Then launch all clients simultaneously:

./run_clients.sh <num-clients> <csv-file>
# e.g., ./run_clients.sh 10 ../csv_files/dos_attack_connect.csv

Each client launches in its own terminal window and executes the attack in the CSV file simultaneously.

CSV format reference

Column	All scenarios	Attack-only
1	Sleep time before action (ms)	—
2	Message to send	—
3	—	Attack type: Replay, DoSK, DoSM, DoSC (case-insensitive)
4	—	Attack parameter (seq modifier or repetition count)