FORUMS
Remove All Ads from XDA

The TWRP Password Protection Thread

2,657 posts
Thanks Meter: 4,439
 
By Lanchon, Senior Member on 2nd January 2015, 06:00 AM
Post Reply Email Thread
The TWRP Password Protection Thread

Yes, it has been discussed to no end. People say it makes no sense. More importantly, the TWRP team says it makes no sense:
Password protecting TWRP (lockscreen)
http://teamw.in/securetwrp



I've had people ask enough for a protected TWRP that I'm creating this page as a response so I don't have to retype. If you're seeing this page, you're probably asking, "Why doesn't TWRP offer password protection?" You want to lock down your device so that a would-be theif won't be able to wipe your device to get past your lockscreen and/or so they can't wipe away that cool app you bought from the Play Store that will let you track your stolen device via GPS. Well, here's the short answer:

Nothing trumps physical access to your device. If you've lost it, there's no way that TWRP can secure it.

For a longer answer, it's very easy for anyone with just a little bit of knowledge to get around any kind of security that TWRP might have. All they have to do is flash one of the other recoveries that's available that doesn't have password protection to get around it. Most, if not all devices have ways to flash recovery without needing to boot to either Android or recovery (usually via fastboot or download mode / Odin). Quite literally the only way to truly secure your device would be to render the USB port completely unusable which isn't an option for most newer devices that don't have removable batteries. Even then most devices could still be worked with via jtag though it's unlikely that a thief will go to the trouble of paying for a jtag service on a device that has a broken USB port. (Note: I am not recommending that you purposely damage your USB port as it will also likely make it very difficult to recover your device if anything ever goes wrong!)

I also don't want to offer a lockscreen / password protection because it offers such a superficial level of protection. Users rarely read and would skip over any disclaimers that we have that indicate that any protection that we displayed indicating that their device really isn't secure. If your device has fallen into someone else's hands, your best case scenario should be that you hope that they don't get your personal data. If you don't want someone getting your personal data, use Android's device encryption and a good lockscreen.
But it does makes sense in many cases. My objectives with this thread are: to change the minds of the TeamWin team members on this matter, and to discuss the best way to implement TWRP security. I will start by answering TeamWin's post.

1) Most people just want their data safe, not their phones unusable to burglars.

It is true that nothing beats encryption. But encryption with a trivially short PIN, pattern or password is useless. Raw access to the encrypted media allows brute forcing which in almost all realistic cases will recover the key in no time. Making it hard to reach the encrypted media would in these cases provide more security than encryption itself. And in any case, this would be added security, not replacement security, and can only strengthen the system (and in common cases, by a great deal).

The security of some phones is fundamentally broken, and there is nothing TWRP can do to fix that. The only fix could come from updated bootloaders. But bootloaders need to be signed by the phone manufacturer to work (so aftermarket bootloaders are not an option), and many companies are just not serious enough to care.

Case in point: dirty Samsung. All Samsung cares about is ending your warranty if you dare install software of your choice on your own phone. It has made it impossible for developers to overcome this by actually blowing physical fuses within the phone in their bootloaders if you exercise your freedom. Their "upgrade" bootloaders also blow fuses to prevent you from ever downgrading to the more permissive bootloader that might have been in the phone when you first bought it.

They care about invalidating your warranty a lot, but not at all about your data. I can grab a stock S3, flash whatever I want (voiding warranty, or so they say because in many countries it is rightly not so) and get to your data. So it better be encrypted because Sammy is not giving a damn to defend it.

But other phones actually make an effort to defend your data. This is the case of, for instance, all Google Nexus devices, and the OnePlus One. I name these phones because these are the only mass-market phones I know that do not try to take away your tinkering freedom with threats of voided warranties, and so are the only phones I consider when buying. (No feature is worth loosing your freedom IMO.)

These phones actually fully wipe your data when you unlock their bootloaders, a required step before any flashing is allowed. This means that if I grab a bootloader-locked nexus, I can wipe it but not get to the data without the lockscreen code. Well, unless TWRP is flashed. TWRP breaks the security that Google (and others) baked into their phones.

