{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreievwlbzyhiho6whc4iywhyulqxtsvdrep6hqvwte45kvepha6sjsy",
    "uri": "at://did:plc:34cg4tn4iwemk3v5k3n3adwf/app.bsky.feed.post/3mnmek3rsoop2"
  },
  "path": "/t/smartphones-are-not-safe/34004?page=5#post_89",
  "publishedAt": "2026-06-06T09:43:49.000Z",
  "site": "https://forum.f-droid.org",
  "tags": [
    "confidenseuide",
    "@confidenseuide"
  ],
  "textContent": "by confidenseuide\n\n> ## **post by confidenseuide on Jan 31**\n>\n> This message will probably give you think.\n>\n> Have you ever considered how easy it is to hack your smartphone? Very easy. Cellebrite can easily access your data in AFU state, and sometimes even in BFU, as in the case of the Serbian activist. Oh, you think Isolated security chip protects your data? This damn chip only stores the keys, but if you trick it into thinking you’ve entered the correct password, it will give them away. Your files are NOT encrypted with your password, which only you know.\n>\n> Entering the correct password is just a message to the chip to give up ITS own keys, and these are the keys responsible for encryption. If you trick it into giving up the keys, you can get all data.\n>\n> If phones had double encryption: the first layer is your password, and only the second is the chip key, then a phone in BFU would be completely invulnerable if you have a strong password, since it wouldn’t be stored anywhere, unlike the chip key, and it wouldn’t be accessible. But manufacturers did differently.\n>\n> You don’t control the encryption. Your password merely signals the chip to release its own keys. The encryption layer is sole. Special agencies will inevitably be able to hack the phone. Even the most secure isolated chip will eventually be compromised by Cellebrite. Sure, you can defending against attacks. But, blocking the USB stack, as GrapheneOS does, is a workaround. The system encryption itself needs to be redesigned, and DirectBootAware mode (introduced by Google), which allows application components to run and variables to be stored outside of encrypted storage, needs to be eliminated. File Based encryption (introduced by Google) also needs to be removed and Full Disk Encryption needs to be restored, as with FileBased Encryption, some system services can be loaded before first unlock. Separating profiles and encrypting them with separate keys is certainly a good idea, but it also expands the attack vector. When system services are running in one profile or on the lock screen, they can be infected, and the next time a password is entered, the data for everyone else can be compromised.\n>\n> I remember on my old phone, when using Full Disk Encryption and the system encryption feature, the entire system required a password to decrypt after a reboot, and even the lock screen contained nothing but a password entry field. No wallpaper, no time, everything was encrypted. Yes, of course, the old encryption as PROTOCOL was weaker than modern ones, but FullDisk Encryption as encryption TYPE itself was better than File Based Encryption.\n>\n> For me, the ideal scheme is when encryption is one that uses not only the chip key but also the user’s password, which is stored nowhere except in RAM while the user is using the phone. That’s double encryption. And the RAM keys, whether the chip key or the password, should be erased after each screen off, not just after a reboot. And of course, after each screen off, the entire phone, even system services, remains encrypted (Full Disk Encryption), leaving fewer attack vectors.\n>\n> You might say that File Based Encryption is supposedly more secure. That’s a lie. No, it’s not more secure. It’s only more secure for separating profiles, not against Cellebrite attacks. Quite the contrary, the threat level has become significantly higher. This is a compromise on security for the sake of convenience. Or perhaps Google is simply collaborating with special agencies. Just like phone manufacturers. For example, how can you explain why they don’t encrypt data using your password? Why your password this is not key, but the key is stored where it can be accessed? The only thing outsiders can’t access is what’s stored in your head.\n>\n> Even if a password is used to create a key, that may be on modern devices, if that key is ultimately stored somewhere permanently, it is a threat. The password must be a separate layer of encryption and temporarily be stored only in RAM.\n\n@confidenseuide I am sorry to be rude, but you are spending too much time in the anonymity area of “privacy” and not enough learning about any of it.\n\nYou don’t know the uses. You read so much you actually think someone is out there, possibly going to steal your phone.\n\nI am a data privacy law attorney who works on product counsel for maximum data security, compliance, and safety for consumers. I make sure that an app is built with that in mind.\n\nGuess what? It’s a joy, because I also used to be a developer and back end engineer before law school,. I didn’t have a password manager, I logged into 0 sites, and I didn’t register for much.\n\nPhones have made our lives fantastic at getting things done and use – and it is great.\n\nBut it also has to be secure. Instead of thinking about how to make that happen for 99.999% of users who will RELY on this security without EVER wanting to think about it….\n\n…you are worrying yourself about it as if you were the most vain man in the world.\n\nThe **hubris** to think someone is going to steal your phone and suddenly “Cellebrite can easily access your data in AFU state, and sometimes even in BFU” is **not something you will ever have happen to you.**\n\nYou are in a state of over-worrying about something you actually are not well read up on.",
  "title": "Smartphones are not safe"
}