Related
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.
I've had the phone for about a week now, and it's been really crash-prone and unstable for the first couple of days. I previously had an HD7 for 4 weeks, so I immediately set up my DVP like I had the HD7 set up.
It was so buggy, I hard reset at least a couple of times in those few days. My most recent hard reset was on Sunday, and lo and behold, I didn't experience any crashes for 4 days!
That started me thinking. The difference between the previous hard reset and the current hard reset was that I hadn't loaded many apps or any mp3s yet - so I loaded the same amount of MP3s as I had before (about 8gb) and immediately any new programs started crashing! In fact, I think just about anything that wrote to the disk exhibited errors, from newly downloaded and installed apps to existing apps which does disk I/O. The marketplace crashed all the time while downloading or installing apps.
My best guess as to the cause of the issue is that the SD card is corrupting data. As long as you are using the internal storage, everything runs fine - but once data is written to the SD card, things are getting corrupted. I'm not sure about this, it's just a guess.
At the OS level, the internal storage is combined with the SD card into a single logical disk - AKA JBOD in RAID terms. I'm not sure about the OS-level algorithm it uses to determine whether or not to save to internal vs SD card, but my guess is that it writes to the internal first, then when that is exceeded, it writes to the SD card. Even after removing some MP3s, I still had crashes, so I'm guessing that it doesn't overwrite the same sectors that previously held data until all the "fresh" sectors have been used (ie it was still writing to the SD card).
If this is the case, then the culprits could be either A) Dell's crappy SD card drivers corrupting the data or B) a crappy quality SD card corrupting the data. Given their recent QC issues i'm inclined to think it's B - but I hope it's A because that would imply a software fix as opposed to having to replace hardware.
Either way, I'll write a program to test my hypothesis: It'll create a test files of a specific size and then read them back and check that the test data is correct.
Thoughts? Has anybody else noticed similar behavior after filling up their storage?
I suspected the SD card as well, which is why I included the remaining storage space in the options in the poll at http://forum.xda-developers.com/showthread.php?t=891295
That being said, some others have said that doing a system reset on their phone did not fix the crashing problems. There are 2 major unknown variables here of course - when the phone is using the SD card vs. internal memory, and whether everyone is experiencing the same type of crashing.
pjfan75 said:
I suspected the SD card as well, which is why I included the remaining storage space in the options in the poll at http://forum.xda-developers.com/showthread.php?t=891295
Click to expand...
Click to collapse
Yeah, I wouldn't be surprised if there were multiple causes for the all the crashes people are experiencing - most likely the SD card may be responsible for some of those, while other issues are causing more crashes.
Impossible to tell at the moment, though. But perhaps the reason why people associated wifi with crashing was that they were using the wifi to load more data than they were over 3G?
I've thought about the apps too. AP mobile is one that is involved on my list. Shazam, yelp, where, are others. I an make my hd7 crash with each of them. However, that does not eliminate sd card. Optimal read/write access speed will probably impact crash, lag, and performance.
Based on this thread it sounds like it's probably more of a driver issue.
alodar1 said:
I've thought about the apps too. AP mobile is one that is involved on my list. Shazam, yelp, where, are others. I an make my hd7 crash with each of them. However, that does not eliminate sd card. Optimal read/write access speed will probably impact crash, lag, and performance.
Click to expand...
Click to collapse
I've used those apps on the HD7 and I don't think they ever crashed it - not nearly as often as the DVP crashes.
zaijian said:
But perhaps the reason why people associated wifi with crashing was that they were using the wifi to load more data than they were over 3G?
Click to expand...
Click to collapse
That and also at a much higher rate than 3G typically.
zaijian said:
Based on this thread it sounds like it's probably more of a driver issue.
Click to expand...
Click to collapse
I don't know if I would agree with that. I would hope that drivers would be the same on all devices. To have 1 fail and 20 not fail....is it driver? I would be curious to know what the failure rates would be. Sure we see alot of complaints here on this forum....but there is not a whole lot of traffic about failure of the DVP. All in All, I'm happy with the DVP. I also have a HD7...and I'm happy with that. I have them both sitting here...and when I make a decision to use a phone of my choice...I've chosen the DVP.
With all things being equal, if I get into a fight, the DVP can be used as a weapon.
I've used up quite a bit of storage but the only time I seem to get a crash is when I enable WiFi, otherwise my DVP seems to run stable.
efjay said:
I've used up quite a bit of storage but the only time I seem to get a crash is when I enable WiFi, otherwise my DVP seems to run stable.
Click to expand...
Click to collapse
I have the same results, I went crash free for 2 days without WiFi I wanted to test it and turned it back on and it crashed within a few min.
I have a replacement coming from Dell but I doubt they will have it fixed. I'm hoping it would be something that can be fixed by an update.
Mine crashes too!!
I too am experiencing many of the issues that have been posted on this forum (crashing w/wo wifi, while in MP, or when an app needs data from the internet). Twice I have reached in my pocket, hit the power button to bring up the lock screen and nothing happens - just a blank screen. Hence had to pull the battery and reboot.
A couple of other things I have noticed that I am not sure I have seen on the forums. Does anyone else have a DVP where the top left edge and the bottom right edge are not flush with the bottom of the phone? It is slight, but I noticed it on day one. Also, I have a heck of a time with the accelerometer sticking. Sometimes it refuses to go back into portrait mode. No mater how I turn and twist it (360 deg).
Anyone else experience this?
I used to use the power button to get to the unlock screen, but after fumbling with it a few times in the dark, I switched to flipping out the keyboard, which does the same thing. And while it did often take multiple presses of the power button to wake the DVP, I have never had to pull the battery.
I've had the DVP since November 8th, and had it crash on my severely enough for a battery pull maybe 3-4 times tops. This is both on the "engineering" phone and the "retail" phone. The only difference I have with you guys - and this is pretty significant - is that I hacked my SD card pretty much within the first couple of days of getting it. I've upgraded to a SanDisk class 2 16GB.
Now, I haven't particularly filled it up; in fact, I have tons of space free. But, I'd like to set some facts straight:
1) The DVP has no internal storage. Just a few megs (~16MB or so) just so the OS can run if you pull the SD card. Nothing new here; we've seen this during the first days of the SD card hack thread.
2) If you fill up your storage, and applications request for IsolatedStorage, the request will most likely fail if you have (close to) zero storage free. If applications don't check for that, it will probably crash. I don't know if this is necessarily happening, since I don't have a crashing device to observe this behaviour, but that's one hunch. Some of you have said that the HD7 did not crash when you filled up the storage, which might throw my theory out the window.
3) The SD card used in the DVP is also a SanDisk - I tend to trust them with storage reliability. If it is indeed a driver issue, then Microsoft might have some share in the blame as well - MS writes drivers for the OEMs for WP7.
What we need to do is scientifically reproduce the issue. Instead of general data corruption, another thing to check is to see what happens as storage gets filled up.
kltye said:
What we need to do is scientifically reproduce the issue. Instead of general data corruption, another thing to check is to see what happens as storage gets filled up.
Click to expand...
Click to collapse
I attempted to do just that - I wrote a storage test app and ran it on my DVP, and it encountered no issues.
The app wrote test data, filling up 95% of available free space (around 13.3GB), then read it back in and verified the data. I'm now fairly confident that it's not the SD card or the storage drivers that are responsible for the crashing.
I did however, encounter issues trying to download the Rise of Glory game. I had turned wifi off, but it's large enough that it requires wifi or sync in order to download and install. Once I turned wifi on and retried the download, the phone crashed on me.
Let's see if we can verify the wifi + marketplace issue:
1) make sure phone wifi is off
2) connect DVP to computer, run Zune
3) via zune sync, verify that you can install a large game or app on your phone. It has to be one which you haven't downloaded before, as I don't think you can force zune to reinstall an app it knows you already downloaded.
4) disconnect the phone
5) verify the game runs correctly
6) uninstall the game on the phone
7) turn phone wifi on
8) go into marketplace on the phone
9) reinstall the same game and see if you have any issues with marketplace while downloading (freezing/hanging/etc)
10) if everything's still ok, verify that the game runs correctly
@Zaijian
I tried reproducing your flow on my DVP and it didn't crash. But, what is strange is mine freezes (only twice so far) @ random right after playing and trying to get to some other app or switching between app. This tends me to side on the memory as being the culprit or some other component being the culprit. Most likely could be memory related and how WP7 manages to kill an app. Is there a memtest kind of thing we could run on this DVP?
I wrote a wifi transfer testing app and ran it overnight - it transferred 4GB over my wifi (from my desktop to the phone) correctly and without incident.
So, i've confirmed that:
A) there's nothing wrong with writing a single large file to the file system
B) there's nothing wrong with transferring data over wifi
My next tests will be:
1) simultaneously writing multiple large files to the file system
2) simultaneoulsy writing files to the file system and transferring data over wifi
3) some sort of memory test to see if memory is getting corrupted
WiFi seems to be the issue
Not much question that mine locks up when WiFi is turned on. I have been experimenting with this issue for the past few days and while having WiFi on causes random lock-ups, not having it on makes it run without any issues.
Fortunately, most of the areas I use my phone have good 3G coverage so WiFi acting up is not a deal breaker but I certainly hope they are able to fix this with the impending update.
One consideration is could there be an app we all have that uses WiFi that is causing trouble? Has anyone had issues with this from a fresh device? I seem to recall having it lock up early on before I put many apps on it.
jetjockgordo said:
Not much question that mine locks up when WiFi is turned on. I have been experimenting with this issue for the past few days and while having WiFi on causes random lock-ups, not having it on makes it run without any issues.
Fortunately, most of the areas I use my phone have good 3G coverage so WiFi acting up is not a deal breaker but I certainly hope they are able to fix this with the impending update.
One consideration is could there be an app we all have that uses WiFi that is causing trouble? Has anyone had issues with this from a fresh device? I seem to recall having it lock up early on before I put many apps on it.
Click to expand...
Click to collapse
My problems seem to occur when I'm going through the marketplace and downloading via wifi.
I verified with my test app that wifi can transfer a large amount of data without errors. This leads me to believe that the wifi itself is not the cause of the issues, but that wifi in combination with other factors may be the cause.
zaijian said:
My problems seem to occur when I'm going through the marketplace and downloading via wifi.
I verified with my test app that wifi can transfer a large amount of data without errors. This leads me to believe that the wifi itself is not the cause of the issues, but that wifi in combination with other factors may be the cause.
Click to expand...
Click to collapse
I thought so too but I left the WiFi on and rebooting without accessing Marketplace has been causing lockups as well. In fact, I just noticed it was locked up after a reboot 10 minutes ago and, sure enough, I left WiFi on. I didn't so much as unlock the screen after the reboot although I have also had it lock up while accessing Marketplace.
jetjockgordo said:
I thought so too but I left the WiFi on and rebooting without accessing Marketplace has been causing lockups as well. In fact, I just noticed it was locked up after a reboot 10 minutes ago and, sure enough, I left WiFi on. I didn't so much as unlock the screen after the reboot although I have also had it lock up while accessing Marketplace.
Click to expand...
Click to collapse
I'll test using wifi simultaneously with local disk I/O and see if that causes errors.
has anyone done this yet? I noticed it in the settings, but it said it can take up to 1 hour... just wondered if it was worth while.
if you have done it, does it slow anything down, and how long did it take you to run?
Sent from my HTC Desire using Tapatalk
iamdarren said:
has anyone done this yet? I noticed it in the settings, but it said it can take up to 1 hour... just wondered if it was worth while.
if you have done it, does it slow anything down, and how long did it take you to run?
Sent from my HTC Desire using Tapatalk
Click to expand...
Click to collapse
I tried but it appears to not work. You have to be plugged in and fully charged (seems to work from 90% ish), and you have to have unlock PIN set. But once you have selected and confirmed encryption, the screen blanks except for a green line drawing of an Android logo, and then after a minute or so the screen blanks out and then you wait...and wait....and wait...and wait. I gave up after 4 hours.
If at any point you switch screen on, you get the PIN prompt: enter PIN, and you're presented with the blank screen with green line diagram of android logo. I've left it like this for several hours. In the end I reset, and got my device back - but still unencrypted. I've also tried without ever trying to log in until at least 4 hours have elapsed, in case the login attempt disturbed the encryption.
I have logged a defect with Asus for this and a couple of other things, and this morning got a response back saying that "We're still looking into this", which seems to suggest that they agree it is a problem.
Cool in gonna try now, at 95percent battery.
Sent from my Transformer TF101 using Tapatalk
That didn't seem to do anything.... I saw the green android with cog body, maybe I need to give it more time. I will set out before i go bed.
Sent from my Transformer TF101 using Tapatalk
I'm wondering how the encryption is handled, is it software or hardware enabled. I have seen with PC's that use software encryption that there is a performance hit and if the encryption is handled by hardware, like a hardware enabled HDD encryption, there is little to no performance hit. The PC I tested the software encryption on took forever to boot vs the hardware enabled one.
Havoc6266 said:
I'm wondering how the encryption is handled, is it software or hardware enabled. I have seen with PC's that use software encryption that there is a performance hit and if the encryption is handled by hardware, like a hardware enabled HDD encryption, there is little to no performance hit. The PC I tested the software encryption on took forever to boot vs the hardware enabled one.
Click to expand...
Click to collapse
You must have used some strange encryption application or had an old computer.
Try truecrypt - on modern (2 core) computer there is practically no performance hit whatsoever (decrypting and even encrypting on the fly is faster than hard drives - on SSD it could be too slow though). The same goes for standard encryption used by Ubuntu (it's very probable that Android tablets use the same method).
Truecrypt (and probably most other full-disk encryptions too) work like that:
- all the data on hard drive is encrypted (edit: it's encrypted all the time, never, ever is decrypted data written to disk),
- when system reads data - it's decrypted before being send to applications,
- when system writes data - it's encrypted before it's saved to the disk.
Also - Tegra2 should have a part handling encryption and decryption so it could be at least partially hardware encryption.
Your right, it has been a while since I have used encryption due to a bad experience early on. I'll give Truecyrpt a try. The software I used before was Safeguard Easy.
iamdarren said:
That didn't seem to do anything.... I saw the green android with cog body, maybe I need to give it more time. I will set out before i go bed.
Sent from my Transformer TF101 using Tapatalk
Click to expand...
Click to collapse
I left mine overnight, and it still was not encrypted. I had even done a factory reset beforehand to minimize the amount of data to encrypt.
I'm pretty sure this doesn't work. I'll post as soon as I get a reply from Asus.
It did not work, maybe this feature isn't ready yet?
Sent from my Transformer TF101 using Tapatalk
As a feature, it's not ready for prime time. I have it working on the xoom, but every reset it erases my timezone and sets it to GMT. Also, it uses the same PIN as your lock screen, so if you have a numeric pin for easy access, anyone who sees it now knows your encryption password as well. It really should be two different passwords. I intend this weekend to reset my machine and remove the encryption, because it doesn't serve the purpose it was supposed to serve.
Bump. Any info from Asus? I started it at ~7pm. It's midnight, and on the last few power-ups I get nothing except the green android logo after I enter the PIN. So it seems it's still not doing anything? Gonna reset now I guess.
Same problem here with a Transformer TF-101 Build number HRI66.TW_epad-8.2.3.8-20110423
See nothing but a android robot after enter the PIN. 7 hrs later I manually shutdown the machine.
Same here on the Modaco ROM.
Left it on the android pic for 9 hours... it didn't lock the screen or anything, and at the end, the accelerometer still worked when I rotated the screen, but I had to power off and on to get it back.
What does the encryption do, anyway? Does it stop you being able to load files on from the PC? Does it ask for the password when you plug it into the PC?
So no one has been able to get encryption working? I was just going to test this out and saw this thread. Thanks.
I've seen someone talking about some minor issues when running with encryption, so someone got it working.
That MIGHT have been on xoom, but I think it was the transformer.
Just thought I would share my experience with the encryption feature in Honeycomb since some people can't get it working:
At first I couldn't get it working like some people on this thread, I too was stuck on the green wireframe Android for hours on end until I discovered I could still exit back to the homescreen by pressing the home key on the keyboard dock. This happened on both the stock Asus 3.1 ROM and v1.4 of the PRIME! ROM (installed via nvflash).
I then updated recently to v1.5 of PRIME! via CWM and I can report that I was able to encrypt my Transformer after this update. It displayed the green Android wireframe logo for a few seconds, then rebooted and went into the encryption progress page. I had not really done much with the ROM other than change a few small settings and add my Google account, so the encryption was complete in less than an hour. I think the 'hour or more' estimate Google gives within the encryption description text is probably more accurate if you've installed a few more apps afterwards, but of course your timing will vary.
Furthermore I think that the encryption is likely only partial, because I was then able to flash one of the zip files from this thread via CWM without any issues or prompts. Otherwise I'm sure it would've thrown some kind of error such as not being able to mount the system partition or something of that ilk.
Finally (lol ) I also found this page on the Android source website outlining the details of the encyption implementation in Android Honeycomb for anyone interested. There is a mention somewhere of the 128-bit flavour of the AES algorithm being used to encrypt the master key.
Hope this helps anyone trying to get encryption working on their Transformer .
yet another absolutely useless feature, besides bricking the thing for whoever tries to steal it. keeps your data safe.. even from yourself.
i noticed a problem when inserting a microsd (into the pad itself) that it would not be able to boot as long as this is inserted. i am guessing this is because it tries to decrypt the microsd (that is not encrypted) and therefore is stuck in boot.
This is another aspect one should expect if this was a pre-release software. I am extremely disappointed with this product so far, mostly because of the software. most of (not any of the cameras) the hardware (including the keyboard) is pretty good
I did it 2 days ago, and it worked flawless. It tooks about an hour. I use it since and I have no problems at all.
The only thing is that I have to insert the SD card again each time I power on the transformer. Any idea how to change rhat?
fjoesne said:
yet another absolutely useless feature, besides bricking the thing for whoever tries to steal it. keeps your data safe.. even from yourself.
i noticed a problem when inserting a microsd (into the pad itself) that it would not be able to boot as long as this is inserted. i am guessing this is because it tries to decrypt the microsd (that is not encrypted) and therefore is stuck in boot.
This is another aspect one should expect if this was a pre-release software. I am extremely disappointed with this product so far, mostly because of the software. most of (not any of the cameras) the hardware (including the keyboard) is pretty good
Click to expand...
Click to collapse
You likely have ASUS to blame for this, as my understanding is that the Thinkpad tablet deals properly (from the spec anyway) with SD cards attached to the device even to the point it can additionally encrypt them. Again we are all early adopters, Honeycomb was sort of an experiment for Google, and Ice Cream Sandwich is the real next version of the andoid platform.
And encryption is hardly a useless feature, it means Google is finally trying to consider enterprise usage of their products which is very important to the further growth of the platform.
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.
Hi,
I am thinking about encrypting my Nexus 4. I am already using encryption on all my computers but I never tried it on my smartphone, so there are three questions I hope you will answer:
1)
How is battery life affected? Well, fortunately the battery of the Nexus 4 is quite good and I hope encryption won't waste too much.
2)
How is speed affected? My Desktop CPU has AES-NI and there's a SSD, so you don't even recognize system encryption. How is it doing on the Nexus 4? I'm just doing the usual smartphone stuff, means E-Mail, messaging, phoning, checking News &Weather and sometimes playing Doodle Jump. My research on the Internet about encryption performance on Android didn't bring up things I can really rely on so I hope someone here can tell me his experiences.
3)
Which algorithm is used exactly? I know it's dm_crypt and I'm using it on my other computers, too, but on my PC I can choose which algorithm I want and on Android it's given as far as I know.
Regards,
becha
You can't use patter lock to unlock your screen, which is a pian for me right now.
Sent from my Nexus 4 using Tapatalk 2
1. Barely noticeable
2. Same as 1
3. Not sure
Sent from my Nexus 4 using Tapatalk 4 Beta
1) I doesn't notice any real impact on battery life. Used the N4 several months before encrypting it.
2) Booting the phone is slowed down, and not only because you have to enter the key for accessing the encrypted drive. But opening apps and doing backup, etc. isn't slowed down. I guess I wouldn't even notice an encrypted devices and so did no one until now, while using my phone.
I was also doubtful before, because in my experience, on a laptop back in the days (5 years ago), the battery drain and performance impact was just to big. But on the other side, I do a lot more disk based tasks on my laptop, than I do on my phone.
in short, after I lost my last phone, I really wanted to give it a try and I didn't regret it until now.
Hoping to hear good answers to question 3.
@HB_Mosh
Well, that's not too bad for me because I don't use Unlock Patterns.
@Vanhoud @memleak
Thanks for sharing your experiences, I'll give encryption a shot.
becha said:
@HB_Mosh
Well, that's not too bad for me because I don't use Unlock Patterns.
@Vanhoud @memleak
Thanks for sharing your experiences, I'll give encryption a shot.
Click to expand...
Click to collapse
can you please tell us your experiences, i was thinking about it, i guess you can CWM, encrypt then restore backup if you want to revert without starting all over
Yesterday I encrypted my Nexus 4, it took around an half an hour. Until now (well, one day...) I didn't discover any problems apart from the fact, that my Nexus 4 did a simple restart for the first time when trying to encrypt it. Everything went fine when trying the second time. The phone itself runs fluent, so up to now I didn't see any performance problems.
Now I can't backup my ROM - any suggestions? Perhaps Recovery can mount to an external USB storage or something? What a pain! You can't un-encrypt either, and there's no way to mount encrypted storage in Recovery I wanted to backup before installing privacy protection in case it borked my phone.
Another encryption question...
Don't mean to hijack this thread, but can anyone tell me if OTA updates will still work on a stock, unrooted N4 that's been encrypted?
Can't find a definitive answer - some have had success on other devices and others haven't.
I don't see why turning on stock encryption on a stock unmodified device would make any difference?
Sent from my Nexus 4 using Tapatalk 2
DroidBois said:
I don't see why turning on stock encryption on a stock unmodified device would make any difference?
Click to expand...
Click to collapse
I wasn't sure why / if this would make a difference either but as I said, I can't find a definitive answer. Some people say that you need to factory reset in order to remove the encryption before you can apply an OTA update, but others say different.
I'd be interested to know if the OTA would work after simply asking you for your encryption PIN on reboot, or if the encryption would prevent the OTA being applied because of the encrypted storage. Does anyone have any experience of this?
DroidBois said:
Now I can't backup my ROM - any suggestions? Perhaps Recovery can mount to an external USB storage or something? What a pain! You can't un-encrypt either, and there's no way to mount encrypted storage in Recovery I wanted to backup before installing privacy protection in case it borked my phone.
Click to expand...
Click to collapse
You have to use TWRP Recovery, which is able to mount your encrypted internal storage.
No way.. I thought I'd tried every option I could think of in TWRP but I'll take a closer look.
Sent from my Nexus 4 using Tapatalk 2
If you start TWRP, it should automatically ask for your passphrase to read the encrypted internal storage. Latest version of TWRP works for me, older ones had bugs regarding to encrypted devices.