FORUMS
Remove All Ads from XDA

The TWRP Password Protection Thread

2,658 posts
Thanks Meter: 4,440
 
By Lanchon, Senior Member on 2nd January 2015, 06:00 AM
Post Reply Email Thread
8th January 2015, 02:49 AM |#11  
Member
Thanks Meter: 26
 
More
Thank you very much for this call, I highly appreciate it! Me, I consider securing Recovery also very essential, but instead of coding a patch I would like to contribute the overall discussion:
  • having a locked bootloader normally restricts you to booting a stock kernel without a bootloader-valid signature, right? Otherwise you could simply fastboot any kernel without flashing. But this can be an issue in case your kernel is outdated and has other security flaws which e.g. make it vulnerable from remote. In this case, you secure your device from offline attacks but stay vulnerable to online attacks. The hard questions is: which attacks are more realistic?
  • in "good old cm7 times", maniac103 implemented a password-protected CWM for the Motorola Defy which was based on entering a password sequence using the sensor keys (back, home, search etc.). See this commit.
  • many people argue against Android encryption because it is based on the "same password as for the screen unlock". This is essentially not true: It's just the front-end in almost all Stock ROMs which does not support it - the back-end does. You can set a much stronger passphrase for protecting your encryption key using comand line or a tool like this or this (both require root, stupid!). You still suffer from the hardcoded limitations in crypt.c (like only 2000 rounds, just 128bit AES, maximum 16 char limitation etc.) but much better than having just a numeric PIN! Please note that Android 5.0 also tries to store the encryption key in a more secure location than the footer of the disk partition as outlined here.
  • Even if you could overcome a TWRP password on a bootloader-unlocked device easily by fastbooting a different boot image, it still raises obstacles for a "stupid" attacker (e.g. you need a device with USB and not just a microSD card or USB drive+OTG cable). Although I would still consider it "security by obscurity", in essence, it's going in the same direction as JTAG also being hard(er) to exploit.
  • The same argument accounts for "dumping your encrypted partition and installing a sniffer" - it raises the barrier and the victim will likely notice that something is wrong (unless it's using a device that's unstable...) because the device will be off or rebooted. A counter-measure would be: if you find your device in such a state, boot into recovery and compare checksums of your boot and system partitions - probably many even more advanced attackers will probably forget to install rogue versions of md5sum/sha256 etc, and of course you could also carry a write-protected USB drive+OTG cable with a clean boot image, provided TWRP would allow you to boot from that (which afaik it currently does not).
  • Considering the huge security breach of an unprotected recovery, I would consider the option to recover stuff via adb from recovery a secondary objective. A more effective approach which could help against the problem of non-recoverable data from a hardware failure would be having the data already external - like in the approach I posted in this thread where I argue against keeping private data in internal phone memory. Unfortunately, on many devices this will not work with a locked bootloader unless you manage to modify the rootfs elsewise (but I assume recoveries like Philz seem to manage it already somehow with locked bootloaders).
  • There are many other attack vectors like a memory freeze which a locked bootloader can certainly make more difficult.
 
 
8th January 2015, 09:31 AM |#12  
Senior Member
Thanks Meter: 33
 
More
For instance, if we had a tool like https://play.google.com/store/apps/d...1.bootunlocker compatible with the OPO, it would be easy to have a pretty secure custom rom.
Scenario (encrypted of course) : unlocked bootloader, TWRP to flash some stuff, back to stock recovery then lock bootloader.
Each time you need back a custom recovery, you unlock the bootloader and to your stuff.

I always did that for the Nexus 4.
8th January 2015, 01:52 PM |#13  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,440
 
Donate to Me
More
Quote:
Originally Posted by Defier525

having a locked bootloader normally restricts you to booting a stock kernel without a bootloader-valid signature, right? Otherwise you could simply fastboot any kernel without flashing. But this can be an issue in case your kernel is outdated and has other security flaws which e.g. make it vulnerable from remote. In this case, you secure your device from offline attacks but stay vulnerable to online attacks. The hard questions is: which attacks are more realistic?

thanks!

no, it does not. android reference bootloaders (nexus, opo, etc) do not check kernel signatures when locked. they just disallow flash and boot commands. your point here is void.
8th January 2015, 02:15 PM |#14  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,440
 
Donate to Me
More
Quote:
Originally Posted by Defier525

