This actually applies to most HTC handsets, heck, maybe most phones, but this is the Dream forum and I wanted to talk about the Dream (since I own one). I actually had realized this the day I first rooted my phone, but it had been on the back of my mind until today when I ported MCR 2.6 for the Dream and saw the laughable WaveSecure app. I then thought about posting this general warning for Dream users and hopefully we can brainstorm and bring this big security hole to an end.
WaveSecure is an app that runs as a high priority process in your phone and it can do silly things such as disallow the usage of the device or access to the data on it by placing a locking screen on your phone. To enable your phone back, you enter a pin. Does that sound familiar? Ofcourse, your phone already has a lockscreen. The app also has a few backup and restore features, but nothing that hasn't been done before. Probably the only worthwhile feature is the ability to lock your phone remotely (but then the lockscreen was already active anyway).
Our rooted phones are different than stock ones, though. If you lose your phone and a knowledgeable person gets a hold of it, all they have to do is reset the phone, hold Home and Red, and voila, they have access to ALL your personal data inside your phone. I'm not only talking about the SDCard here, because accessing that data is so stupidly simple, but your phone writes enormous amounts of personal data to /data. There you can find account logins for all your installed apps, contacts info, you can find browser cache info and if you do your banking on your phone's Browser and have cookies set, well, they're all there. I've looked through several of the files in /data and most things there are dumped in human readable format, so a crook wouldn't even have to try very hard. I found my home's wifi hidden SSID AND 22 character lenght alphanumerical WAP2 encryption key in a file, and both were labeled as such .
One solution I see is easy, modify recovery to give you an option to prompt for password on start. But there's still the fact that, with the device on, we can still adb remount and then adb pull /data, so the adb binary would also have to be re-written for this purpose.
There's still yet another problem, though. Fastboot... Most of us are running a flavor of an Engineering SPL (either Death SPL or Hard SPL), and even if we block /recovery and /system, a crook can still fastboot flash boot and fastboot flash system and with a minimal booting image (no android runtime, only enough in /bin to boot a linux system) he can still get adb pull /data access.
That's where I'm at a loss, though. How do we patch SPL to prevent unauthorized usage? Are there any other security gaps I might have missed?
Comment, discuss, develop.
I'm confused. Wiping clears out the /data partition. Where are you getting all this data from post-wipe?
And that's exactly why I carry my important data safely with me. Wipe clears out the /data partition as much as "Emptying the Recycle Bin" erases deleted data in Windows.... meaning, it's still there. Although flash memory is better at deleting data, it can still be easily recovered, but then again, how are you supposed to wipe if you don't have the phone with you. I didn't see anything about remote wipe. Also, any person with two neurons firing would think right away about removing the battery and SIM before attempting anything.
Also, so let's say a wipe did clear /data entirely and you were able to remotely wipe EVERY SINGLE TIME the phone was lost or stolen (I once went a week without realizing I had lost my phone, paying that kind of bill and talking to Customer Service for hours on end is no fun), it still doesn't mean that the security gaps are not there. I still think they should be fixed, even if to foil people not interested in the data at all but on using the phone for their own. Don't you hate it when people find phones on the street, and instead of trying to return it they take it to their nearest mom & pop phone shop and have it unlocked, etc?
Oh, I see what you meant XD. Edited my post.
I've noticed this too, but the safest way to secure it is to have android encrypt the files as they are put on the data partition. Even then, that data is still unsecure. We should file an issue with the google code page for android and have them worry about it
Well, this has actually been considered...
For 'droid 1.6: From the home screen, Menu --> Settings --> Security --> "Use secure credentials". It is, of course, up to the application to make use of secure credentials. This is something that you should question the developers of secure applications about.
Other times, you may note that applications like "Password safe" will password protect and encrypt their data sets.
So it is definitely up to you to ensure that the applications that you use are written with security in mind.
Now for your home wifi password... does that really matter that much? They have to actually be IN (or very near to) your home to make use of it.
B-man007 said:
I've noticed this too, but the safest way to secure it is to have android encrypt the files as they are put on the data partition. Even then, that data is still unsecure. We should file an issue with the google code page for android and have them worry about it
Click to expand...
Click to collapse
No device can be more secure than being encrypted (assuming use of strong encryption). There is most definitely NO WAY EXCEPT encryption to secure your data.
I guarantee that EVEN WITH a no-root recovery partition and a no-fastboot bootloader that enforces system image signatures, that the data on the device *CAN STILL* be read off it.
It is definitely impossible to secure these devices against being read through something like jtag. And if it is read through jtag, the only thing that can possibly protect your data is encryption.
is it possible to do a complete wipe of the device? i know its not permanent but i figure if i quit banking online after i wipe the phone then i am no longer succeptible to that form of theft
I bet this is making some people that sold their rooted G1's nervous right now lol
this is the same issue blackberry users have, , even with a remote wipe ,there was concern that data can still be retrieved. That's also why the secret service is so concerned about the president having and using one daily, if its ever lost or stolen, ,,well you know, ,,
So rooted or not android is not the only platform with this issue. .
I would like to address this
"Don't you hate it when people find phones on the street, and instead of trying to return it they take it to their nearest mom & pop phone shop and have it unlocked, etc?"
Did you know if you called any cellphone carrier that you have and told them your phone was lost/stolen they will put the IMEI or ESN on the lost/stolen list, and then it can no longer be active on their network and from what I hear any other networks.
card13 said:
I would like to address this
"Don't you hate it when people find phones on the street, and instead of trying to return it they take it to their nearest mom & pop phone shop and have it unlocked, etc?"
Did you know if you called any cellphone carrier that you have and told them your phone was lost/stolen they will put the IMEI or ESN on the lost/stolen list, and then it can no longer be active on their network and from what I hear any other networks.
Click to expand...
Click to collapse
Depends on where you are, here in Canada, if it gets blacklisted by Rogers, it will still work on Fido (which happens to be owned by rogers).
There is also the possibility of rewriting the IMEI. Not exactly a major difficulty.
I have an idea. Since that, if someone gets hold of your phone physically, there's no way that he/she will be restricted from accessing the data, unless it's encrypted properly.
Therefore, to enhance the security, the data (or at least, /data) should be encrypted all time. I'm not familiar with Linux so I have no idea if it's doable or not, but that's a start.
That way, even if someone gets hold of your phone, and flash/hack/cheat all kinds of things, fastboot, recovery, adb... He/she will still be unable to access your data.
To do this, the bootloader (or the init script?) needs to implement a way to unlock the data.
To further increase the security, remote shutdown and wipe should be implemented as well.
Remote lock will NOT work because, while a phone is locked, it means it's running, and the data is already unencrypted at that point, and while I don't have much knowledge in hacking. I think a serious-enough person can hack the phone and get the data.
Of course, this still doesn't solve the problem that, if you, or your family member, is being held at gunpoint.
Just my 2 cents.
1) No changes to bootloader. Bootloader is not relevant to encrypted /data. The changes would be to add in the appropriate encryption scheme to the kernel. Also, to mount the /data partition using the selected encryption method, and to prompt at the appropriate time (mount time) for password. This would be DURING BOOT.
2) The reason you don't want to do this is that d/encryption eats CPU and memory.
bug666 said:
I have an idea. Since that, if someone gets hold of your phone physically, there's no way that he/she will be restricted from accessing the data, unless it's encrypted properly.
Therefore, to enhance the security, the data (or at least, /data) should be encrypted all time. I'm not familiar with Linux so I have no idea if it's doable or not, but that's a start.
That way, even if someone gets hold of your phone, and flash/hack/cheat all kinds of things, fastboot, recovery, adb... He/she will still be unable to access your data.
To do this, the bootloader (or the init script?) needs to implement a way to unlock the data.
To further increase the security, remote shutdown and wipe should be implemented as well.
Remote lock will NOT work because, while a phone is locked, it means it's running, and the data is already unencrypted at that point, and while I don't have much knowledge in hacking. I think a serious-enough person can hack the phone and get the data.
Of course, this still doesn't solve the problem that, if you, or your family member, is being held at gunpoint.
Just my 2 cents.
Click to expand...
Click to collapse
lbcoder said:
1) No changes to bootloader. Bootloader is not relevant to encrypted /data. The changes would be to add in the appropriate encryption scheme to the kernel. Also, to mount the /data partition using the selected encryption method, and to prompt at the appropriate time (mount time) for password. This would be DURING BOOT.
Click to expand...
Click to collapse
So that's the init scripts?
lbcoder said:
2) The reason you don't want to do this is that d/encryption eats CPU and memory.
Click to expand...
Click to collapse
And battery, may I add?
To what extent is the question, I don't think it's a must-have feature for everybody, but think some may be willing to put up with the trade off...?
bug666 said:
So that's the init scripts?
Click to expand...
Click to collapse
Mainly kernel, but yes, some adjustment would have to be made to the init.
And battery, may I add?
Click to expand...
Click to collapse
Certainly. Anything that eats CPU eats batter.
To what extent is the question, I don't think it's a must-have feature for everybody, but think some may be willing to put up with the trade off...?
Click to expand...
Click to collapse
A better implementation would be to encrypt *some* data, i.e. application home directories, but specifically NOT the ~/lib directory. Because really, do you CARE if your APK's or dalvik cache are encrypted or not? This would minimize the performance impact (to negligible) while providing the desired data security.
Also, encryption on a per-application basis would allow this to be done withOUT having to pause bootup to ask for a password... it could be done more intelligently on first-access-attempt.
Anybody tried using Walkie Vault (http://www.walkie-vault.com/)...? Can it encrypt the data/home folder...?
A system-wide usable encryption system that different apps may make use of is a good idea, but is it on Android's agenda yet...?
It hasn't quite entered the collective consciousness that the connected smartphone, as configured today and if logged into online services, is the ultimate personal identity device. Unlike other personal effects we keep on us at all times (id cards, keys), a Google login gives a thief potentially a treasure trove of data to exploit without requiring any further identification to the phone other than the lock screen (assuming the user has set one). Once it becomes a big enough issue we may see solutions such as:
- Built in biometric identification (fingerprint scan, iris scan) replaces lock screen.
- OS framework requires apps storing sensitive user data to store into encrypted databases, authenticated from above biometric keys.
- Carriers, digital identity providers (e.g. Google, MSN) providing remote wipe as free standard services and accessible over the phone, not just a web page.
No computer is 100% secure.
Biometrics are often easy to fool.
3 of the fingerprint scanners I have encountered were easily by-passed with a pencil, and a rubber glove. Not to say they are all like that, but some are super simple to get around. Myth busters bypassed one with a photo copier and a sharpie. My buddy bought one super cheap, and put it on his wife's computer to make her feel safer. We bypassed it by breathing on it. (it was super cheap)
The current "Lock" on the G1 is like that super cheap biometric scanner. Your fingers leave behind oils. Oils are what leave the marks on the screen. Breathe hot air on the screen and you can see the pattern of the lock sequence. Some lock.
Note to self: remember to wipe off screen everytime you unlock phone.
I think that the best way around this is to remove all the data from the phone in the first place. For several years now I have been telling my friends that google's ultimate goal will be server side data storage that you log into to use.
The world of cell phones is headed this direction as well.
Google voice, Google Chrome, Google Docs, Cloud....all operate under the idea that you connect to the data, manipulate it, save it, then (ideally) your device forgets it was there.
If you want to stop cell phone theft, you have to hard code the phone to accept only one set of data, and any attempt to change that data in a way not prescribed by the phone will result in the destruction of the data and the usability of the phone. Not real cost effective for a device that lasts on the average of 18 months.
Another option is to make a daily use phone. Only good for 24 hours. Then you have to get a new one. Make them cheap, and disposable.
Common users would freak out over having to back up the data all the time, or you would need a uplink storage location like...oh say Google voice, Google Chrome, Google Docs, Cloud.
The average consumer has no clue what that thing in their hand is capable of doing, storing, or tracking. The techno geek is the problem and much like ROM's, what stops a Techno geek today, won't necessarily stop him tomorrow.
In the mean time, wave secure at least offers you the satisfaction of telling you when someone has put a different sim in your phone.
And it will scare the crap out of someone when they pull out the sim card. it is very loud!
But I agree the android system needs a better lock.
Maybe a mod could be prepared to separate /data into a cryptfs system, only trouble is that to make it secure a start/unlock password would need to be entered.
Related
Hi Guys,
See my original post...
http://forum.xda-developers.com/showthread.php?t=1088561
I've added the thread to this section as i have just bought the A500 i saw how unsecure the device was after it being rooted and applications were removed. Lots of my personal data, conversations and even contact lists were accessable....
Anyone shed any light on this? I feel a bit better now that i have my device encrypted and pin secured.
Funny was considering asking the same thing. Curious to see the responses. Specifically does it also encrypt an sd card, and if so will it prevent me from using that sd card anywhere else.
The encryption protects the data on the device. Also keeps unauthorized users from accessing the data or the device. It can not be undone in less you do a restore to factory settings. It is a lower level setting, that as far as I know does encrypt apps just data.
Hi Guys,
Thanks for the reply's...
I have to deal with AES 256bit encryption as part of my system admin role, which is typically Whole Disk Encryption. I would assume that this may be some form of WD encryption as it takes around an hour to do 32gb, generally it takes a few hours for work related machines with 80gb+
I dont think that external media will be covered by the crypto... i cant of course confirm that though.
Just wanted to write a few words as I have encrypted the phone and it might not be totally clear to everyone what will happen.
First encrypted phone (i.e. not SD card). Possible with strong password (e.g. 3Jjtljle45) as well as pin (e.g. 5069). Had a GS2 before and only possibility was strong password, for sure much safer but a hassle as you need to type it in every time lock screen kicks in. Pin option can easily be cracked by advanced users but for thiefs after you phone and not bothering to have a go at cracking the encryption your data will be reasonalby secure.
Next SD card encryption. Will encrypt all files the phone writes to the SD card after you turn it on, files on the phone stays un-encrypted (havent found a way to encrypt them exept from transfering them to PC and writing them back again). No hassle transfering files to and from the phone with USB, dropbox and the like (with ohter phones/implementation the files could stay encrypted when you transfer them to the PC in certaion situations).
So all in all a very nice implementation of encryption that you can tailor much to your liking, much better implementation than on the GS2 for example.
/Voz
Thank you for this information. I think anybody working for a company with a BYOD policy is very interested to know about encryption.
Do you notice any difference in the phones performance after encryption?
Slower to boot up, otherwise no noticeable performance degradation!
Sent from my XT890 using xda premium
My old (preordered in July) stock 16 GB Nexus 7 (4.2.2) which was stolen approximately 3 weeks ago was returned to me today with a flat battery. The thief said, "I could not get into your tablet to wipe its data. I'd like to return it to you and apologize for trying to make a quick buck."
During the three weeks it was missing, I remotely disconnected my Google account from the device by enabling two-step verification, and bought a new 32 GB (NO SCREEN SEPARATION ISSUES ).
He handed it to me, and promptly left the scene. Ecstatic, I rushed to the nearest outlet to charge the sucker up and use it again (I was thinking "WHOO HOO! TWO NEXUSES, NOW I CAN EXPERIMENT AND CRAP!"). However, while I was expecting to see my data, I found the device to have been wiped. The thief said that he had never had any experience with android devices, which leads me to believe that there is a wipe feature built into the Nexus.
Is there one or did this guy lie and actually get into it, steal whatever he needed and wipe? Should I be concerned? I checked the serial number and it IS the same device.
Sent from my [NEW] Nexus 7 using XDA Premium HD app
Well I know on iPhone after 10 failed attempts it wipes data but on android, I know it can disable your device but it usually makes you enter your password. If you disconnected your account its possible it wiped the device as well
Sent from my Nexus 4 @1.72 GHz on Stock 4.2.2
The stock recovery wipes everything and you can launch it without the OS, so no screen-unlock password is needed to do that.
OTOH, starting up the boot loader and then the recovery is not obvious to someone without android familiarity, but the instructions to do so are certainly readily available on the internet (e.g. here)
The story is rather odd - if you use the stock recovery to wipe the tablet, it is no longer locked by a password or gesture, so it is not obvious why someone that could wipe the device with the stock recovery would be unable to simply start the device up and notice that it was ready for configuration.
Then again, from your story it sounds like the thief isn't the brightest bulb in the room.
Either that or he was a CIA/Mossad agent and they planted hardware bugs in your device with the intent of returning it to you all along.
bftb0 said:
The stock recovery wipes everything and you can launch it without the OS, so no screen-unlock password is needed to do that.
OTOH, starting up the boot loader and then the recovery is not obvious to someone without android familiarity, but the instructions to do so are certainly readily available on the internet (e.g. here)
The story is rather odd - if you use the stock recovery to wipe the tablet, it is no longer locked by a password or gesture, so it is not obvious why someone that could wipe the device with the stock recovery would be unable to simply start the device up and notice that it was ready for configuration.
Then again, from your story it sounds like the thief isn't the brightest bulb in the room.
Either that or he was a CIA/Mossad agent and they planted hardware bugs in your device with the intent of returning it to you all along.
Click to expand...
Click to collapse
Lol, excellent theory! But my question is, what would a CIA agent want with a Canadian teenager that has a love of android?
Anyway, I'm going to try to find out more about it on Monday.
Was curious about this feature of the phone. ...I know what encryption is. ... but, in regards to phones, I do not. Can anyone shed some light on this for me? Like, what it does exactly, how it works, does implementing it in my device effect it on an os level or kernel?...any other general information about it is very appreciated. ..... tried google, but it just kept bringing up "15 things you must know about your s5" articles and the like.
beav3r
Skynyrd420 said:
Was curious about this feature of the phone. ...I know what encryption is. ... but, in regards to phones, I do not. Can anyone shed some light on this for me? Like, what it does exactly, how it works, does implementing it in my device effect it on an os level or kernel?...any other general information about it is very appreciated. ..... tried google, but it just kept bringing up "15 things you must know about your s5" articles and the like.
beav3r
Click to expand...
Click to collapse
You can encrypt the device (Settings > Security >Encrypt). However, you will NOT be able to use the fingerprint scanner if you do this. This process takes around one hour and scrambles all the data. Every time you turn on the device you need to enter a passcode before it boots. This helps to provide an extra layer of security on top of the regular PIN or password.
Read more: http://www.itpro.co.uk/mobile/22034/samsung-galaxy-s5-top-15-tips-and-tricks#ixzz319NY0W4G
kprice8 said:
You can encrypt the device (Settings > Security >Encrypt). However, you will NOT be able to use the fingerprint scanner if you do this. This process takes around one hour and scrambles all the data. Every time you turn on the device you need to enter a passcode before it boots. This helps to provide an extra layer of security on top of the regular PIN or password.
Read more: http://www.itpro.co.uk/mobile/22034/samsung-galaxy-s5-top-15-tips-and-tricks#ixzz319NY0W4G
Click to expand...
Click to collapse
Also recovering data off a damaged phone is impossible.
Unless you require your data to be fully encrypted and don't care if you lose it, because it is backed up; do not encrypt.
Thanks guys. Does anyone know the processes the phone goes through while encrypting? Or decrypting. ... just wondering if it would be beneficial at all If someone did a log cat while doing both, just to see if there is a hole that could have an exploit vulnerability. ... and, would dalvik vs ART during the process change that answer, since you're running "custom"while ART is on. ... I'm 99% sure it isn't going to help s#!%, but, never know, little things usually get overlooked.
beav3r
In light of the recent kerfuffle between the government and Apple, I have a purely technical question (not looking for opinions) on 6P/Marshmallow encryption.
1) How does the actual encryption compare to Apple's (latest)?
2) Is it possible (within reason and with current technology) to be broken? (I know that theoretically ANYTHING can be broken, just asking if it would be practical (e.g. not take 100 years).
3) In there anything either Google or Huawei could do to assist the government in hacking a 6P/Marshmallow?
4) Is there any addon that would give the capability of n-wrong attempts/erase as in Apple. If so, would it require root?
Apple is being asked to provide a method to allow a brute force attack. Having a really strong password is a good way to prevent such an attack. And the 6P's fingerprint scanner makes a strong password doable, without the inconvenience usually associated with it.
After 10 incorrect entries, Android will make you wait 30 seconds after each attempt, which makes it a slow, arduous process. I don't have the patience to determine if there is a point in this process where data is automatically wiped from the phone.
Of course you can always use ADM to wipe your phone remotely if your phone is still connected.
Actually, (and I'm just speaking technically, not making political/moral judgements), fingerprint encryption does NOT stop the government from decrypting your phone. You can be legally compelled to swipe your finger (but NOT to provide your own password), and your fingerprint can be used even if you're dead.
Solutions Etcetera said:
Apple is being asked to provide a method to allow a brute force attack. Having a really strong password is a good way to prevent such an attack. And the 6P's fingerprint scanner makes a strong password doable, without the inconvenience usually associated with it.
After 10 incorrect entries, Android will make you wait 30 seconds after each attempt, which makes it a slow, arduous process. I don't have the patience to determine if there is a point in this process where data is automatically wiped from the phone.
Of course you can always use ADM to wipe your phone remotely if your phone is still connected.
Click to expand...
Click to collapse
l_stevens said:
Actually, (and I'm just speaking technically, not making political/moral judgements), fingerprint encryption does NOT stop the government from decrypting your phone. You can be legally compelled to swipe your finger (but NOT to provide your own password), and your fingerprint can be used even if you're dead.
Click to expand...
Click to collapse
Assuming they have your finger, that's all true. But turning the phone off will still require your pin/pattern/password to decrypt it.
IIRC, Android does not automatically wipe your phone, but enough attempts will put it into a state where no more attempts can be made. At that point, additional account credentials are required, or an FDR is necessary.
I also know first hand, that resetting a phone from recovery will not allow a phone to be used without account credentials.
Great information. Big thanks given!
Since Android is "Open Source", would it be feasible for someone to remove the delay to enable a brute force attack? In any case, Google could do it if ordered.
So, assuming a brute force attack occurs (delay removed), how easy to break the encryption set by a pattern (and is there anything else Google to do in addition to removing the delay to help decrypt)?
Solutions Etcetera said:
Assuming they have your finger, that's all true. But turning the phone off will still require your pin/pattern/password to decrypt it.
IIRC, Android does not automatically wipe your phone, but enough attempts will put it into a state where no more attempts can be made. At that point, additional account credentials are required, or an FDR is necessary.
I also know first hand, that resetting a phone from recovery will not allow a phone to be used without account credentials.
Click to expand...
Click to collapse
l_stevens said:
Great information. Big thanks given!
Since Android is "Open Source", would it be feasible for someone to remove the delay to enable a brute force attack? In any case, Google could do it if ordered.
So, assuming a brute force attack occurs (delay removed), how easy to break the encryption set by a pattern (and is there anything else Google to do in addition to removing the delay to help decrypt)?
Click to expand...
Click to collapse
On an unrooted phone with a locked bootloader, the only way to modify the system would be to unlock and root, which would wipe the phone.
Does Marshmallow use 256-bit AES encryption?
That about pattern lock? Is it the equivalent of a 4 digit passcode (or 6 or 8...)?
l_stevens said:
Does Marshmallow use 256-bit AES encryption?
That about pattern lock? Is it the equivalent of a 4 digit passcode (or 6 or 8...)?
Click to expand...
Click to collapse
https://source.android.com/security/encryption/
128 bit.
Sent from my Nexus 5X using Tapatalk
Solutions Etcetera said:
On an unrooted phone with a locked bootloader, the only way to modify the system would be to unlock and root, which would wipe the phone.
Click to expand...
Click to collapse
Google could create an special signed OTA update zip file and side load it to the device in Recovery without having to oem unlock the bootloader. This special OTA would allow for brute force unlocks.
SpookyTunes said:
Google could create an special signed OTA update
Click to expand...
Click to collapse
I suppose. But given Google's stance on the issue, I doubt that is any more likely to happen than with Apple.
SpookyTunes said:
Google could create an special signed OTA update zip file and side load it to the device in Recovery without having to oem unlock the bootloader. This special OTA would allow for brute force unlocks.
Click to expand...
Click to collapse
You have to unlock the phone to authorize the computer you're using to be able to connect to adb, correct? I could have sworn this needed to be done before you could adb sideload. Perhaps I'm incorrect.
At any rate, this is a fantastic reason why you should never leave your bootloader unlocked, unless you don't care if someone can have an easier time stealing your data.
Sent from a 128th Legion Stormtrooper 6P