Android - verity discussion

One of the most compelling reasons to use security focused custom Android ROMs is because of dm-verity - all files under /system are made sure to not be modified at boot time, preventing malware with root access as well as evil maid attacks. However, one very important downside is hardware support - usually only Pixels or OnePlus device support verity with ROMs signed with a different signature than that of the OEM.( This eliminates a lot of the custom ROM userbase, leaving them vulnerable to the previously mentioned attack scenarios. I was wondering if it would possible to verify the integrity of files(reliably) under /system *after* boot time. This would remove the hardware dependency on the OEM to properly implement the AVBv2 specification. Or even a way to check integrity *at* boot time would be nice as long as we don't need to depend on the OEM for verity checks. Now we could just encrypt /system but that wouldn't deter root malware - we won't know of its presence at the next reboot at all. On a proper Android device with verity, it would either fail to boof or at least warn that verity failed. My idea so far - add a helper program that checks integrity under /system. Clearly, anyone could just modify the helper binary - since the bootloader is unlocked and so can root malware. Your ideas?

>>17526 >ROMs signed with a different signature than that of the OEM my problem with here is what if it still accepts something signed by systemG (either by an attacker or some actor) and proceed to boot with zero problems and then proceed to modify your system, and replenish the custom signed boot? I might be misremembering here but I think the graphene boot was signed by systemG and that doesn't mean anything secureboot which already have something like golden key and "trusting something that's signed" is a bad model. and I'm highly suspicious of the phone hardware too even the chromebooks are all sus if you know what I mean https://web.archive.org/web/20210913200639/http://www.loper-os.org/?p=2433 >all files under /system are made sure to not be modified at boot time, preventing malware with root access as well as evil maid attacks true but doesn't disallow them to just yank all your files and image your entire phone in seconds now with UFS (or faster versions of eMMC) and then proceed to bruteforce that pattern lockscreen with a modified unlocker system because why not and they have it. now that's a different scenario since I'm just questioning the "encryption" properties here instead of infiltration. android encryption already fails since everything is unlocked the moment you boot up, wallpaper is loaded, apps are loaded, literal flaw and there used to be this one bypass method to just crash system UI and you could skip the lock screen. dunno how graphene does it maybe different? I wouldn't know and I doubt it's been ironed out properly maybe it is somehow but I doubt that as even something like windows lock screen could be easily "crashed" the same way too. asdfgdfgshszdfhd

>>17527 >my problem with here is what if it still accepts something signed by systemG (either by an attacker or some actor) and proceed to boot with zero problems and then proceed to modify your system, and replenish the custom signed boot? I might be misremembering here but I think the graphene boot was signed by systemG If I am not mistaken, it would still perform verity checks. Also, no, I think GrapheneOS is signed by the dev thestinger. >secureboot which already have something like golden key and "trusting something that's signed" is a bad model. Agreed. Most modern PC/Laptops, however, allow changing the root of trust. >true but doesn't disallow them to just yank all your files and image your entire phone in seconds Modifying files under /system and being able to read files under /data are different things. Most modern phones these days are encrypted by default, and so is GrapheneOS I think. Apps aren't loaded completely. >https://source.android.com/security/encryption/file-based#Direct_Boot >With the introduction of file-based encryption (FBE) and new APIs to make applications aware of encryption, it is possible for these apps to operate within a limited context. The apps have to be "encryption-aware", i.e, they have to opt-in to it. >bruteforce that pattern lockscreen with a modified unlocker system Don't exactly understand what you mean but by "they", if you mean the OEM, yeah encryption is useless if the modify the part of android that handles unlocking and encryption. But lets assume the ROM is trusted. If I am not mistaken, they key is generated on first boot, and the another key derived from the pattern/password is used to encrypt this key. So I don't think they would bruteforce the pattern lock. >asdfgdfgshszdfhd kek. But seriously, if we had such a system to implement verity after boot, it would be pretty lit.

>>17529 I've tried crashing the pattern lock screen before (bugs are good for exploits as they say), there's also an older method where you just put emergency number, copy a sequence of numbers you typed, paste paste, copy and repeat until the input text overflows causing the lockscreen to just give up. A funny bug. Bruteforcing pattern lock screen I think could be done if they have 1:1 copy of your entire system (the modified part is just to increase/optimize the speed like with dmcrypt cracking they use modified iteration time) and in which case they need the help of a special chip somewhere in the device maybe baked in the cpu? I think if the device has usb host that's already just as worse or good for them (usb direct memory access attacks or maybe emergency download mode). this is saying that even with a secure system if some port is insecure they will just use that to defeat your "conventional" security methods and bypass security. A literal backdoor. The best way then would be not with another "security implementation and verification" and to just seal or break that usb port which is the only way for them to have doors over your device, remove the door. And you're only left with if whether they confiscate your device or open it up but you can strengthen such by using a custom case or removing any other input, you could say the only input peripheral device now is just your touch screen which is userspace, can't let them go into ring negatives and using backdoors over usb host so what you do, just remove the damned usb port, make it a charging port, make it a usb killer, make it a self-destruct switch. I think lightning port is what made apple phones cool, it didn't use the "standard" that is usb so it gave spies and agents a lot of head ache that they needed a full stack backdoor preinstalled through negative day backdoors to break your security.

We need smartphones where the touchscreen, system-on-chip, charging port, microphone, video cameras, network-interfaces, battery, and platform security chips (like Google's Titan security chip), are all physically separate and can be replaced separately. We need an ATX standard for phones much like there is an ATX standard for desktops. We don't need separate companies each making redundant incompatible unicorns filled with backdoors that openly refuse to run the software stacks the users want to actually run. I don't care if the phone is 1" in thickness instead of 1/4 inch ; it's a phone, not a dildo for consoomer purposes. Anyone who looks at a handheld computer as a fashion item deserves to die in a COVID concentration camp, good f_ucking riddance.

>>17526 How hard is it to make a computer that explicitly reads OS bootloader and encryption keys from easily detachable external drive having only stateless memory (dynamic RAM) on it's system board? Raspberry Pi manages to boot from removable SD card, why can't smartphones, why do we need this security theater of proprietary """trusted""" memory chips and biometrics mumbo jumbo? Why aren't all Android smartphones using plain dm-crypt on all memory? BTW, making stolen smartphones non-reusable contributes to electronic waste, why aren't Apple and Samsuck sued for this by UN or whoever is in charge of le environment protection?

>>17875 >to make a computer We already have such computers, I think you mean smartphones. >why do we need this security theater of proprietary """trusted""" memory chips and biometrics mumbo jumbo? I am no security expert. The biometrics stuff, yeah, for normal people to use their fingerprints. As for the """trusted""' memory chips I think this might be because - 1. Maybe it isn't (completely) security theater. Assuming you mean TPMs, they have genuine security purposes. 2. DRM - Digital Restrictions(or maybe Rights) Management, without which normal people won't be able to play their 4k Netflix TV shows. >BTW, making stolen smartphones non-reusable contributes to electronic waste, why aren't Apple and Samsuck sued for this by UN or whoever is in charge of le environment protection? Not sure about Applel products, but Samcucc products can be gotten past FRP, assuming that's what you mean? There are a lot of XDA threads on this. Also, the amount of stolen phones going to waste is probably too insignificant for the UN/whoever responsible to care about. >Why aren't all Android smartphones using plain dm-crypt on all memory? ?. You mean use verity on /data and /sdcard? That would decrease performance heavily. >>17871 and >>17875 I am sure you are aware of the Fairphone. Since you seem to support the idea of such hackable phones, maybe help them in some way (other than money)?

>>17875 >Raspberry Pi manages to boot from removable SD card, why can't smartphones Because smartphones are for people who want to buy with all the software installed and it just works. It's not for 1337 h@x0rs like you. >Why aren't all Android smartphones using plain dm-crypt on all memory? You can't boot if everything is encrypted. You need some code the run first which will decrypt the rest of the system. >why do we need this security theater of proprietary """trusted""" memory chips and biometrics mumbo jumbo? This is the secure the the code that runs first and decrypts/verifies/boots the rest of the system. Otherwise someone can replace it with malware.

>>17902 >software installed and it just works. Include SD card with separate bootloader and compressed system image that installs OS and encrypts everything upon first boot, literally same next-next-next sequence as signing for google account. Did you read the attached PDF? >You can't boot if everything is encrypted Do not pretend to be an idiot, you know what he meant. Android does not encrypt the SD storage, and have dropped full file system encryption in favor of file encryption which leaks ton of metadata to anyone who gets a hold of device unlike regular full drive encryption. >someone can replace it with malware. Nobody can replace it with malware if It's read-only and I know how to verify it's integrity, and I can separate it from the rest of the device when I'm not using said device.

>>17909 >why don't they just <complicated process> Because consumers don't value the output enough to pay the extra cost. >Android does not encrypt the SD storage, Probably because users expect to be able to pull it out and mount it on their PC or another phone. >dropped full file system encryption in favor of file encryption which leaks ton of metadata to anyone who gets a hold of device unlike regular full drive encryption. Phones are always powered on so "regular" full disc encryption is not useful anyway. >Nobody can replace it with malware if It's read-only and I know how to verify it's integrity, and I can separate it from the rest of the device when I'm not using said device. Good for you. You are not the target audience of these devices though.