{"slug": "building-a-secure-os-the-hard-list-what-i-found-and-what-i-m-fixing-in-iona-os", "title": "Building a secure OS: the hard list — what I found and what I'm fixing in IONA OS", "summary": "A developer building IONA OS, a sovereign operating system written in Rust, has published a list of security vulnerabilities found in the system. Issues include unencrypted disk reads/writes, a fake onion routing circuit, and a keystore using XOR instead of real encryption. The developer is actively fixing these gaps by integrating encryption, adding file shredding, and implementing duress passwords.", "body_md": "Every operating system has security gaps. Most never publish them.\n\nI am publishing mine.\n\nIONA 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.\n\nBut secure is a journey, not a destination.\n\nHere is the hard list — the security issues I found in IONA OS, and what I am doing about them.\n\nIONAFS 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`\n\n), but it is only used for backup/distribution — not for everyday local reading and writing (`fs/ionafs/mod.rs`\n\n).\n\n**Why this matters:**\n\nFor a journalist or a civil servant, this is the central threat scenario: a lost device, confiscation at a border, or seizure.\n\n**What I'm doing about it:**\n\nIntegrating `encrypted_storage.rs`\n\ninto the normal IONAFS read/write path. Every write will be encrypted automatically. The key will be derived from a PIN or TPM.\n\n`delete_file()`\n\nremoves only the index entry. The data sectors remain on the disk, recoverable with standard forensic tools.\n\n**Why this matters:**\n\nFor users with high security requirements — journalists, activists, government officials — this is a critical gap.\n\n**What I'm doing about it:**\n\nAdding a `shred()`\n\nfunction that overwrites the data sectors with random patterns before releasing them, with a configurable number of passes.\n\n`security/keystore.rs`\n\npretends 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.\n\n**Why this matters:**\n\nThis is a critical vulnerability. XOR is not encryption. If an attacker has access to the disk, they can recover the keys.\n\n**What I'm doing about it:**\n\nReplacing the XOR stream with real ChaCha20‑Poly1305 encryption, properly key‑derived and authenticated.\n\nThe 3‑hop circuit exists conceptually in `net/onion.rs`\n\n, 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)`\n\n— deterministic, not negotiated. There is no real key exchange with any relay.\n\n**Why this matters:**\n\nIf a user believes they are sending data through a real anonymous circuit, they are actually sending it without any anonymity protection.\n\n**What I'm doing about it:**\n\nEither implementing a real circuit with per‑hop key exchange, or removing the feature and being transparent about it.\n\nZero 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.\n\n**Why this matters:**\n\nFor users who may be coerced into revealing their device, this is essential.\n\n**What I'm doing about it:**\n\nAdding a duress password that decrypts a fake volume, similar to VeraCrypt — two passwords, two volumes.\n\nNothing equivalent to a VeraCrypt hidden volume. The only results for \"decoy\" are a honeypot oriented towards attackers (`ai/honeypot.rs`\n\n) and drone command decoys — nothing for plausible deniability of the user's own data.\n\n**Why this matters:**\n\nUsers with high risk profiles need to be able to deny the existence of certain data.\n\n**What I'm doing about it:**\n\nAdding a hidden volume that can be mounted with a separate password.\n\nThe 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`\n\n) 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.\n\n**Why this matters:**\n\nWithout signature verification, a compromised bootloader can still load a tampered kernel.\n\n**What I'm doing about it:**\n\nAdding signature verification with a public key embedded in the firmware, and investigating hardware attestation options.\n\n`memory::scrubber::scrub_all()`\n\n— 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()`\n\n.\n\n**Why this matters:**\n\nIf a device is seized while running, sensitive data may remain in RAM.\n\n**What I'm doing about it:**\n\nImplementing a function that zeroizes all memory pages before shutting down.\n\n`ai/source_protector.rs`\n\nzeroizes 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.\n\n**Why this matters:**\n\nA user who believes their metadata has been removed may still have sensitive information embedded in their files.\n\n**What I'm doing about it:**\n\nUsing a real metadata parser (e.g., the `exif`\n\ncrate in Rust) for accurate cleaning, while keeping the pattern scan as a fallback.\n\nThis list is not a sign of failure. It is a sign of maturity.\n\nMost operating systems do not publish lists like this. They hide their security gaps. I am publishing mine because:\n\n**My priorities:**\n\n`shred()`\n\nfunction.If I fix all of these, IONA OS will be one of the most secure operating systems in the world.\n\nIf you are a security researcher, a kernel developer, or just someone who cares about sovereign computing, I would love to hear your thoughts.\n\n**Website:** [iona.zone](https://iona.zone)\n\n**GitHub:** [github.com/Ionablokchain](https://github.com/Ionablokchain)\n\n*I'm building this alone. 13 years of research. Every line is written from scratch. And it works.*", "url": "https://wpnews.pro/news/building-a-secure-os-the-hard-list-what-i-found-and-what-i-m-fixing-in-iona-os", "canonical_source": "https://dev.to/ionablokchain/building-a-secure-os-the-hard-list-what-i-found-and-what-im-fixing-in-iona-os-347g", "published_at": "2026-07-12 18:13:33+00:00", "updated_at": "2026-07-12 18:45:00.717459+00:00", "lang": "en", "topics": ["ai-safety", "developer-tools"], "entities": ["IONA OS", "ChaCha20-Poly1305", "VeraCrypt", "TPM", "UEFI"], "alternates": {"html": "https://wpnews.pro/news/building-a-secure-os-the-hard-list-what-i-found-and-what-i-m-fixing-in-iona-os", "markdown": "https://wpnews.pro/news/building-a-secure-os-the-hard-list-what-i-found-and-what-i-m-fixing-in-iona-os.md", "text": "https://wpnews.pro/news/building-a-secure-os-the-hard-list-what-i-found-and-what-i-m-fixing-in-iona-os.txt", "jsonld": "https://wpnews.pro/news/building-a-secure-os-the-hard-list-what-i-found-and-what-i-m-fixing-in-iona-os.jsonld"}}