{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreide7wbaw6cnehi2ncll2fqlvw7trgmnaniqlbqzabbg7b7xfphove",
    "uri": "at://did:plc:34cg4tn4iwemk3v5k3n3adwf/app.bsky.feed.post/3meg6e3ei46e2"
  },
  "path": "/t/smartphones-are-not-safe/34004?page=2#post_27",
  "publishedAt": "2026-02-09T08:34:52.000Z",
  "site": "https://forum.f-droid.org",
  "textContent": "### Where the author is correct\n\n**1. There is no absolute smartphone invulnerability**\n\nYes. Any mass-market device will eventually get exploits—through SoC, Secure Enclave / TEE, USB stack, baseband, DMA, etc. Cellebrite, GrayKey, and similar tools really work, especially in AFU.\n\nThis is undisputed.\n\n**2. AFU is the most vulnerable stage**\n\nAlso true.\nOnce a phone has been unlocked at least once after boot, some keys are active, services are running, and the attack surface is huge.\n\nThis is exactly why GrapheneOS cuts USB access, reduces the attack surface, introduces auto-reboot, etc.\n\n**3. File-Based Encryption is a convenience compromise**\n\nCorrect, with nuances.\nFBE was indeed introduced to support:\n\n  * Direct Boot\n\n  * Alarms\n\n  * Phone calls\n\n  * Services running before device unlock\n\n\n\n\nIt is a trade-off between UX and security, not a “pure win” for security.\n\n**4. The user does not directly control the keys**\n\nYes.\nYou do not “enter the key” yourself. Instead:\n\n  * you enter a password\n\n  * it participates in derivation\n\n  * the Secure Element decides whether to release the CE keys\n\n\n\n\nThis is an accurate description of the trust model.\n\n* * *\n\n### Where the author is mistaken or oversimplifies\n\n**1. “Your password does not participate in encryption”**\n\nThis is incorrect.\n\nOn modern Android:\n\n  * password → scrypt / Weaver\n\n  * used to derive keys\n\n  * without the password, the Secure Element will not release CE keys\n\n\n\n\nThe password is not just a “signal”; it **cryptographically participates** in the process.\n\nThe claim “the key is stored and can simply be extracted” is a forum-level oversimplification.\n\n**2. “If the chip is hacked, the data is immediately accessible”**\n\nNot quite.\n\nEven if compromised:\n\n  * rate-limit bypass is needed\n\n  * hardware delays must be bypassed\n\n  * memory access is required\n\n  * proper boot context is required\n\n\n\n\nThis is why:\n\n  * BFU is often not compromised\n\n  * AFU is not always compromised\n\n\n\n\nThe author presents the Secure Enclave as a “cardboard lock.” This is false.\n\n**3. “Double encryption = absolute protection”**\n\nThis is naive thinking, very common.\n\nWhy:\n\n  * if the SoC is compromised → password input can be logged\n\n  * RAM can be attacked\n\n  * TEE can be attacked before key erasure\n\n  * attacks can occur before screen-off\n\n  * side-channel attacks are possible\n\n\n\n\nTwo layers ≠ magic. It only **reduces risk** , not guarantees invulnerability.\n\n**4. “FDE was safer than FBE”**\n\nThis is partly false, partly nostalgia.\n\nTrue:\n\n  * attack surface was smaller\n\n  * nothing worked before password input\n\n\n\n\nBut:\n\n  * old FDE had weak key management\n\n  * worse multi-user protection\n\n  * worse isolation\n\n  * worse rollback protection\n\n\n\n\nFBE is cryptographically stronger but architecturally more complex, and complexity = new attack vectors.",
  "title": "Smartphones are not safe"
}