Every operating system has security gaps. Most never publish them.
I am publishing mine.
IONA OS is a sovereign operating system written from scratch in Rust. It has a kernel, a GUI, a blockchain protocol, a programming language, and a 140,000‑line AI running in Ring 0. It is designed to be secure by default.
But secure is a journey, not a destination.
Here is the hard list — the security issues I found in IONA OS, and what I am doing about them.
IONAFS reads and writes sectors in plain text directly to the disk. I already have a real ChaCha20‑Poly1305 engine with per‑file key derivation (fs/encrypted_storage.rs
), but it is only used for backup/distribution — not for everyday local reading and writing (fs/ionafs/mod.rs
).
Why this matters:
For a journalist or a civil servant, this is the central threat scenario: a lost device, confiscation at a border, or seizure. What I'm doing about it:
Integrating encrypted_storage.rs
into the normal IONAFS read/write path. Every write will be encrypted automatically. The key will be derived from a PIN or TPM.
delete_file()
removes only the index entry. The data sectors remain on the disk, recoverable with standard forensic tools.
Why this matters:
For users with high security requirements — journalists, activists, government officials — this is a critical gap. What I'm doing about it:
Adding a `shred()`
function that overwrites the data sectors with random patterns before releasing them, with a configurable number of passes.
security/keystore.rs
pretends to use AES/ChaCha in its comments, but the actual implementation is a simple XOR stream — trivial to break once an attacker has access to the disk.
Why this matters:
This is a critical vulnerability. XOR is not encryption. If an attacker has access to the disk, they can recover the keys.
What I'm doing about it:
Replacing the XOR stream with real ChaCha20‑Poly1305 encryption, properly key‑derived and authenticated.
The 3‑hop circuit exists conceptually in net/onion.rs
, but the relay list is hardcoded with fake IPs, circuit building is just a 500ms before marking it active, and the per‑hop key is keccak256(node_id)
— deterministic, not negotiated. There is no real key exchange with any relay.
Why this matters:
If a user believes they are sending data through a real anonymous circuit, they are actually sending it without any anonymity protection. What I'm doing about it:
Either implementing a real circuit with per‑hop key exchange, or removing the feature and being transparent about it.
Zero results for "duress" in the entire codebase. If a journalist or civil servant is forced to unlock the device, there is no second code that shows a fake profile instead of the real data.
Why this matters:
For users who may be coerced into revealing their device, this is essential. What I'm doing about it:
Adding a duress password that decrypts a fake volume, similar to VeraCrypt — two passwords, two volumes.
Nothing equivalent to a VeraCrypt hidden volume. The only results for "decoy" are a honeypot oriented towards attackers (ai/honeypot.rs
) and drone command decoys — nothing for plausible deniability of the user's own data.
Why this matters:
Users with high risk profiles need to be able to deny the existence of certain data.
What I'm doing about it:
Adding a hidden volume that can be mounted with a separate password.
The boot measurement is now real (it actually hashes the entry point + .text, not a constant placeholder — corrected in this session), with a software TPM (security/secure_boot.rs
) and a root‑of‑trust gate. But there is no signature verification of the UEFI boot, and hardware TrustZone/Knox attestation is explicitly a stub that returns false.
Why this matters:
Without signature verification, a compromised boot can still load a tampered kernel.
What I'm doing about it:
Adding signature verification with a public key embedded in the firmware, and investigating hardware attestation options.
memory::scrubber::scrub_all()
— called by both emergency wipe paths — zeroizes only the CPU registers, even though the log claims "wiping sensitive memory". Key zeroisation depends entirely on keystore::lock()
.
Why this matters:
If a device is seized while running, sensitive data may remain in RAM. What I'm doing about it:
Implementing a function that zeroizes all memory pages before shutting down.
ai/source_protector.rs
zeroizes EXIF fields by searching for literal markers (GPS, Author, Model...). This is functional, but can miss fields not covered by the format, unlike a real EXIF/XMP/IPTC parser.
Why this matters:
A user who believes their metadata has been removed may still have sensitive information embedded in their files.
What I'm doing about it:
Using a real metadata parser (e.g., the `exif`
crate in Rust) for accurate cleaning, while keeping the pattern scan as a fallback.
This list is not a sign of failure. It is a sign of maturity.
Most operating systems do not publish lists like this. They hide their security gaps. I am publishing mine because:
My priorities:
shred()
function.If I fix all of these, IONA OS will be one of the most secure operating systems in the world.
If you are a security researcher, a kernel developer, or just someone who cares about sovereign computing, I would love to hear your thoughts.
**Website:** [iona.zone](https://iona.zone)
**GitHub:** [github.com/Ionablokchain](https://github.com/Ionablokchain)
I'm building this alone. 13 years of research. Every line is written from scratch. And it works.