Signed, hashed and timestamped Rust cdylib plugins meet NIS2 performance and evidentiary requirements.
Evidence within the context of a cdylib plugin
- authenticity: binary signed with a unique UUID v4;
- integrity: SHA-256 hash detects any post-deployment modification;
- traceability: Cargo manifest includes crate-type=["cdylib"] and version;
- timestamping: TSA service applies a certificate guaranteeing the exact date;
- attribution: metadata.authors and BUILD_ID fields contain the developer identifier.
Crates and cryptographic primitives
| Crate | Role |
|---|---|
| zeroize (1) | Secure erasure of private keys in memory |
| sha2 (0.10) | SHA-256 digest for integrity proof |
| uuid (1) v4 | Unique identifier per build |
| ring (0.16) | RSA / Ed25519 primitives for code signing |
These crates are audited and maintained in line with NIS2 quality requirements.
What an auditor will seek to verify
- each .so or .dll binary has a unique and immutable UUID v4;
- signed SHA-256 hash from a recognised key appears in the manifest;
- timestamp originates from a qualified TSA (RFC 3161);
- secrets used during compilation are zeroised immediately;
- binary stored in WORM mode with an appropriate retention policy.
Chain of custody for a cdylib plugin
Cargo compilation with metadata (UUID, Cargo version, Git commit). SHA-256 hash sent to the TSA. Deposit in an S3 Object Lock bucket (Compliance mode). Tags type=plugin, retention=7y. Restrictive IAM access control. Daily verification: hash calculation and comparison with the recorded value. Audit export as a signed ZIP archive containing binaries, metadata, and validation report.
Limitations not to be overlooked
- immutability does not eliminate erroneous generation at the source;
- source quality is paramount;
- local vs qualified timestamping: only the latter carries legal weight;
- the cost of WORM and TSA services can be significant for SMEs.
Further reading
Further reading:
Read the Challenges article on KARL →
KARLStorage that remembers.