Even if you could overcome a TWRP password on a bootloader-unlocked device easily by fastbooting a different boot image, it still raises obstacles for a "stupid" attacker (e.g. you need a device with USB and not just a microSD card or USB drive+OTG cable). Although I would still consider it "security by obscurity", in essence, it's going in the same direction as JTAG also being hard(er) to exploit.

personally i do not consider connecting the device to a host being any kind of bar raising at all. it is the realm of script kiddies and the standard way stolen phones are reset and/or returned to stock when they have a screen lock.

JTAG, on the other hand, is. it requires physically disassembling the phone and maybe modifying the board. it requires hardware and software tools that are not in the arsenal of the usual adversary. (i am not talking about the NSA!) i have JTAG hardware and use OpenOCD for hardware development but i have never attempted to JTAG a phone and probably never will. it is just too much trouble; not worth it.

modded phones will always be a minority. as long as mainstream phones do not need JTAG after being stolen, i predict modded phones that require JTAG to be recycled will not be recycled and will be sold for parts or maybe resold to the owner at a reduced price. (the "hey, i found this phone..." scenario.)
8th January 2015, 02:47 PM |#15  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,440
 
Donate to Me
More
Quote:
Originally Posted by Defier525

Considering the huge security breach of an unprotected recovery, I would consider the option to recover stuff via adb from recovery a secondary objective. A more effective approach which could help against the problem of non-recoverable data from a hardware failure would be having the data already external - like in the approach I posted in this thread where I argue against keeping private data in internal phone memory. Unfortunately, on many devices this will not work with a locked bootloader unless you manage to modify the rootfs elsewise (but I assume recoveries like Philz seem to manage it already somehow with locked bootloaders).

i do not. i do not encrypt my phone because i would not be able to access it with a broken screen. that proposition is unthinkable for me. i use software fallbacks such as keepass. this is a matter of priorities.

also, i dont consider the sdcard hack to be a valid alternative. i will answer to your thread here (but keep in mind that even if it were a valid alternative, this thread is about securing the recovery, not about other options):

-using an external encrypted sdcard with an untrusted boot chain leaves you vulnerable to all caveats of internal encryption, plus more. eg: wiping the phone to get control of its bootloader to plant an attack does not wipe the sdcard.

-the sdcard can be trivially dumped even with a trusted boot chain in place.

-many phones today, including my last 4 phones, do not even have sdcard slots (eg, most of the "free" phones: nexuses and the opo; some GPE phones do have slots) and you can expect the number keep falling down.

-sdcards are extremely slow compared to internal flash.

-sdcards tend to use much more power than internal flash.

-sdcards tend to be unreliable.

-the FTL in sdcards is not designed to handle the constant writing android will subject /data to. most FTLs do not provide good wear leveling, specially if cards are mostly full, and as a result the cards would probably fail soon.

-ASOP encryption of /data is all that is needed since the emulated "internal sdcard" is backed by storage in /data/media since reference android 4.0

-eMMCs in phones *do* provide secure erase commands! it has been a required part of the eMMC standard for years. commands are: SECURE ERASE and SECURE TRIM, and maybe later they added a SECURE DISCARD command, not sure. furthermore, reference android recovery does use these commands while wiping a phone.
8th January 2015, 02:51 PM |#16  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,440
 
Donate to Me
More
Quote:
Originally Posted by Xoib

For instance, if we had a tool like https://play.google.com/store/apps/d...1.bootunlocker compatible with the OPO, it would be easy to have a pretty secure custom rom.
Scenario (encrypted of course) : unlocked bootloader, TWRP to flash some stuff, back to stock recovery then lock bootloader.
Each time you need back a custom recovery, you unlock the bootloader and to your stuff.

I always did that for the Nexus 4.

this is not solution. you can do this with the opo. it is trivial to use adb shell or the terminal to unlock the bootloader.

but what if android does not boot for any reason? you loose access to your phone? this is not a valid alternative for me.
8th January 2015, 03:03 PM |#17  
Senior Member
Thanks Meter: 33
 
More
Quote:
Originally Posted by Lanchon

this is not solution. you can do this with the opo. it is trivial to use adb shell or the terminal to unlock the bootloader.

but what if android does not boot for any reason? you loose access to your phone? this is not a valid alternative for me.

How do you do that with adb/fastboot without wipe ? (I mean I know oem lock / unlock but unlock implied wiping right)

