03Academic dissertation

KALYX

Tamper-evident execution history with deterministic trust verification.

What it solves: Lets investigators verify whether execution logs were altered, deleted or reordered after a system compromise.
Engineering decision: Once the trust boundary is broken, the ledger refuses further appends. A broken chain is never quietly extended into a plausible-looking history.
Proof: pytest over ledger construction, replay, and break detection paths.

Python · FastAPI · Angular · Raspberry Pi · eBPF · pytest

Scope note: KALYX verifies the integrity of accepted evidence. It does not prove the original source was truthful, and it does not prevent attacks.

Repository Learning site

A hash-linked chain rolls past a verifier; a tampered record lifts out of line and breaks the link, while checkpoints anchor to an independent device.

(Case study)

How KALYX is built

Constraints, decisions and limits, in the order they shaped the system.

Use case

Post-incident review, where the first question is whether the recorded execution history can be trusted at all.

What I built

Built a hash-linked execution ledger.
Normalises and enriches execution evidence before ingestion.
Replays the chain deterministically and identifies where trust breaks.
Uses explicit trust states instead of vague risk scores.
Prevents new evidence from being appended when the existing trust boundary is already broken.
Supports CLI, FastAPI, and Angular interfaces over shared backend services.
Anchors verified checkpoints to an independent Raspberry Pi service.
Uses explainable rules rather than machine learning for behavioural detection.
Runs detection only after the full ledger has passed hash-chain verification.

Constraints

An attacker with host access can edit or delete local logs.
Verification must be reproducible by someone who does not trust the running system.
Detection has to be explainable to an investigator.

Approach

Hash-link every execution record so reordering and edits are detectable.
Replay the chain deterministically rather than scoring risk heuristically.
Anchor verified checkpoints outside the host being audited.

Architecture

Shared Python services beneath a CLI, a FastAPI HTTP interface and an Angular UI.
eBPF-sourced execution evidence, normalised and enriched before ingestion.
An independent Raspberry Pi service holding checkpoint anchors.

Key decisions

Explicit trust states over risk scores, because an investigator needs a verdict with a reason.
Append refusal after a break, so a compromised chain cannot be laundered.
Rule-based behavioural detection over machine learning, for explainability.

Limitations

Verifies integrity of accepted evidence only; it cannot prove the source was truthful.
It is not a preventative control and does not stop attacks.

What I learned

Integrity and truth are different guarantees, and conflating them misleads users.
Refusing to operate is sometimes the correct behaviour for a trust system.