GhostTag Apocalypse is a firmware, security, and BLE simulation challenge. Students implement the protocol of an nRF52840 tag that must be found by authorized gateways without transmitting a stable identifier.

The challenge combines:

• C code for the protocol;
• SipHash-2-4 for ephemeral identity and authentication;
• Zephyr firmware for nrf52840dk/nrf52840;
• Renode simulation with multiple boards and a positional BLE environment;
• Automated validation, HTML report, and execution in Kubernetes.

This is a hackathon challenge, not a complete protocol for a real product. It does not fully cover secure provisioning, key protection, replay attacks, radio certification, or a complete privacy evaluation.

Status verified on 2026-07-15:

The BLE payload is exactly 28 bytes:

The packet does not contain the stable ID of the device. The radio identity changes at every epoch, and the gateway verifies the packet using the small authorized key space of the sector.

The student receives in the browser:

• firmware/ - Editable source;
• problem/ - Challenge statement;
• output/ - Logs, results, and HTML report;
• Run button - Starts the validation pipeline;
• Results panel - Displays output/report.html.

Data is kept on the user's PVC. A scenario change archives the previous workspace. PVCs must not be deleted during the challenge or at rollback.

Every Run executes, in order:

1. Native C17 compilation with -Wall -Wextra -Werror;
2. Known SipHash vectors and tamper tests;
3. Zephyr build for the tag firmware;
4. Zephyr build for the trusted gateway;
5. Renode sector generation;
6. Starting the nRF52840 machines in the BLE environment;
7. Collecting UART logs from gateways;
8. Fleet validation and HTML report generation.

The validator uses only the traffic observed by gateways. It does not read the student's C variables and does not inspect the tags' memory.

The showcase uses 12 independent sectors and runs a maximum of 4 in parallel. Each sector has a limit of 3 CPU and 2560 MiB RAM. These values were chosen after real testing; they must not be increased without a new capacity test.

The platform was recovered and hardened after the power incident:

• CoreDNS is functioning and resolving internal and external names;
• Cloudflare tunnel uses token from mounted file, not token in arguments;
• Tunnel credential was rotated;
• Platform frontend is healthy;
• Provisioner selects only Ready=True and schedulable workers;
• All 3 nodes have systemd in running state;
• The infinite block in plymouth-quit-wait.service was removed;
• systemd journals are persistent on all nodes.

Students only modify:

firmware/ghost_protocol.c

The student implements ghost_siphash24:

• 128-bit key;
• 64-bit result;
• Canonical SipHash-2-4 construction;
• Little-endian read;
• Correct support for lengths that are not a multiple of 8;
• Result identical to the known vectors included in tests.

An approximate implementation or with wrong byte order will not pass.

The student completes ghost_build_payload:

• Keeps the existing header and layout;
• Derives the ephemeral identity using domain 0x45, the epoch, and the sector;
• Writes the ephemeral identity in bytes 12..19;
• Derives the MAC with a different key domain than the one used for EID;
• Authenticates bytes 0..19;
• Writes the MAC in bytes 20..27;
• Does not copy device_seed into the packet.

The same raw key must not be reused directly for both roles.

The student completes ghost_verify_payload so that it rejects:

• Wrong company ID;
• Wrong version;
• Wrong ephemeral identity;
• Wrong MAC;
• Flags modified after signing;
• Any modification to authenticated bytes;
• Verification with an unauthorized seed;
• Clone packets that only respect the protocol format.

The verification must reconstruct the expected values, don`t accept a packet just because it has the correct size and header.

1. Read problem/problem.md and the comments for the 3 TODOs;
2. Implement and verify SipHash first;
3. Implement EID and MAC;
4. Implement verification;
5. Run the challenge using the Run button;
6. Fix native errors first, then Zephyr errors;
7. Analyze Renode logs only after builds pass;
8. Open or refresh the Results panel after the run finishes.

A solution is accepted only if:

• All SipHash tests pass;
• All 3 gateways start;
• All authorized tags are observed;
• Each tag changes its radio identity;
• Clone traffic is rejected;
• There are no fatal errors in the firmware;
• The validator displays GHOST_VALIDATION passed=1;
• The run finishes with GHOSTTAG FLEET SURVIVED THE APOCALYPSE.

Compiling without errors is not enough.

We monitor:

• Node and pod health;
• The Job queue for student runs;
• Image pull errors;
• CPU, RAM, and ephemeral storage usage;
• Frontend and ingress availability;
• Participants' PVCs;
• Renode execution times.

We help students with compilation errors, platform usage, and interpreting the report. We do not implement TODOs for them.

The showcase is optional and separate from student runs.

Before launching:

• Check requested resources on both workers;
• Confirm there is at least one healthy worker and enough space for the

approx. 3.76 GB image;

• Keep parallelism: 4;
• Do not delete pods or student PVCs to make room.

Launch k8s/showcase/indexed-job.yaml and monitor all 12 completions. The showcase is successful only if all 12 sectors finish successfully and each log contains GHOST_VALIDATION passed=1.

• Only delete the Showcase Job if it needs to be stopped;
• Restore the saved ConfigMap if reverting to the previous scenario;
• Do not delete student PVCs;
• Keep reports and logs useful for evaluation;
• Check the public health endpoint again;
• Document any cluster incident or observed capacity limit.

The challenge can be opened to students when all points are true:

• [ ] GhostTag image is built from the desired commit;
• [ ] Reference smoke test passes;
• [ ] Image tag is confirmed in the registry;
• [ ] All required nodes are Ready;
• [ ] Frontend and DNS are healthy;
• [ ] Manifest dry-run passes;
• [ ] Previous scenario state is saved;
• [ ] GhostTag scenario is active;
• [ ] Starter fails in a controlled manner for the disposable user;
• [ ] Reference passes for the disposable user;
• [ ] HTML report loads in Results;
• [ ] Rollback is prepared;
• [ ] Reference solution is not accessible to participants.

At the time of writing, the first two remaining operational actions are build/push for the image and controlled activation of the scenario. The showcase must not be launched before the disposable test.