For your second point, even if I lost access to the android boot, I always get fastboot screen so for me it's a pretty good alternative.
8th January 2015, 03:32 PM |#18  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,440
 
Donate to Me
More
Quote:
Originally Posted by Xoib

How do you do that with adb/fastboot without wipe ? (I mean I know oem lock / unlock but unlock implied wiping right)

For your second point, even if I lost access to the android boot, I always get fastboot screen so for me it's a pretty good alternative.

you have to change one bit. you need to be root. there are threads that discuss how to, google them.
8th January 2015, 04:28 PM |#19  
Senior Member
Thanks Meter: 33
 
More
Quote:
Originally Posted by Lanchon

you have to change one bit. you need to be root. there are threads that discuss how to, google them.

Right, but adb don't use this trick.
That's why I said it will be cool when the bootunlocker app upgrade to handle OPO address bit.
8th January 2015, 04:37 PM |#20  
Member
Thanks Meter: 26
 
More
Thank you for these comments! But could you (re-)post the arguments concerning the fitness of sdcards for /data in the other thread, please? This way we could keep the discussion more focused.

JTAG vs. fastboot: I agree with you, JTAG is a much higher obstacle for a thief and probably most will not go this way while I guess most "bring back to stock" tools work over fastboot anyways. I was just considering a different scenario, e.g. you leave your phone unattended for some minutes on a party.

Data recovery in case of hardware failure: Well this is in conflict with getting more security, unless you additionally secure adb in Recovery like you proposed...

Internal sdcard in /data/media since AOSP 4.0: This was new to me, but it seems to be implemented this way in my Nexus S. I just wonder why my Xperia V does not handle it this way then?

eMMC and secure erase: Okay this was new to me as well. But afaik, TWRP does not use these commands for wiping, does it?

locked bootloader and password protected TWRP: What if an attacker would try to fastboot erase the data or recovery partition? Will a locked, properly implemented bootloader prevent that?

My sd hack in general: I agree, that if this hack only works with a unlocked bootloader (like probably on my Sony) it is less secure than having a locked bootloader even without encryption. Therefore, I was already considering re-locking the bootloader and disabling the hack, but using at least a non-stock userland. Yet, the stock kernel will probably not see any updates anymore and thus will be vulnerable to any upcoming threats.

Yet I think that we both agree in the point, that having password protected TWRP would enhance security. Since TWRP already has all means of a password-unlocker screen in place (for dealing with encrypted /data), it should be trivial to provide a patch which asks for a password before it lets you do anything in TWRP. Maybe if I find some time I can try to see what it would take to implement it, but I am quite busy these days.

Nevertheless, I am quite interested in discussing the security of locked bootloaders and any attack vectors over fastboot in general here.
The Following 3 Users Say Thank You to Defier525 For This Useful Post: [ View ] Gift Defier525 Ad-Free
8th January 2015, 05:56 PM |#21  
Member
Thanks Meter: 26
 
More
Out of curiosity, I tried the following on my Nexus-S:

- relock bootloader using "fastboot oem lock" (worked fine, shows status locked; trying to fast-boot another kernel is refused by the device)
- boot CM11 which was already there before re-locking using the locked bootloader (worked fine as well, seems not to check kernel signatures)
- send "fastboot erase data" from locked bootloader (worked fine as well !?! phone booted to fresh data partition):

Code:
$ fastboot erase userdata
erasing 'userdata'...
OKAY [  0.272s]
finished. total time: 0.273s
Recovery - no matter if password protected or not - was not involved at all in the process. In case the phone was not encrypted, stuff in userdata would be lost but I could easily access the emulated internal storage. With some file recovery techniques, I should be probably also able to restore most stuff in userdata, since the "wipe" by "fastboot erase", which took less than 300ms, probably just wrote a new filesystem signature to the data partition without really wiping anything.

Now, if I can get root (i.e. if the previous rom was rooted already or an exploit exists) I can now easily flash a new password-unprotected recovery and revert everything back to stock. And probably so can the burglar which you wanted to lock out with password-enabled TWRP. To put it with your terms, I don't consider this for the list of "other phones which actually make an effort to defend your data. "

Since you counted all Google Nexus devices in your whitelist of "secure phones", can you please confirm that newer devices like Nexus 4, Nexus 5 or OnePlus One are not affected by this vulnerability?
Post Reply Subscribe to Thread

Tags
twrp security password

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes