Originally Posted by Dees_Troy
The features you're asking for will likely only be used by a tiny subset of users on a small subset of the overall devices that we support. The number of devices that allow you to relock the bootloader and still allow you to boot an unsigned image is basically just Nexus devices and the OPO. The number of users that need / want the feature you're requesting is very small, probably less than 20 people.
The amount of time and effort needed to properly implement what you are requesting is not small. Finding a safe location and method to store the password will hardly be trivial. We need to make sure that adb is completely disabled until after the correct password is entered, otherwise an attacker would be able to use adb to bypass most of the security measures. We cannot safely store the password anywhere in /data because the data partition may be encrypted and thus not accessible.
You still haven't come up with a solution to a fastboot erase command that I believe still works on Nexus and probably the OPO devices even if the bootloader is locked. As I said in my write-up, your best case scenario if someone else gets hold of your phone is that they don't get access to your private data.
You might be able to enter a password on a device with a broken display using a USB keyboard and USB OTG cable. As mentioned earlier, leaving adb running leaves a humongous gaping security hole open that basically makes all of your arguments for better security null and void.
The fact that you don't encrypt your device and the fact that you aren't willing to do the development yourself tells me you aren't that serious about security.
I guarantee you that I have thought about this subject way more than you have. It's extremely unlikely that you're going to win this argument, and even if you "win", it's extremely unlikely that I'm going to develop this feature for you as part of regular TWRP development because of the limited benefit to the overall project. I do take contract work though, on occasion if it is something that you're serious about. It's not cheap though.
Also, for the record, the Nexus S does NOT have unified storage. You can get unified storage on the Nexus S using lvm and some other "hacks", but in stock form it does not have unified storage.
hi and thanks for answering! and for TWRP too
i absolutely understand the cost vs. return argument, i only wrote this thread because i didn't agree with the "we shouldn't do it because it's useless" stance as a way to trigger constructive discussion, such as this here.
as an option to where to store the password:
last sector of the recovery partition: a header plus integrity checking at the end of the sector (that could be the same hash function used to store the password). on init, the recovery reads the last sector of the recovery partition. (that shouldnt cause a problem in fastboot boot scenarios.) if the sector doesnt pass header/integrity checks, continue booting. otherwise ask for a password if the payload section of the sector has a password hash in it.
downside: susceptible to induced glitching attacks during the sector read. workaround (far from perfect): read the sector twice (bypassing caches) and fail to boot if the reads differ. (real workaround: die hard enthusiasts can build their own TWRP that fails to boot if the sector fails the checks.)
the fastboot erase vuln: this should be fixed by google if it wasnt ages ago. they can easily fix bootloaders in the field too. i will try to investigate this and post results here.
usb: well, because i always used patterns to unlock, i never thought i could encrypt the phone with a password then use a usb keyboard to decrypt. this is so simple it's brilliant!
do you know if this would work while booting standard encrypted android? would the kernel connect usb keyboards before mounting data? (for sure BT keyboards wouldnt work.) if this works i would encrypt my phone.
yes, i stated in post #2 that adbd and mtpd have to remain disabled before auth of course. or some new adbd mode could be used to get the password. or maybe a completely independent, hacked adbd binary could do it; that could make maintenance of standard adbd easier.
lol, i AM serious about security! im paranoid about my printers getting worms!
really, i am serious, so much so that my phone doesnt keep anything of value outside of my keepass vault. it is protected by a 30 or so character passphrase that cannot be dictionary attacked. you should see me typing that phrase to unlock my laptop harddrive in public places such as airports: im so wary of cameras filming my figer movements, you'd think im scheming to blow something up, its ridiculous!
on the realistic side, with the opaque baseband owning the phone, connected to everything, and presumably full of vulns, no phone can really be trusted. phones will never be a trusted device for me.
yes, the first /data/media nexus was the galaxy nexus. the cutoff was probably at android 4.1, not 4.0 as i previously stated, i dont really remember.