There used to be a good reason to avoid security in the old CWM days: CWM was not touch, and much less was capable of popping up a keyboard. TWRP has gone such a long way forward that now security can be easily implemented. There is no reason to break the security of good phones just because some phones are broken.

One could disallow access to the storage media on their phone (encrypted or not) by installing TWRP with a password and then relocking the bootloader. In this way, the modded phone would be as secure as its stock counterpart. Modding your phone would not longer mean zero security.

2) It turns out that those who want to disable the burglar's ability to reset the phone and sell it can actually do it in many cases!

It so happens that bootloaders usually do not wipe the phone themselves as it is "too complex" an operation. Many times during bootloader unlocking, the bootloader boots stock recovery instructing it to 1) do the wipe, then 2) reset the bootloader lock. If the bootloader is locked and TWRP is installed in place of the stock recovery and TWRP ignores these commands (as current versions do), then there is no way to wipe the data or unlock the bootloader (and thus no way to flash a door to the system) from fastboot.

So if you:
1) setup a TWRP lockscreen,
2) keep a flashable zip that unlocks your bootloader in your phone (see boot unlock scripts),
3) setup an android lockscreen,
4) download a root app that unlocks your bootloader (see BootUnlocker),
5) and lock the bootloader,

...then you are secure. You can recover bootloader access without wiping as long as either one of rooted android and/or recovery works. But you cannot use either without going through their respective lockscreens.

This prevents access to your data, but in the case mentioned here (recovery does the actual bootloader unlock) it also prevents wipes. In this situation, it is not difficult to imagine a burglar attempting to sell you back your own phone on the cheap. Of course suitable contact info would be displayed in your lockscreen. This is even more security than was planned by Google, and not less as is the current situation with TWRP.

I know for a fact that the OnePlus One works in this recovery-invoked-to-unlock-bootloader manner, and I suspect all Nexuses work in the same way. For these phones, anti-theft can be a reality, and getting them back after a robbery, a not so improbable scenario.

NOTE: It should now be obvious why it is very dangerous to lock your bootloader unless a working stock recovery is in place. If you cannot obtain root access in either android or recovery, your recovery is custom (and thus it does not unlock the bootloader), and your bootloader is locked, then you are stuck: you will not be able to unlock your bootloader without a JTAG rig. Under some circumstances this can render your phone unrootable or effectively bricked. This is in part our objective anyway: that burglars are not able to gain control of the phone, not even by full wipe. But it can seriously backfire if you make a configuration mistake or simply forget your passwords. Keep in mind that you can make these mistakes today, without security in TWRP. Bootloader re-locking in a scenario other thank return-to-stock is an intrinsically dangerous operation that only advanced users should attempt.

3) Encryption is insecure unless the boot chain can be trusted.

An adversary that gains physical access to your phone can dump and save a copy of the encrypted partition(s) and plant a password sniffer that later forwards the password to them. You cannot trust your password to a non-tamper-evident device that can be trivially modified. The only way to protect the boot chain from tampering in today's phones is locking the bootloader and restricting access to the recovery.

Countermeasures

Some SoCs are compromised. For example, a signed USB-fed bootloader for the Galaxy Nexus has leaked into the public domain, and with it the SoC of a Galaxy Nexus can be booted entirely via the USB port. A monitor software can be loaded that can read (or write) the complete eMMC (the storage). This is possible because either TI or Samsung leaked a properly signed debugging bootloader. This is an extremely rare case because this bootloader makes you God. I think some Kindle Fires also have a similar thing. Few phones had their security broken so drastically; compromised SoCs are the exception and are very few.

Finally, the attacker could open up the phone and use JTAG to directly access the eMMC. It requires equipment and know-how and work and time, and significantly adds to the full cost of robbing a phone, eating up their profit. Probably almost all phones could be recovered by JTAG.

But of course, there are countermeasures to countermeasures. Many people have discussed damaging JTAG traces, bond wires, or even the IC itself, and some JTAG ports can be irreversibly disabled by design.

Conclusions

