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.
1. The filesystem is not encrypted at rest
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.
2. Deleting a file does not destroy it
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.
3. The keystore uses XOR, not real encryption
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.
4. The onion routing is a UX simulation, not real anonymity
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 pause 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.
5. No duress password with fake content
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.
6. No hidden / deniable storage
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.
7. Secure boot measures hashes, not real signatures
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 bootloader, and hardware TrustZone/Knox attestation is explicitly a stub that returns false.
Why this matters:
Without signature verification, a compromised bootloader 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.
8. Memory wiping does not touch the heap
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.
9. Metadata cleaning is a pattern scan, not a real parser
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.
The big picture
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:
- I understand the real threats — not just theoretical vulnerabilities, but concrete scenarios (confiscation, border, seizure).
- I am willing to be transparent — I do not hide problems; I acknowledge them and fix them.
- I am building for real users — journalists, civil servants, users with high risk profiles.
My priorities:
- Real keystore encryption — replace XOR with ChaCha20‑Poly1305.
- IONAFS encryption — encrypt all writes by default.
-
Secure deletion — add a
shred()function. - Duress password + hidden volume — for coercion scenarios.
- Real onion routing — or remove it and be transparent.
If I fix all of these, IONA OS will be one of the most secure operating systems in the world.
Want to help?
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
GitHub: github.com/Ionablokchain
I'm building this alone. 13 years of research. Every line is written from scratch. And it works.
Top comments (0)