SecureSense

SecureSense is a local-first physical tamper-awareness system for edge devices. It runs a compact sensor-fusion model on an Arduino Nano 33 BLE Sense and reports security decisions to a local monitoring console.

What it monitors

The deployed system uses two onboard sensing subsystems:

• LSM9DS1 IMU — acceleration, movement, vibration and relocation patterns.
• APDS9960 — clear-light and proximity changes associated with enclosure opening or close physical interaction.

The final model does not use temperature, camera or microphone data. Acoustic sensing was evaluated only as a separate hardware diagnostic and was excluded from the deployed classifier.

How it works

Nano sensors at 20 Hz
        ↓
1-second non-overlapping window
        ↓
45 deterministic IMU + APDS features
        ↓
100-tree binary random forest
        ↓
5-window temporal vote + light-range safeguard
        ↓
Built-in LED + USB Serial JSON
        ↓
Local SecureSense security console
        ↓
Optional rate-limited phone notification

The Arduino makes the security decision. The dashboard is a secondary visualisation and evidence-logging layer; it does not perform inference in final device mode. Optional phone alerts are generated only from stable device-mode state transitions and contain no raw sensor telemetry.

Measured prototype performance

Measurement	Result
Held-out Session 3 accuracy	83.33%
Held-out Session 3 macro-F1	0.8324
Controlled live raw accuracy	81.67%
Controlled live 5-window accuracy	86.67%
Mean on-device model inference	236.68 µs
Maximum on-device model inference	275 µs
Flash use	120,840 bytes (12%)
Global dynamic memory	46,656 bytes (17%)
Python/C++ class parity	720 / 720 windows

These results describe controlled prototype conditions. They do not establish field reliability or certification for security-critical deployment.

Repository map

arduino/                    board diagnostics and final embedded inference
dashboard/                  local Flask security console
data/                       collection tools and curated session splits
models/                     training, export and parity verification
results/                    measured evaluation and deployment evidence
tests/                      C++ parity runners
docs/                       architecture, model and security documentation

Quick start

1. Prepare the Python environment

python3 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt

2. Compile the device firmware

arduino-cli compile \
  --fqbn arduino:mbed_nano:nano33ble \
  arduino/04_final_inference

Connect the Nano and discover its current port:

arduino-cli board list

Upload the firmware using the reported /dev/cu.usbmodem... port:

arduino-cli upload \
  --port /dev/cu.usbmodemXXXX \
  --fqbn arduino:mbed_nano:nano33ble \
  arduino/04_final_inference

3. Start the console in final device mode

Close Arduino Serial Monitor first, then run:

source .venv/bin/activate
python dashboard/app.py \
  --mode device \
  --serial-port /dev/cu.usbmodemXXXX

Open http://127.0.0.1:5001.

For interface development without hardware:

python dashboard/app.py --mode replay

Replay mode is clearly identified as host inference in the console.

Reproduce the evaluation pipeline

python models/train_binary_security_models.py
python models/export_binary_random_forest.py
python models/verify_binary_forest_parity.py
python models/verify_feature_pipeline_parity.py
python models/evaluate_light_safety_override.py
python models/evaluate_online_predictions.py

The repository includes the processed feature table and session-separated splits needed for model training. Original raw recordings remain private; capture_serial.py and build_features.py support collecting and processing a new local dataset.

Security and privacy

• inference is local in final device mode;
• raw sensor streams are not sent to a cloud service;
• the final model contains no audio, image or temperature features;
• the local SQLite event store is capped at 2,000 decisions;
• confidence values are model vote proportions, not calibrated probabilities;
• the system is a research prototype, not certified security equipment.

See architecture, model card and security notes for the technical boundaries. The optional phone gateway has a separate verification record.