1) TWRP is doing nothing in fundamentally insecure phones.
2) TWRP is disabling the security of secure phones.
3) Secure phones with TWRP could be as secure as they are with stock recovery.
4) In some cases phones with TWRP can be even more secure, preventing their unauthorized wiping and reselling.
5) A barrier blocking access to encrypted media can effectively protect more than encryption itself if short keys are used.
6) Encryption is insecure with an unlocked bootloader or an open-access recovery.

We have the rationale, we have the UI, we have the keyboard, and we have the great team of programmers behind TWRP: let's get this old rat hole plugged for good.
The Following 21 Users Say Thank You to Lanchon For This Useful Post: [ View ] Gift Lanchon Ad-Free
 
 
2nd January 2015, 06:21 AM |#2  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,439
 
Donate to Me
More
Implementation Ideas

Security is never trivial to implement, so I will accumulate some points here to guide the design of a solution. Fell free to contribute.
  1. The passwords must be stored in an irreversible manner, using proven, properly salted cryptographic methods.
  2. The password store (PS) should not be accessible to apps, or else they might attack it by brute-force. In /data/media devices, if the PS is stored in /data/media/0, it should be stored with restrictive permissions such that the fuse daemon will not reflect it into world readable /sdcard. Under kitkar (and even using a permission-less real fat32 /sdcard) files could be made inaccessible under folders in /Android i think. Otherwise the /data partition could work (ugly due interactions with nandroid backups). Also, bytes reserved in the /recovery partition itself could do the trick. NOTE: nandroid backups suffer the same problem: they are world readable copies of your passwords and auth tokens. It is imperative that general solution to this problem be found for TWRP. CM's recovery places the backup files outside of '0' in /data/media which is a good solution for /data/media devices. And going forward, this type of devices should be the norm.
  3. adbd and mtpd should not start before the password is entered.
  4. It is enough to ask for password once per boot.
  5. adb on recovery is the data recovery method of choice when a screen is broken. it should be possible to enter the password via USB to enable adb and mtp with a broken screen. NOTE: by the same token, it should be possible to enter the phone encryption password via USB if any.
  6. Both the recovery lockscreen/password and android lockscreen/password could be the same, since access to android's lockscreen data is needed for encryption support anyway and thus that code is already in place. But then, forget this one password and your phone is a brick!!!
  7. If they are not the same, a way (an app) to change the password (or at least reset it) from root android should be provided.
  8. There could be an official TWRP password manager app that stores the TWRP password in its private data in /data and TWRP could read it from there. (But the interaction with nandroid backups would kinda suck.)
  9. To enter the password over USB, ideally a restricted adbd mode would ask for the password, then restart itself a la "adb root" switcheroo. So that standard adb can be used to enable adbd and another host tool is not needed.
  10. There should be some throttling down of passwords tries both via the recovery popup keyboard and via adb. If the same password is used for android and recovery, then the throttling should not be less aggressive than android's.
  11. Ideally the password hash in the PS should be stored in a way compatible with some proven challenge response authentication so that the data in the PS can support future unlock protocols that do not send the password in the clear.
The Following 3 Users Say Thank You to Lanchon For This Useful Post: [ View ] Gift Lanchon Ad-Free
2nd January 2015, 07:07 AM |#3  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,439
 
Donate to Me
More
kind invitation to read this thread:

@Dees_Troy
@bigbiff

thanks!
5th January 2015, 08:52 AM |#4  
Senior Member
Flag munich
Thanks Meter: 36
 
More
Quote:
Originally Posted by Lanchon

Some SoCs are compromised. For example, a signed USB-fed bootloader for the Galaxy Nexus has leaked into the public domain, and with it the SoC of a Galaxy Nexus can be booted entirely via the USB port. A monitor software can be loaded that can read (or write) the complete eMMC (the storage). This is possible because either TI or Samsung leaked a properly signed debugging bootloader. This is an extremely rare case because this bootloader makes you God. I think some Kindle Fires also have a similar thing. Few phones had their security broken so drastically; compromised SoCs are the exception and are very few.

All MediaTek SoCs can be considered compromised, for every single one of them allows the entire ROM to be read back and reflashed using spFlashTool, even with a "locked" 2nd stage bootloader. Furthermore, their source code quality can be considered as "rotten to the core", I would bet my behind on the Mediatek kernel customization containing more than one exploitable hole.
The Following 3 Users Say Thank You to harddisk_wp For This Useful Post: [ View ] Gift harddisk_wp Ad-Free
5th January 2015, 05:47 PM |#5  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,439
 
Donate to Me
More
Quote:
Originally Posted by harddisk_wp

All MediaTek SoCs can be considered compromised, for every single one of them allows the entire ROM to be read back and reflashed using spFlashTool, even with a "locked" 2nd stage bootloader. Furthermore, their source code quality can be considered as "rotten to the core", I would bet my behind on the Mediatek kernel customization containing more than one exploitable hole.

thank you for the contribution. it is good to know that all mediatek devices can be rooted and are effectively unbrickable.

it also seems that the opo is unbrickable: there seems to be a ColorOS leak that flashes the system by debug-booting the qualcomm soc.
5th January 2015, 09:05 PM |#6  
Member
Thanks Meter: 9
 
More
This is really important stuff… pitty how most people are more interested in skins than serious security issues. Hope it gets the attention it deserves.
The Following 2 Users Say Thank You to davru For This Useful Post: [ View ] Gift davru Ad-Free
7th January 2015, 04:43 PM |#7  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,439
 
Donate to Me
More
i forgot to mention in the first post that Philz Touch Recovery does have password support. (i think they are actually PINs.) i haven't checked how the security is implemented in Philz though. regrettably that recovery has been discontinued so further investigation seemed useless.

TWRP is such a great piece of software that i simply can't imagine any competition will dare take on it again. that's exactly why it's important to get security merged in TWRP.
7th January 2015, 05:56 PM |#8  
Senior Recognized Developer
Thanks Meter: 6,041
 
Donate to Me
More
Quote:
Originally Posted by Lanchon

i forgot to mention in the first post that Philz Touch Recovery does have password support. (i think they are actually PINs.) i haven't checked how the security is implemented in Philz though. regrettably that recovery has been discontinued so further investigation seemed useless.

TWRP is such a great piece of software that i simply can't imagine any competition will dare take on it again. that's exactly why it's important to get security merged in TWRP.

3 people in the entire world do a majority of the work for TWRP. We are welcome for contributions to the TWRP projcect at OMNI's gerrit for people who want to get this done.
The Following 3 Users Say Thank You to bigbiff For This Useful Post: [ View ]
7th January 2015, 08:51 PM |#9  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,439
 
Donate to Me
More
Quote:
Originally Posted by bigbiff

3 people in the entire world do a majority of the work for TWRP. We are welcome for contributions to the TWRP projcect at OMNI's gerrit for people who want to get this done.

i thought of that, but adding a feature like this to TWRP probably requires too much effort for somebody who doesnt know the codebase. i imagine that TWRP is sort of an app framework in itself. i chose to advocate for it instead of implementing, i just can't justify the effort it would take *me*. i also tried to help by centralizing ideas on how it should be implemented, if somebody chooses to.

anyway, it's great to know you are not opposing the idea and you would consider merging if somebody implements, that is a good start.

btw, there is a tangentially related issue i'd love to hear your opinion on:

i hear TWRP can mount encrypted partitions and there is a UI for entering PINs, passwords, patterns etc. but i dont have my phone encrypted because if i break my display with the phone encrypted then im toast: i cant extract my files from the device anymore.

would you consider implementing a way to enter the encryption password via usb? maybe some sort of adb shell command?
7th January 2015, 09:15 PM |#10  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,439
 
Donate to Me
More
UPDATE: Added a third item to the OP...

3) Encryption is insecure unless the boot chain can be trusted.

An adversary that gains physical access to your phone can dump and save a copy of the encrypted partition(s) and plant a password sniffer that later forwards the password to them. You cannot trust your password to a non-tamper-evident device that can be trivially modified. The only way to protect the boot chain from tampering in today's phones is locking the bootloader and restricting access to the recovery.
The Following User Says Thank You to Lanchon For This Useful Post: [ View ] Gift Lanchon Ad-Free
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.
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