Just bought a new Galaxy Tab S 10.5 Wifi and I have been debating whether to enable full disk encryption. I know that the stock android implementation of encryption is entirely software based, but Samsung mentioned in their documentation that their ODE (On Device Encryption) system supports hardware accelerated encryption. However, information on the topic is scarce, and I cannot confirm which models actually support acceleration.
Does anyone know of a list of android devices that supports hardware accelerated encryption?
snapper.fishes said:
Just bought a new Galaxy Tab S 10.5 Wifi and I have been debating whether to enable full disk encryption. I know that the stock android implementation of encryption is entirely software based, but Samsung mentioned in their documentation that their ODE (On Risk Encryption) system supports hardware accelerated encryption. However, information on the topic is scarce, and I cannot confirm which models actually support acceleration.
Does anyone know of a list of android devices that supports hardware accelerated encryption?
Click to expand...
Click to collapse
Go to Settings/Security and if it says Storage Type-Hadrware Backed, then your device has crypto module. However, big warning here: if your master encryption key sits in hardware (like in Iphones), there is nothing easier for a sophisticated attacker to get the key directly from there. If, like in Lollipop, the master key is salted on hard drive and crypto module holds another key used to sign the master key, that provides an additional layer of protection against brute force attack. In other words, someone can take an image of your entire hard drive and then brute force your password offline or in the case of Iphone, just get the key from hardware. In lollipop, it is impossible. So, sometimes google does good things (by mistake)...
In lollipop, it is impossible.
Click to expand...
Click to collapse
Android disk encryption is based on dm-crypt, which means it's at the block device layer. The encryption algorithm used is AES-128 with cipher-block chaining (CBC) and ESSIV:SHA256. The master key is encrypted with 128-bit AES via calls to the OpenSSL library. New Lollipop devices encrypted at first boot cannot be returned to an unencrypted state.
The unlock PIN/password is used to derive the AES disk encryption key which is stored in the volume header. As from 4.4, scrypt is used to derive the keys in order to make brute force attacks a little harder, but using a strong password instead of a stupid PIN remains highly recommended. On certain Nexus devices, the key is hardware-protected (likely TEE).
Nothing is impossible but's harder:
http://www.bbc.com/news/technology-31765672
http://www.washingtonpost.com/blogs...-apple-and-google-users-researchers-discover/
http://www.bbc.com/news/technology-31729305
CHEF-KOCH said:
Nothing is impossible but's harder:
http://www.bbc.com/news/technology-31765672
http://www.washingtonpost.com/blogs...-apple-and-google-users-researchers-discover/
http://www.bbc.com/news/technology-31729305
Click to expand...
Click to collapse
What have these news to do with Android encryption?
Seriously, there was a clear question by the OP and you didn't even try to answer at all. Instead you copy and paste text fragments from other websites and post irrevelant links...
@bastei
And how your post helps here? I explained very well that FDE is vulnerable with several attacks. It isn't worth to use it, especially on such hardware, because it costs a lot of performance for nothing.
FDE isn't secure to use, especially if you have a mobile device which allows the attacker to get physical access to it + the mentioned attacks.
But to answer the question:
Hardware accelerated encryption is dependent on which hardware (needs to support special flags like AES/AES-NI/AVX) you use and if your os supports it (minimum Android 3.x) or not. And no there is no list, because all new hardware after (and some of them before) Android 3.x comes with support for it, the Tab S uses AES 256-Bit Encryption according to the specs.
ODE (On Risk Encryption)
Click to expand...
Click to collapse
It's Samsung On-Device Encryption (ODE) and not on Risk ...
Yup that's a typo. Going to check the settings when I get home today.
CHEF-KOCH said:
@bastei
I explained very well that FDE is vulnerable with several attacks. It isn't worth to use it, especially on such hardware, because it costs a lot of performance for nothing.
FDE isn't secure to use, especially if you have a mobile device which allows the attacker to get physical access to it + the mentioned attacks. .
Click to expand...
Click to collapse
With all due respect, but your explanation is wrong. If encryption is properly implemented, you reduce vulnerability to virtually none. Users just have to understand how encryption works and what it is designed for. Contrary to popular beliefs, disk encryption is not designed to protect the device that is live/running, it only prevents access to your data, when your phone is off. By the way, the term "full disk encryption" , as it applies to Android, is highly misleading, because unlike in Linux, Android only provides for data encryption.
However, Android allows to implement encryption in a way that it is virtually impossible to break. You can have separate passwords short for screen and long/strong for boot and encryption. In addition, Android Lollipop provides an extra layer of protection by putting a second key, which is used to sign the master key in crypto module (hardware). This is much better than in IOS (iphones) where the master key simply sits in hardware crypto module and therefore could be easily obtained by a sophisticated attacker (think back doors in crypto module and weak hardware assisted random number generation).
Let me give you an example with my Sony Xperia Z1 running custom lollipop. I have enabled 256 bit encryption; I have increased the length of various keys, as well as the number of iterations for random number generation; then I have disabled in kernel hardware based weakened random number generator and enabled all other methods inactive by default (thanks to google and sony for making it easier to break for spooks); I then disabled hardware overlay option, which causes slow down, so, now, there is no visible difference in performance with unencrypted device. And finally, I have encrypted the phone via adb shell by using a long pass phrase, so that screen pin was not used in encryption in any way, including its salted traces on the device. By the way, when you encrypt lollipop via adb shell, you don't input your raw passphrase, but rather its hexed version, and guess what, I hexed it on my computer, as opposed to the phone. So, when I turn my phone off, I know that no sophisticated spook can get access to my data even if they take an image of all my partitions and try to brutforce the password off the phone. They simply can't. No one can break properly implemented 256 bit AES encryption. That is why the spooks need backdoors in hardware and weak random number generation (the latter is disabled in kernel on my Z1).
So, properly implemented encryption (and Android Lollipop provides for that) does not visibly slow down the device and can make it impossible for spooks to break. .
With all due respect, but your explanation is wrong. If encryption is properly implemented, you reduce vulnerability to virtually none. Users just have to understand how encryption works and what it is designed for. Contrary to popular beliefs, disk encryption is not designed to protect the device that is live/running, it only prevents access to your data, when your phone is off. By the way, the term "full disk encryption" , as it applies to Android, is highly misleading, because unlike in Linux, Android only provides for data encryption.
Click to expand...
Click to collapse
But Android is not a Computer which is on the same place all the time which means that it is a lot of easier to get physical access to it. That means an attacker have all the time to crack it, which in fact is only a matter of time. With or without additional protection mechanism - it will be cracked soon or later, and if you asking me it's not worth to use FDE on a mobile device, it coasts performance (as said for nothing).
The focus should be to protect data, correct but these kind of protection not protect against usage data stealing if most aps need internet connection which never use any secure way to send and receive data - So the risk here is much higher that a attacker can collect all necassary data if your phone is unlocked and a app xyz is running in the background which logs all stuff, such as Pin, passwords for website logins or whatever.
However, Android allows to implement encryption in a way that it is virtually impossible to break. You can have separate passwords short for screen and long/strong for boot and encryption. In addition, Android Lollipop provides an extra layer of protection by putting a second key, which is used to sign the master key in crypto module (hardware). This is much better than in IOS (iphones) where the master key simply sits in hardware crypto module and therefore could be easily obtained by a sophisticated attacker (think back doors in crypto module and weak hardware assisted random number generation).
Click to expand...
Click to collapse
It's very easy breakable there a several tools out there, exploits and poc's - and why need to crack something if you better steal data that are necessary over internet? Which tactic is easier - sure the last. Yes, lollipop is the first secure os, but not all people use it right now or the oem rolls out the update for every device. But I generally agree in the aspect that lollipop fix most stuff which are vulnerable compared to Android 4.x.
There are several attacks which affects all Android versions even latest lollipop:
- First, the encryption doesn't help much if you haven't set a passcode!
- Limitations in lollipops encryption explained over here
- Only the /data partition and all stuff in there will be protected (only the sdcard is protected if it's non-removable)
- The attacker boot to recovery and factory reset the device.
- If your phone is rooted and booted up, they'll use adb to copy your unencrypted data (e.g. sdcard). If it's not booted, they're stuck.
- The attack can use a download mode from there they flash a custom recovery or custom kernel (rooted) image. Most custom recovery's allows root adb which is needed to bypass the lockscreen.
- The attacker can simply use some software holes to bypass the pin and of course several known tools to crack the image master password.
- Military-grade encryption just doesn’t matter if an attacker has access to the key already.
- Nobody use a strong password (eg 20 chars) since you can't use a hardware token + the fact it's too long to type on the phone (and this each time).
- Android just required you to use a strong password/passphrase when starting up the device, but for some absurd reason they also require that you use the same password as your screen lock password
So, properly implemented encryption (and Android Lollipop provides for that) does not visibly slow down the device and can make it impossible for spooks to break. .
Click to expand...
Click to collapse
Yes and no, you right if you say the stuff about the implementation but overall encryption always takes performance for e.g. if you use AES 256 encryption anything that needs to decrypt constantly during the read and write process will causes performance impacts examples are give over here and here. But AES is most common used which is already "optimized".
The conclusion is that the performance of your device will take a slight hit if you enable encryption (dependency which hardware you use and which encryption algo was used + possible bugs/implementation problems) but to fight with this only for a technique that will be cracked it the near feature is really not worth to use or recommend if you asking me. It's more like a placebo, nothing is really secure as long the user is to lazy to use a very strong passcode/password
CHEF-KOCH said:
But Android is not a Computer which is on the same place all the time which means that it is a lot of easier to get physical access to it. That means an attacker have all the time to crack it, which in fact is only a matter of time. With or without additional protection mechanism - it will be cracked soon or later, and if you asking me it's not worth to use FDE on a mobile device, it coasts performance (as said for nothing).
The focus should be to protect data, correct but these kind of protection not protect against usage data stealing if most aps need internet connection which never use any secure way to send and receive data - So the risk here is much higher that a attacker can collect all necassary data if your phone is unlocked and a app xyz is running in the background which logs all stuff, such as Pin, passwords for website logins or whatever.
It's very easy breakable there a several tools out there, exploits and poc's - and why need to crack something if you better steal data that are necessary over internet? Which tactic is easier - sure the last. Yes, lollipop is the first secure os, but not all people use it right now or the oem rolls out the update for every device. But I generally agree in the aspect that lollipop fix most stuff which are vulnerable compared to Android 4.x.
There are several attacks which affects all Android versions even latest lollipop:
- First, the encryption doesn't help much if you haven't set a passcode!
- Limitations in lollipops encryption explained over here
- Only the /data partition and all stuff in there will be protected (only the sdcard is protected if it's non-removable)
- The attacker boot to recovery and factory reset the device.
- If your phone is rooted and booted up, they'll use adb to copy your unencrypted data (e.g. sdcard). If it's not booted, they're stuck.
- The attack can use a download mode from there they flash a custom recovery or custom kernel (rooted) image. Most custom recovery's allows root adb which is needed to bypass the lockscreen.
- The attacker can simply use some software holes to bypass the pin and of course several known tools to crack the image master password.
- Military-grade encryption just doesn’t matter if an attacker has access to the key already.
- Nobody use a strong password (eg 20 chars) since you can't use a hardware token + the fact it's too long to type on the phone (and this each time).
- Android just required you to use a strong password/passphrase when starting up the device, but for some absurd reason they also require that you use the same password as your screen lock password
Yes and no, you right if you say the stuff about the implementation but overall encryption always takes performance for e.g. if you use AES 256 encryption anything that needs to decrypt constantly during the read and write process will causes performance impacts examples are give over here and here. But AES is most common used which is already "optimized".
The conclusion is that the performance of your device will take a slight hit if you enable encryption (dependency which hardware you use and which encryption algo was used + possible bugs/implementation problems) but to fight with this only for a technique that will be cracked it the near feature is really not worth to use or recommend if you asking me. It's more like a placebo, nothing is really secure as long the user is to lazy to use a very strong passcode/password
Click to expand...
Click to collapse
I agree with you regarding weaknesses, but they all are rellated to improperly implemented encryption or user's misunderstanding. You have acknowledged that if the phone is off "they are stuck." That's what I call properly implemented encryption, and no tool can help including their super fast computers. By the way, if they do it on the device, in lollipop, data will be erased after 10 attempts, not to mention that there is a slowdown mechanism to prevent brutforce. Stealing online: yes, this is true, but again, it is possible to restrict any app from contacting the internet (afwall that was recently updated for lollipop and Xprivacy). On my phone, only web browser, mail client and sip client (all non google) have access to the internet; and since I have no Gapps, there is no "phoning home" Google's servers. Performance: it is true that encryption degrades performance somewhat, but again, if it is properly implemented, human's eye wouldn't notice. By the way, I think the reason Google is back pedalling on default encryption is that they have realized they really created something that is difficult to crack. Hence, they'll "modify" it soon to help their sponsoring spooks.
"Nobody use a strong password (eg 20 chars) " I use a boot pass phrase that has over 60 characters. This one was used for encryption, as opposed to a screen pin. You can only do it via adb shell.... Again, it is all about implementation. And by the way, most of the time I use soft reboot, which does not require me to use the long phrase at all.
A lot of people over-estimate spook's abilities. Despite the recent revelations: they can't do magic, meaning breaking encryption and they know it. That's why they are colluding with everyting that "moves" to put backdoors, weaken number generation, force weaker ciphers and so on.
May I ask you if using an xposed module is a risk for the whole system itself? It shouldn't be too hard to abuse it and to bypass xprivacy itself and the Android firewall.
Funny stuff, you not use gapps but you trust goggles encryption even if they already worked together in the past with GCHQ/NSA ...
Stealing online: yes, this is true, but again, it is possible to restrict any app from contacting the internet (afwall that was recently updated for lollipop and Xprivacy)
Click to expand...
Click to collapse
Again apps are not the first line of defense, they are the last. Xprivacy can't protect/or fake mac address, ID's or your imei/phone number (please read the whole FAQ) and on Lollipop there are a lot of more restrictions generally and they are not all implemented yet.
Since Xprivacy needs root (or should I say the Xposed framework) this is also a possible security risk, the attacker can use adb (which can be rescricted by an app) to disable/uninstall/freeze XPrivacy or any other app even if you use them as admin (the app will once crash and not restart).
...and no tool can help including their super fast computers
... data will be erased after 10 attempts
Click to expand...
Click to collapse
Erased? Are you sure? I don't think so I guess the os will just shutdown but to erase something would be horrible.
On my phone, only web browser, mail client and sip client (all non google) have access to the internet; and since I have no Gapps, there is no "phoning home" Google's servers.
Click to expand...
Click to collapse
Yes, and this is a mistake here in this thread, people forgett that most users are not experts, they not even know about XPrivacy/AFWall+ or root. The benefit of encryption should that all people even without bigger knowledge can handle it without disadvantages or other hints. So that already failed, google now reverted there own statement which means the encryption will not default enabled for all (see my links for there statement: In short - OEM complaining about performance!).
So security isn't activated from the beginning which is also a possible risk.
Performance: it is true that encryption degrades performance somewhat, but again, if it is properly implemented, human's eye wouldn't notice.
Click to expand...
Click to collapse
No it's not and you not understand it the I/O performance is slower, that can be a little bit different from device to device (due other hardware) but it's definitely noticeable (and not only in benchmarks) - please read the links. Not every use high end devices, never forget it -> again security should be available for all and the fact google reverted it clearly shows that we are not ready yet.
By the way, I think the reason Google is back pedalling on default encryption is that they have realized they really created something that is difficult to crack. Hence, they'll "modify" it soon to help their sponsoring spooks.
Click to expand...
Click to collapse
It's a matter of time anyone found a solution, the only thing we can do is to upgrade the OS to fix the possible holes asap - but that won't protect anyone who not update direct after each new release. And oem's usally needs aslo time to update there stuff, if they not already gave up due the massive fragmentation.
I use a boot pass phrase that has over 60 characters. This one was used for encryption, as opposed to a screen pin. You can only do it via adb shell.... Again, it is all about implementation.
Click to expand...
Click to collapse
Yes and because of implementation there are always security holes, possible risk and negative side-effects and because of this there will always a way to crack thinks as long if you're rooted.
And again because you use that it not means the mass use this - I'm not the only one who complains about that several known security experts and on several sites a lot of people saying that the length of the password is always a problem. Sure there are a lot of tools, but in our case they only works after a login and again ... mostly only experts using them.
A lot of people over-estimate spook's abilities. Despite the recent revelations: they can't do magic, meaning breaking encryption and they know it. That's why they are colluding with everyting that "moves" to put backdoors, weaken number generation, force weaker ciphers and so on.
Click to expand...
Click to collapse
Maybe, maybe not. Maybe NSA already have the ability to crack it with some exploits, maybe not - but we can bet on it they are working on it right know we talking about it. But why holidng on stuff that is placebo? There are already problems which can't be denied.
So we are now a bit off-topic, but if you believe the myth that it can't be bypassed you must be naive it was done in the past and it will be soon or later with lollipop with tools every script kiddy can use (like on 4.x). That's not what I call implementation related, it's also not encryption related it's the fact that as long users can side-load stuff or execute root it's only a matter of time - that was and ever will a possible security risk (not only on Android).
pikatchu said:
May I ask you if using an xposed module is a risk for the whole system itself? It shouldn't be too hard to abuse it and to bypass xprivacy itself and the Android firewall.
Click to expand...
Click to collapse
Don't use any xposed module that is not open source
Use Afwall built in iptables binaries, as opposed to system ones or better move builtin iptables into your system
Prevent any xposed module including xprivacy and xposed framework from internet access
---------- Post added at 04:39 PM ---------- Previous post was at 03:50 PM ----------
CHEF-KOCH said:
Funny stuff, you not use gapps but you trust goggles encryption even if they already worked together in the past with GCHQ/NSA ...
Again apps are not the first line of defense, they are the last. Xprivacy can't protect/or fake mac address, ID's or your imei/phone number (please read the whole FAQ) and on Lollipop there are a lot of more restrictions generally and they are not all implemented yet.
Since Xprivacy needs root (or should I say the Xposed framework) this is also a possible security risk, the attacker can use adb (which can be rescricted by an app) to disable/uninstall/freeze XPrivacy or any other app even if you use them as admin (the app will once crash and not restart).
Erased? Are you sure? I don't think so I guess the os will just shutdown but to erase something would be horrible.
Yes, and this is a mistake here in this thread, people forgett that most users are not experts, they not even know about XPrivacy/AFWall+ or root. The benefit of encryption should that all people even without bigger knowledge can handle it without disadvantages or other hints. So that already failed, google now reverted there own statement which means the encryption will not default enabled for all (see my links for there statement: In short - OEM complaining about performance!).
So security isn't activated from the beginning which is also a possible risk.
No it's not and you not understand it the I/O performance is slower, that can be a little bit different from device to device (due other hardware) but it's definitely noticeable (and not only in benchmarks) - please read the links. Not every use high end devices, never forget it -> again security should be available for all and the fact google reverted it clearly shows that we are not ready yet.
It's a matter of time anyone found a solution, the only thing we can do is to upgrade the OS to fix the possible holes asap - but that won't protect anyone who not update direct after each new release. And oem's usally needs aslo time to update there stuff, if they not already gave up due the massive fragmentation.
Yes and because of implementation there are always security holes, possible risk and negative side-effects and because of this there will always a way to crack thinks as long if you're rooted.
And again because you use that it not means the mass use this - I'm not the only one who complains about that several known security experts and on several sites a lot of people saying that the length of the password is always a problem. Sure there are a lot of tools, but in our case they only works after a login and again ... mostly only experts using them.
Maybe, maybe not. Maybe NSA already have the ability to crack it with some exploits, maybe not - but we can bet on it they are working on it right know we talking about it. But why holidng on stuff that is placebo? There are already problems which can't be denied.
So we are now a bit off-topic, but if you believe the myth that it can't be bypassed you must be naive it was done in the past and it will be soon or later with lollipop with tools every script kiddy can use (like on 4.x). That's not what I call implementation related, it's also not encryption related it's the fact that as long users can side-load stuff or execute root it's only a matter of time - that was and ever will a possible security risk (not only on Android).
Click to expand...
Click to collapse
GAPPS vs. Google encryption: I can't examine or modify GAPPS, but I can Google encryption, which is open source
Xposed modules: Xposed framework needs root once only during installation. After that you can revoke root permission
Attacker use of ADB: no matter what attacker does, he can't mount Data. Even on a live device, if pings are disabled, as well as all incoming connections, there is no way to reach the system over the internet. Now, I am not talking about baseband or simcard exploits, but if you face that kind of an attacker, then you don't use cell phones at all. The point stands: if your phone is off and it is properly encrypted, there is virtually no way to get the data. And I say virtually only because of baseband/simcard exploits.
Erasing data: If you look at lollipop's /system/vold/cryptfs.c and .h, you will see that erasing data is implemented after 10 unsuccessful attempts (the number could be reduced).
Low end devices vs. high end; regular user vs. advanced: you can't have a product that will satisfy all. You can't lower safety standards to satisfy the low end regular user. 2015 Mercedes is safer on the road than 1976 Honda. If you have advanced knowledge, you'll benefit more than a regular user. And if that user refuses to help himself, he will have to face the consequences.. That's the way Linux (and Android is its ugly daughter) is built...
GAPPS vs. Google encryption: I can't examine or modify GAPPS, but I can Google encryption, which is open source
Click to expand...
Click to collapse
Open source isn't a guarantee for security. I'm tired to saying this over and over again here on xda and in other forums. And no, it's not open source since most devices comes with own stock android builds which may use other hardware/drivers and maybe other or touched encryptions. There is also no guarntee that it hold what it promise as long nobody can proof or deny it.
Xposed modules: Xposed framework needs root once only during installation. After that you can revoke root permission
Click to expand...
Click to collapse
Once is more than enough, to get infected by faked Xposed Installers or other possible attacks. You scenarios are very unrealistic, nobody only use root only for one single module - You can't tell me that. Attackers don't need to mount data if you installed apps on external sdcard which isn't encrypted.
as well as all incoming connections, there is no way to reach the system over the internet.
Click to expand...
Click to collapse
Incoming connections are not necessary, outgoing is more important to send data to a eg. C&C.
The point stands: if your phone is off and it is properly encrypted, there is virtually no way to get the data. And I say virtually only because of baseband/simcard exploits.
Click to expand...
Click to collapse
Sure but it's unrealistic too, I will use the phone and not use encryption which can be attacked or bypassed except the phone is offline.
Erasing data: If you look at lollipop's /system/vold/cryptfs.c and .h, you will see that erasing data is implemented after 10 unsuccessful attempts (the number could be reduced).
Click to expand...
Click to collapse
Please give me the source, thanks. According to this normal userdata not getting any wipe on encryption fail and on other systems then EXT4 or F2FS nothing will be done (no access). And as long /data is not mounted there is also no access, that's the reason android temporary mount /data each time to promt for passwords, other processes and such (for more look in the documents)
I didn't know that but nvm it's unimportant since the master key is still on the device itself - which will definitely not erased and as said it not protect against privacy data stealing which is more important, nobody want you android files, only you passwords etc ...
Use Afwall built in iptables binaries
Click to expand...
Click to collapse
Iptables are not installed on every system and not working anymore since Android 5 need some extra flags like -pie and to replace the system own or installing them needs root too - oh, and to fix possible startup data leaks also needs root for init.d.
Low end devices vs. high end; regular user vs. advanced: you can't have a product that will satisfy all.
Click to expand...
Click to collapse
I'm not saying other stuff but you are the one which said that the performance impact is minimal and I'm the one which said encryption should work out of the box for all on any device - sure it's definitly an implementation thing, but as a workaround older devices may just simple lower the encryption e.g. 256 -> 128 Bit.
You can't lower safety standards to satisfy the low end regular user. 2015 Mercedes is safer on the road than 1976 Honda. If you have advanced knowledge, you'll benefit more than a clueless user who refuses to help himself....
Click to expand...
Click to collapse
I'm not comparing cars I only compare the encryption algos which haven't much changed over the years (just some fixes here and there but under the hood the car still needs 4 wheels).
We talked about encryption and possible attacks and you still can't deny them all. You try to find some excuses but under the line it will be cracked - and not in 10 years, this or next year I promise because of this reasons:
- Cracking the pins normally takes only seconds: they are simply to short or follow patterns due to being the same as the lock screen password. Practically speaking, the security of this entire story depends on the passphrase the user sets. If it is very long, it makes brute forcing difficult. But most people would set a 4/6/8 digit PIN, because who would want to enter a 20 digit password with alphabets and special characters every time you want to make a call or send a message?!
- Cracking Encryption in general -> Encrypted Master Key + Salt stored in footer and they are usually stored at the end of the partition or in a footer file on other partitions
- OEM's may use a different key management module
- Some forensic boot images are available which makes it possible to start early in the boot chain before the whole system loads ->
- Keyloggers or memory catcher allowing the attacker to capture unencrypted data -> including encryption keys and passwords for non encrypted content
- If the device is already compromised with malware it will be possible send things into the internet
- Some root kits already breaking most of all hard disk encryption such as the "Stoned" bootkit on TrueCrypt
- A factory reset also resets the master key
optimumpro said:
I have enabled 256 bit encryption; I have increased the length of various keys, as well as the number of iterations for random number generation; then I have disabled in kernel hardware based weakened random number generator and enabled all other methods inactive by default (thanks to google and sony for making it easier to break for spooks); I then disabled hardware overlay option, which causes slow down, so, now, there is no visible difference in performance with unencrypted device.
Click to expand...
Click to collapse
You already mentioned some of these things over at unclefab's "How To Secure Your Phone"-thread. Any chance to get some more detailed steps or even diffs of your changes?
Thanks!
CHEF-KOCH said:
Open source isn't a guarantee for security. I'm tired to saying this over and over again here on xda and in other forums. And no, it's not open source since most devices comes with own stock android builds which may use other hardware/drivers and maybe other or touched encryptions. There is also no guarntee that it hold what it promise as long nobody can proof or deny it.
Once is more than enough, to get infected by faked Xposed Installers or other possible attacks. You scenarios are very unrealistic, nobody only use root only for one single module - You can't tell me that. Attackers don't need to mount data if you installed apps on external sdcard which isn't encrypted.
Incoming connections are not necessary, outgoing is more important to send data to a eg. C&C.
Sure but it's unrealistic too, I will use the phone and not use encryption which can be attacked or bypassed except the phone is offline.
Please give me the source, thanks. According to this normal userdata not getting any wipe on encryption fail and on other systems then EXT4 or F2FS nothing will be done (no access). And as long /data is not mounted there is also no access, that's the reason android temporary mount /data each time to promt for passwords, other processes and such (for more look in the documents)
I didn't know that but nvm it's unimportant since the master key is still on the device itself - which will definitely not erased and as said it not protect against privacy data stealing which is more important, nobody want you android files, only you passwords etc ...
Iptables are not installed on every system and not working anymore since Android 5 need some extra flags like -pie and to replace the system own or installing them needs root too - oh, and to fix possible startup data leaks also needs root for init.d.
I'm not saying other stuff but you are the one which said that the performance impact is minimal and I'm the one which said encryption should work out of the box for all on any device - sure it's definitly an implementation thing, but as a workaround older devices may just simple lower the encryption e.g. 256 -> 128 Bit.
I'm not comparing cars I only compare the encryption algos which haven't much changed over the years (just some fixes here and there but under the hood the car still needs 4 wheels).
We talked about encryption and possible attacks and you still can't deny them all. You try to find some excuses but under the line it will be cracked - and not in 10 years, this or next year I promise because of this reasons:
- Cracking the pins normally takes only seconds: they are simply to short or follow patterns due to being the same as the lock screen password. Practically speaking, the security of this entire story depends on the passphrase the user sets. If it is very long, it makes brute forcing difficult. But most people would set a 4/6/8 digit PIN, because who would want to enter a 20 digit password with alphabets and special characters every time you want to make a call or send a message?!
- Cracking Encryption in general -> Encrypted Master Key + Salt stored in footer and they are usually stored at the end of the partition or in a footer file on other partitions
- OEM's may use a different key management module
- Some forensic boot images are available which makes it possible to start early in the boot chain before the whole system loads ->
- Keyloggers or memory catcher allowing the attacker to capture unencrypted data -> including encryption keys and passwords for non encrypted content
- If the device is already compromised with malware it will be possible send things into the internet
- Some root kits already breaking most of all hard disk encryption such as the "Stoned" bootkit on TrueCrypt
- A factory reset also resets the master key
Click to expand...
Click to collapse
Wipe after 10 attempts, see here https://github.com/CyanogenMod/android_device_qcom_common/blob/cm-12.0/cryptfs_hw/cryptfs_hw.c
A factory reset wipes data, so whatever happens to master key is not significant. But even if the master key is reset, there is no use of it in terms of trying to get previously encrypted data. And by the way, the term reset is not correct: if you do a regular reset, the master key is not touched, as it is not sitting on data partition and if you wipe system and data, your master key is gone and the new one will be generated only when you enable encryption again.
I don't understand your consistent point that users won't bother with long passwords, when Android provides for separate passwords one for boot/encrption and another for screen (which is not used for encryption). As I have already said, I use an over 60 character boot password and a short screen pin. If I need to reboot the device, I use soft reboot, which does not require the password at all. So, having a long password does not create any undue burden.
Again, data/disk encryption is valuable, because it protects your device when it is off, meaning, no one can access your data... I have close to personal experience with "sophisticated attackers": they can do nothing with properly encrypted device that is turned off...
Closed source vs. open source. I am not saying open source is secure. I am saying that open source could be examined unlike proprietary one.
My last words on this:
Well in the source nothing to user data gets wiped, only stuff that protects android system related files which proofs that the user data aren't safe if someone use forensic image and cloned everything.
Short screen pins can be cracked in minutes so as long we can sideloading anything before or after a boot especially if not all stuff is mounted it is still a risk.
Fastboot/softboot or whatever you want to call it isn't available on every device so you whole argumentation about complex passwords are useless (for example a friend of mine recently got the LG G3 which had fastboot deactivated). And of course if you got an error like kernel panic or other crash you can't fast reboot which also required that complicated and complex password - especially on mobile devices this is pretty annoying.
Again FDE on Android is placebo that's all, as long the user can dump the whole system and crack it on a PC which is powerful enouth it will be always useless. Apple use a unique key (if we can believe it) which can't be extracted with any tool or read out during the boot (maybe some day but I don't know any tool yet) so everything like brute force must be directly on the device which takes a lot of more time compared to a computer with an external powerful nvidia card and tools like hashkill/hashcat.
About explaining closed source, if you are good enouth you can reverse engineering most of the code - you don't even need to deobfuscate all stuff but in most time if you know the basics you know which weakness e.g. the encryption may have.
As long you not understand that sideloading is the biggest problem in android you not understand that all can be cracked soon or later and because you use xyz do not means that millions of stock users doing such complicated steps too to "secure" the phone which do not protect all stuff except the os itself. Android has defenses yes, but it is more to protect itself and not the private data that's the conclusion. It's a good step what was made with lollipop but there are still attacks which can't be that easily blocked, especially if the user doesn't know how or most if the mechanism are deactivated or simply to complex.
CHEF-KOCH said:
My last words on this:
Well in the source nothing to user data gets wiped, only stuff that protects android system related files which proofs that the user data aren't safe if someone use forensic image and cloned everything.
Short screen pins can be cracked in minutes so as long we can sideloading anything before or after a boot especially if not all stuff is mounted it is still a risk.
Fastboot/softboot or whatever you want to call it isn't available on every device so you whole argumentation about complex passwords are useless (for example a friend of mine recently got the LG G3 which had fastboot deactivated). And of course if you got an error like kernel panic or other crash you can't fast reboot which also required that complicated and complex password - especially on mobile devices this is pretty annoying.
Again FDE on Android is placebo that's all, as long the user can dump the whole system and crack it on a PC which is powerful enouth it will be always useless. Apple use a unique key (if we can believe it) which can't be extracted with any tool or read out during the boot (maybe some day but I don't know any tool yet) so everything like brute force must be directly on the device which takes a lot of more time compared to a computer with an external powerful nvidia card and tools like hashkill/hashcat.
About explaining closed source, if you are good enouth you can reverse engineering most of the code - you don't even need to deobfuscate all stuff but in most time if you know the basics you know which weakness e.g. the encryption may have.
As long you not understand that sideloading is the biggest problem in android you not understand that all can be cracked soon or later and because you use xyz do not means that millions of stock users doing such complicated steps too to "secure" the phone which do not protect all stuff except the os itself. Android has defenses yes, but it is more to protect itself and not the private data that's the conclusion. It's a good step what was made with lollipop but there are still attacks which can't be that easily blocked, especially if the user doesn't know how or most if the mechanism are deactivated or simply to complex.
Click to expand...
Click to collapse
And here are my last words. Click the link in the previous post and you will see code to wipe user data. There is annotation that says we will wipe everything related to encryption followed by the code itself that contains the words "wipe user data":
} else {
if(ERR_MAX_PASSWORD_ATTEMPTS == err)
wipe_userdata();
With regard to cracking everything soon, this is just your opinion that is not based on known facts. And one of the facts is that if spooks could break the encryption, they wouldn't need back doors and weakening.
Again, I fail to understand your point about users not using long screen passwords. You don't need long ones for your screen. But let's leave it there and agree to disagree.
bastei said:
You already mentioned some of these things over at unclefab's "How To Secure Your Phone"-thread. Any chance to get some more detailed steps or even diffs of your changes?
Thanks!
Click to expand...
Click to collapse
Look here for kernel changes:
https://github.com/AOSP-Argon/android_kernel_sony_msm8974/commit/29d918c1f11247602c58096a62084811bccc328f
// When device comes up or when user tries to change the password, user can
// try wrong password upto a certain number of times. If user enters wrong
// password further, HW would wipe all disk encryption related crypto data
// and would return an error ERR_MAX_PASSWORD_ATTEMPTS to VOLD. VOLD would
// wipe userdata partition once this error is received.
#define ERR_MAX_PASSWORD_ATTEMPTS -10
#define QSEECOM_DISK_ENCRYPTION 1
#define MAX_PASSWORD_LEN 32
Click to expand...
Click to collapse
It won't touch userdata at all, it wipes only (as written) disk encryption related data stuff but I'm talking about sideloading user data and this will never be wiped since this will destroy other stuff too - so this prevents only some attacks if you just start you're phone. - Or if you dump the data without - in a locked state - the master key.
The stuff you linked is also different from my link from AOSP project since it's CM, also a mistake, because CM isn't stock or based on OEM's firmware. So all you're stuff may applies only to custom firmwares - I'm talking again about stuff which use the mass and not only certain "expert" people.
Look here for kernel changes:
Click to expand...
Click to collapse
This is also from CyanogenMod which also only affects /cache/recovery which doesn't matter if the system was already booted success and (as shown) some stuff was already compromised or running in the background.
With regard to cracking everything soon, this is just your opinion that is not based on known facts. And one of the facts is that if spooks could break the encryption, they wouldn't need back doors and weakening.
Click to expand...
Click to collapse
Yes and your wrong opinion is that it isn't crackable, same was said years ago about TrueCrypt which now is labeled as unsafe and I already mentioned tools which break it.
Seems you're to ignorant to understand which possible negative effects may comes with side-loading. As long you not understand this we can stop the entire discussion here (I already gave up because you don't know s much as I do which tools can break stuff) - it will be cracked and the the dm-crypt stuff was already cracked in Android 4. because of some fixes that doesn't mean anything. Again, because you use xyz that doesn't mean all use the same stuff you already ignored this several times now and I already said that - but okay.
CHEF-KOCH said:
It won't touch userdata at all, it wipes only (as written) disk encryption related data stuff but I'm talking about sideloading user data and this will never be wiped since this will destroy other stuff too - so this prevents only some attacks if you just start you're phone. - Or if you dump the data without - in a locked state - the master key.
The stuff you linked is also different from my link from AOSP project since it's CM, also a mistake, because CM isn't stock or based on OEM's firmware. So all you're stuff may applies only to custom firmwares - I'm talking again about stuff which use the mass and not only certain "expert" people.
This is also from CyanogenMod which also only affects /cache/recovery which doesn't matter if the system was already booted success and (as shown) some stuff was already compromised or running in the background.
Yes and your wrong opinion is that it isn't crackable, same was said years ago about TrueCrypt which now is labeled as unsafe and I already mentioned tools which break it.
Seems you're to ignorant to understand which possible negative effects may comes with side-loading. As long you not understand this we can stop the entire discussion here (I already gave up because you don't know s much as I do which tools can break stuff) - it will be cracked and the the dm-crypt stuff was already cracked in Android 4. because of some fixes that doesn't mean anything. Again, because you use xyz that doesn't mean all use the same stuff you already ignored this several times now and I already said that - but okay.
Click to expand...
Click to collapse
I guess we speak different languages. My point is (and it stands) that if encryption is properly implemented, there is no way to get data from unmounted encrypted partition. Let's forget about wiping, any sophisticated attacker will take an image of the device and then try to break a copy. However, to mount data, he will have to bruteforce my 60 character password that will unlock master key or break 256 bit AES. Good luck on either front. And I am not talking about stock, aosp or Cm roms. It makes no difference, the bottom line is he won't be able to do either of the above. I also don't care about careless users. They have a right to be ignorant and most enjoy it very much. Linux (on which Android is based) was not created for ignorant users...
Related
This is just some random thoughts as at the moment, I'm not for one or the other.
I like rooting and experimenting with different ROMs as much as the next guy, but when I read about Samsung Knox, I think I like it too.
With Knox, I can finally saved all my private data in a Knox container and never worry about it falls into the wrong hands.
I never used any password manager like Keepass on my phone so far, it was because I never knew if the app I just installed yesterday would sip out my passwords and quietly pass them to a remote server without my knowledge. How do I know after I unlock Keepass that another app wouldn't suck out all my passwords? I don't.
Same for other personal documents that I scanned and stored on my phone. Without Knox, I will never know if they stay only on my phone.
I wish we can have Knox and also can root with impunity
Did I understand it correctly?
Thanks for any inputs.
Keepass saves passwords in an aes256 encrypted file and runs with a localized secure enviroment (though I'm not sure on the details of this security). As an open source program this can easily be tested however. As a closed source program, Knox (or any number of other password managers) are much harder to test against exploits. I know exploits have obviously been found and fixed by the Keepass team, as with any security software. However I've never seen a good reason to mistrust Keepass over other password managers.
As for the details of Knox, I can't say. But from what I've read it seems like container based encryption. There are other container encryption apps but I don't know much of anything about them. I just use my laptop for that.
Remember, unless your whole device is encrypted, unlocking the encrypted container and viewing the files within will leave traces in the file system which can be pieced together by a competant snoop. Since mobiles are easily stolen compared to other computers, this needs to be kept in mind when working with secure documents.
E_Phather said:
Keepass saves passwords in an aes256 encrypted file and runs with a localized secure enviroment (though I'm not sure on the details of this security). As an open source program this can easily be tested however. As a closed source program, Knox (or any number of other password managers) are much harder to test against exploits. I know exploits have obviously been found and fixed by the Keepass team, as with any security software. However I've never seen a good reason to mistrust Keepass over other password managers.
As for the details of Knox, I can't say. But from what I've read it seems like container based encryption. There are other container encryption apps but I don't know much of anything about them. I just use my laptop for that.
Remember, unless your whole device is encrypted, unlocking the encrypted container and viewing the files within will leave traces in the file system which can be pieced together by a competant snoop. Since mobiles are easily stolen compared to other computers, this needs to be kept in mind when working with secure documents.
Click to expand...
Click to collapse
Thanks for the comment. When I tried Keepass on my PC, as soon as I enter the master password, all passwords are visible. So I just assumed that any malware running in the background can suck them all out and ship them 'home'. With knox, if I understand correctly, nothing can go out once it's in the container. Nothing can get into the container from outside the container either. I'm already using Android whole disk encryption, but that doesn't prevent data from being 'sucked' out without our knowledge when we are using the device. It's good only to prevent data from being accessed if we lost the device.
I use Truecrypt container on my PC, but once we unlock the container, everything is visible by the whole system. Unlike Knox container. So I think Knox does have its value.
some keyloggers can read the clipboard data of password managers (this is why a number of secure inputs dont allow the pasting of passkeys), and I suppose it is possible to intercept the video data and essentially send screenshot data. This is beyond the real strength of a password manager. The Knox idea of keeping it in the container yet reading it is interesting. Do you know of a desktop equivalent? I had previously thought unlocking the container would open it up for any malware present.
i share many of the same opinions with you, but as many other people are concerned, and very much turned off, if this is going to impose hardcore restrictions on rooting and installing custom ROMs, then i'm not sure what to think of knox. it IS there to secure stuff, so it's sort of a slippery slope deal. i guess for the non-experimental people who use vanilla TW and all that, it's a luxury.
this article, though a bit dated, was pretty helpful: http://blog.kaspersky.com/understanding-samsung-knox/
I am a noob with a history of 3-4 phones stolen , so it prompted me to search a antitheft app. One thing I found out that antitheft apps only work till phone is switched on or it has not been wiped and flashed with a new ROM. I struck me that is there a way that we can circumvent it.
The idea was
1) Make a partition in memory which is very small that it is not noticed by the thief who is flashing it to wipe every thing.
2) This new partition should not be wiped while flashing a new ROM and should be hidden to computers.
3) Install a anti theft app app on that new partition.
4) The app should get installed automatically even after flashing new ROM.
5) The app should retain its data.
6) The app should be hidden in the menu.
7) We can access the app to trace the mobile.
See I don't have any necessary skill to do any of these task so I ask you security pundits CAN IT BE DONE?
If possible we can ask a developer to do it and fund it I am sure there will be many to fund this work.
anurag09 said:
I am a noob with a history of 3-4 phones stolen , so it prompted me to search a antitheft app. One thing I found out that antitheft apps only work till phone is switched on or it has not been wiped and flashed with a new ROM. I struck me that is there a way that we can circumvent it.
The idea was
1) Make a partition in memory which is very small that it is not noticed by the thief who is flashing it to wipe every thing.
2) This new partition should not be wiped while flashing a new ROM and should be hidden to computers.
3) Install a anti theft app app on that new partition.
4) The app should get installed automatically even after flashing new ROM.
5) The app should retain its data.
6) The app should be hidden in the menu.
7) We can access the app to trace the mobile.
See I don't have any necessary skill to do any of these task so I ask you security pundits CAN IT BE DONE?
If possible we can ask a developer to do it and fund it I am sure there will be many to fund this work.
Click to expand...
Click to collapse
+1
i like it.
Please dont qoute OP
It is possible
But our devices are flashed completely if we flash a new rom
Every 1 is changed to zero
And if some devs figure out how to create such partition then people will figure out how to disable it
If a thief know how to flash new rom then he might find out a way to disable it.
We can change kernel and system so its not so much secure.
I don't have enough knowledge
For example you own a Samsung device and you created partition like that and a thief will just flash a stock rom including pit file so your partition will be merged or wiped
Sent from my C6502 using XDA Premium 4 mobile app
anurag09 said:
I am a noob with a history of 3-4 phones stolen , so it prompted me to search a antitheft app. One thing I found out that antitheft apps only work till phone is switched on or it has not been wiped and flashed with a new ROM. I struck me that is there a way that we can circumvent it.
The idea was
1) Make a partition in memory which is very small that it is not noticed by the thief who is flashing it to wipe every thing.
2) This new partition should not be wiped while flashing a new ROM and should be hidden to computers.
3) Install a anti theft app app on that new partition.
4) The app should get installed automatically even after flashing new ROM.
5) The app should retain its data.
6) The app should be hidden in the menu.
7) We can access the app to trace the mobile.
See I don't have any necessary skill to do any of these task so I ask you security pundits CAN IT BE DONE?
If possible we can ask a developer to do it and fund it I am sure there will be many to fund this work.
Click to expand...
Click to collapse
There Are many of them:
NQ Mobile Security Free
AVG antivirus
Quickheal
Avast
Mobile Tracker
(according to my theory)
Unless you can modify your hardware, it is highly impossible to have anti-theft app or security which persist through wipe (full wipe).
What if you have access to your hardware ? You can make system like Knox. Let say if your device is tampered, you can make the (Let say X-hardware) flag become 1. Now what should it do when the flag become 1 ? Either locks entire rom or make the device looks like bricked or etc (which make the device useless until you reset it). In hardware part, you should also modify how device should behave when it is turned on. Let say you have a microcontroller which see this X-hardware flag. If it is 1, skip entire process and turn off the device. How about software side ? Of course you need modified OS to support this.
The theory looks easy, but implementation is the hardest one.
There is a very easy way to implement this.
Most all new comouter hard disk and solid state disks sjpport what is known as HPA.
HPA stands for Host Protected Area or Hidden Protected Area.
It can be set or queried with the linux tool hdparm.
It effectively makes the disks report a smaller total size to the OS at the firmware level. Anything can be put inside including anti-theft software (see: computrace)
Easy enough.
anurag09 said:
I am a noob with a history of 3-4 phones stolen , so it prompted me to search a antitheft app. One thing I found out that antitheft apps only work till phone is switched on or it has not been wiped and flashed with a new ROM. I struck me that is there a way that we can circumvent it.
The idea was
1) Make a partition in memory which is very small that it is not noticed by the thief who is flashing it to wipe every thing.
2) This new partition should not be wiped while flashing a new ROM and should be hidden to computers.
3) Install a anti theft app app on that new partition.
4) The app should get installed automatically even after flashing new ROM.
5) The app should retain its data.
6) The app should be hidden in the menu.
7) We can access the app to trace the mobile.
See I don't have any necessary skill to do any of these task so I ask you security pundits CAN IT BE DONE?
If possible we can ask a developer to do it and fund it I am sure there will be many to fund this work.
Click to expand...
Click to collapse
I dont know if you live in a developed country, but phones have thing called IMEI that can be tracked. The guys who steal phones and who buy stolen phones are obviously stupid enough to believe that reselling phones is a thing.
Really, if you get your phone stolen so much, my suggestion would be buy two phones this time. One feature phone and a smartphone you keep at a safeplace. You use the smartphone only in safe situations and the dumbphone in all other cases.
Works fine, believe me. A feature phone costs less than an SD card nowadays.If you got your phone stolen 4 times, dont use or get a smartphone in the places you work or pass.
Software cant help if you are surrounded by thieves.
Sounds a great idea.
def a good idea. but as the previous post mentions., imei does a moderately good job of keeping blacklisted phones of the network
came across this article, and made me think of this post
its talks about an anti-theft method called poison pill
here is an excerpt:
The loss or theft of a company laptop can cost far more than the replacement hardware. It can cause significant disruptions to business. It can result in legal or financial exposure. It can put your company in breach of compliance with HITECH, HIPAA, and other stringent rules and regulations regarding data security and privacy.
Laptops with an Intel® Core™ processor with Intel® Anti-Theft Technology (Intel® AT) provide IT administrators with intelligent protection of lost or stolen assets.
With Intel® AT, you can now disable a lost or stolen PC with a local or remote "poison pill". This poison pill can delete essential cryptographic material from system hardware in order to disable access to encrypted data stored on the hard drive. The poison pill can also block the laptop’s boot process, rendering the system a "brick".
Intel® AT’s flexible policy engine allows you to specify the detection mechanism that asserts theft mode, the thresholds for timer intervals, and the theft-response action(s) to take. Because the technology is built into PC hardware, Intel® AT provides local, tamper-resistant protection that works even if the OS is reimaged, the boot order is changed, a new hard-drive is installed, or the laptop is disconnected from the network. When the laptop is recovered, you can reactivate it quickly and easily using your choice of methods: pre-provisioned passwords, one-time codes generated by IT, security questions, and more.
Intel® AT is activated through service subscriptions from Intel® AT-enabled software and service providers.
Source
If you have a Samsung phone, Enable "Reactivation Lock" from Settings->Security.
Wouldn't you have to use a custom PIT file to realize this? I think the best thing at the moment is the reactiviation lock, which is coded into the bootloader as far as i know.
Try Android Lost. If you convert it to a system app, you'll have a great security app (the best, in my opinion) that should survive a reset.
Sent from my SCH-I545 using XDA Premium 4 mobile app
Great idea! I would like a developer to make a recovery (such as CWM) that could be able to give you an option to put a password on the recovery. That'd be awesome.
Try using Hidden Eye. It captures a photo using front camera every wrong password. The full version have an ability to send the photo to your email. Check it out.
Never underestimate a kid whose poor in cash but rich in time.
https://play.google.com/store/apps/details?id=com.lsdroid.cerberus
Cerberus does all of the things mentioned in this thread except create a hidden partition and survive a new rom flash but does survive factory resets.
If the person was tech savvy enough to flash a new rom then they are tech savvy enough to change the IMEI to circumvent blacklisting. The reality is that the vast majority of people would at most do a factory reset on a stolen device.
So I'm selling my old Meizu M2 Note which is running Flyme OS that doesn't allow me to encrypt the whole phone. How can I ensure the data is actually gone before selling? Normal wiping doesn't erase everything.
That's a good but hard to answer question.
A good old fashioned hard drive can be single pass overwritten (debate about overwrite passes is still an open discussion) making it unrecoverable for anything but an MFT, Mobile devices use flash memory just like a USB drive or an SSD.
What is the difference? Wear leveling (https://en.wikipedia.org/wiki/Wear_leveling).
Because of that people came up with crypto-shredding or crypto erase which only truly works with Hardware Encryption because Software encryption can never, with 100% certainty, know how the wear leveling reacts on every device.
You already said this isn't an option so what can you do to be sure nothing can be recovered? The answer is unfortunately short, nothing.
However recent research showed that multi pass overwriting caught a lot of data but even the Gutmann method (35 passes) did not get rid of everything (I forgot the link to the Whitepapers).
That said, you aren't selling it to a forensic specialist.
My best suggestion is to use one of the higher rated wiping apps (Shreddit for example) to first destroy your files, then factory reset and download a few good recovery apps and again a wiping app. Make sure you can't recover your own files anymore (if you have very sensitive data you can connect it to a PC and use even better recovery or, if you are paranoid, forensic tools) then overwrite it with as many passes, rounds and algorithms you feel comfortable with. Check recovery tools again and call it a day when you feel satisfied.
This WILL eat at the wear level so keep that in mind when you want to start overdoing it.
Not everything will be gone but it's as good as it's going to get and I highly doubt the person you sell it to will be able to recover anything.
Good luck!
GU42 said:
So I'm selling my old Meizu M2 Note which is running Flyme OS that doesn't allow me to encrypt the whole phone. How can I ensure the data is actually gone before selling? Normal wiping doesn't erase everything.
Click to expand...
Click to collapse
#noob guide incoming
(potentially useless and harmful)
i just thought of it
shred memory
download custom rom and flash
fill memory with stuff
shred again
xD
TheMarchHare said:
That's a good but hard to answer question.
A good old fashioned hard drive can be single pass overwritten (debate about overwrite passes is still an open discussion) making it unrecoverable for anything but an MFT, Mobile devices use flash memory just like a USB drive or an SSD.
What is the difference? Wear leveling.
Because of that people came up with crypto-shredding or crypto erase which only truly works with Hardware Encryption because Software encryption can never, with 100% certainty, know how the wear leveling reacts on every device.
You already said this isn't an option so what can you do to be sure nothing can be recovered? The answer is unfortunately short, nothing.
However recent research showed that multi pass overwriting caught a lot of data but even the Gutmann method (35 passes) did not get rid of everything (I forgot the link to the Whitepapers).
That said, you aren't selling it to a forensic specialist.
My best suggestion is to use one of the higher rated wiping apps (Shreddit for example) to first destroy your files, then factory reset and download a few good recovery apps and again a wiping app. Make sure you can't recover your own files anymore (if you have very sensitive data you can connect it to a PC and use even better recovery or, if you are paranoid, forensic tools) then overwrite it with as many passes, rounds and algorithms you feel comfortable with. Check recovery tools again and call it a day when you feel satisfied.
This WILL eat at the wear level so keep that in mind when you want to start overdoing it.
Not everything will be gone but it's as good as it's going to get and I highly doubt the person you sell it to will be able to recover anything.
Good luck!
Click to expand...
Click to collapse
Thanks for your amazing reply!
I finally found the solution I was looking for: as Avast! support told me, you can still use Avast! Mobile Security to securely erase your phone (by overwriting data), it's just a hidden feature. You just have to deactivate the Device Administrators permission for the app.
Then you just use the "erase device."
Was that research about multi pass overwriting done on SSD, or HDD? I always thought that one pass is enough on a standart HDD.
Can you recommend me any good forensic tools to use to check if the data is truly erased, please? And does the phone need to be rooted in order to restore deleted data?
Thanks for all your insight and advice !
GU42 said:
Thanks for your amazing reply!
I finally found the solution I was looking for: as Avast! support told me, you can still use Avast! Mobile Security to securely erase your phone (by overwriting data), it's just a hidden feature. You just have to deactivate the Device Administrators permission for the app.
Then you just use the "erase device."
Was that research about multi pass overwriting done on SSD, or HDD? I always thought that one pass is enough on a standart HDD.
Can you recommend me any good forensic tools to use to check if the data is truly erased, please? And does the phone need to be rooted in order to restore deleted data?
Thanks for all your insight and advice !
Click to expand...
Click to collapse
Avasts shredder works but it's a single pass on flash memory so it doesn't clear everything with 100% certainty because of the wear leveling but no algorithm does. I'm pretty sure that's a feature they added after purchasing CCleaner.
They also added it as a module in their windows platform.
The multi pass research was done on Solid State Drives and I still can't find the link. Just from a research paper in 2011.
SSD's are still closest in comparison to the kind of memory used in Mobile devices.
As for HDD's it's an open debate. Forensics have claimed to be sble to read past 200 writes in the past but there is no research to support this. I believe that they showed that 1 pass PRNG is enough in 2005, however the DoD was still developing machines to perform 7 pass DoD standard wipes so, I have to say that I have no idea.
If you want serious forensic tools you're looking at these kind of distributions (infosec just made me laugh, SSL_ERR_CERT_COMMON_NAME_INVALID, it's infosec! ??).
http://resources.infosecinstitute.com/computer-forensics-tools/
But if anyone you sell it to would try something it would be more along the lines of Recuva and similar software.
On phones you can just download a bunch of high rated recovery tools and see if anything pops up.
You do not need root for most of them.
You could run fstrim which I'm pretty sure has no root requirements either. This would mark all blocks as invalid so Garbage Collection can pick it up as well. Even though GC has been show not to clean everything it doesn't hurt.
Hello,
I have a rather interesting question, if someone (expert only please) can help, it would be very much appreciated
I have bought a new phone (Huawei Mate 10 Lite) which already has the preinstalled Android 7 OS.
After I turned it on, I've upgraded it to Android 8 (and EMUI 8) via the Software Updater.
So now, I am running Android 8 on Huawei Mate 10 Lite.
Until here, everything works like charm
The problem starts here: I'm used to having my ENTIRE user data partition (phone/device, call it as you wish) ENCRYPTED.
I am using my phone very much in different environments and if I accidentally loose it or it gets stolen, I want to ensure that nobody can access my private data by any possible means.
So, when I go to the classical place for encrypting phones: Settings -> Security & Privacy, I noticed that the "Encrypt Phone" option is MISSING.
I have only "Encrypt SD Card", but I do not have an SD Card, nor do I use one. I use only the internal flashdisk memory.
I even turned on the Developer mode and searched for that specific setting, but I cannot find it.
I googled about this problem and what I found even deepens the mystery, as there are some contradicting information and it doesn't paint a clear picture on how the hell encryption works on Android 7/8...
- In one place, it says that starting with Android 6 phones, the option of encrypting the entire phone is no longer available, as all phones with Android 6+ preinstalled are already encrypted !
Bump ! Really ?
- Somewhere else, someone says that the Full Disk Encryption (FDE) has been replaced with File Encryption and Google is slowly marking full disk encryption as obsolete...
I found the File Encryption on my phone and I have the possibility to create a file encryption "folder" or "vault" or what is that, but I do NOT want that, as I want the entire partition to be encrypted !
I am using VPNs, SSH keys, Pictures, E-mail accounts, Web browsers with stored passwords, basically the entire user partition contains secrets ! I cannot move everything to a secure container... maybe I forget something, and that something remains unencrypted ?
I cannot move everything to a secure SD Card or to put it in that encrypted "folder", because some secrets are files, some secrets are particular app settings or credentials.
Yes, I read about the fact that in Full Disk Encryption mode, a PIN is required for startup (as I had with my previous phone, which was great for me, by the way), and that PIN can prevent the booting of some basic functions of the device or the functioning alarms or something like that.
To tell you honestly, I don't care about those functions. I only want ENTIRE device encryption with one single PIN code.
I have already changed my SIM PIN (which is another thing, it doesn't relate to this), and I generated a phone PIN & Fingerprint on my phone, and set my phone to Lock after 15 seconds.
For everyday usage, the PIN/Fingerprint is enough to keep others from accessing my content, but what about plain disk access (using some other tools that read the flash disk) if I loose my phone or if my phone gets stolen ?
I liked the previous encryption method.
So, basically, I want to encrypt ENTIRE partition (FDE encryption) with one PIN, not SD Card encryption, not other file encryption solutions, not special vaults, not other stuff... I want my classic encryption back !
Please explain me:
1. Are all the new phones starting from Android 6 already encrypted ?
1.1. If so, why is there a file encryption tool to further encrypt particular files if the user partition is already encrypted ?
1.2. If so, what is the encryption key ? or what kind of encryption is that which does not require a PIN or something ? that means that the key is stored in plain text ? (if I don't offer it a PIN, it means that it must read the key from other places in order to decrypt the data (key that can be read by a thief, too?))
2. If Android 6+ phones are not encrypted, how can I implement full device encryption, and why the hell does Google abandon this kind of full, quick and not-giving-extra-security-thoughts encryption ?
I would kindly ask only experts to reply me.
If you are an expert or you know these things for sure, please reply.
I need a correct, documented (if possible), answer, because the security of my phone depends on it !
Thank you !
Well... anyone ??? Is this really such a hard question ???
I was getting so excited when I read your question, because I am looking for the exact same answer. But then I saw there aren't any answers.
Please can someone who knows about this answer this for us?
Mar0615 said:
I was getting so excited when I read your question, because I am looking for the exact same answer. But then I saw there aren't any answers.
Please can someone who knows about this answer this for us?
Click to expand...
Click to collapse
I'm not an "expert" but I can tell you your data is safe & encrypted by default, that is why you can't find an encryption setting.
As I understand it
1. Yes (Google makes manufacturers sign agreement)
1.1 The data is encrypted on phone but you may choose not to lock it. Also you may allow some other people access to your phone even if you set screen lock or it's possible somebody may get your phone before it automatically locks, that is why here is a separate encryption system that some people may want ho use to encrypt certain files. (I'm assuming this is what you are referring to as I have never used Huawei)
1.2 Yes the system can generate it's own key from it's internal information automatically (note also, if you put in a simple passcode it is just one element the phone will use to generate a long key, so hackers can't crack a simple passkey to get into your phone as it also uses it's internal data to generate the key)
2, All your data is encrypted, ok maybe not all eg if you consider an alarm time your data, as some apps may be able to access limited data eg alarm times.
A quick search produced these two articles that are not overly technical & also show the numerous security improvements that all go to make your phone more secure. I hope it puts your mind at rest (though of course nothing can be guaranteed 100% secure if a well resourced group has physical access to your phone eg a government)
https://m.androidcentral.com/how-android-n-addresses-security
https://www.computerworld.com/article/3220446/android/android-8-oreo-security.html
Ideally I'd like to actually be able to put an arbitrary OS on my tablet. Has anyone figured out how to do this with the Fire HD 8, 8th generation, yet? I'm willing to use soldering to do so. If this is not possible with this hardware, does anyone have a recommendation about what tablet options I have, to do this?
dc123123 said:
Ideally I'd like to actually be able to put an arbitrary on my tablet. Has anyone figured out how to do this with the Fire HD 8, 8th generation, yet? I'm willing to use soldering to do so. If this is not possible with this hardware, does anyone have a recommendation about what tablet options I have, to do this?
Click to expand...
Click to collapse
There is a hardmod to secure root but no custom roms. Consider a 3rd gen HDX if seeking a selection of Nougat based custom ROMs.
Davey126 said:
There is a hardmod to secure root but no custom roms. Consider a 3rd gen HDX if seeking a selection of Nougat based custom ROMs.
Click to expand...
Click to collapse
It shouldn't be possible to modify /system on the 8th generation as it ships with dm-verity enabled.
xyz` said:
It shouldn't be possible to modify /system on the 8th generation as it ships with dm-verity enabled.
Click to expand...
Click to collapse
Ok, interesting, but how are software updates possible on devices with dm-verity? Doesn't that change the file/partitions to the extent that they need a new key for it?
Essentially the firmware update includes a hash of the /system partition (a tree of hashes) signed with Amazon's private key. The boot image includes the public key so that the device can verify the /system integrity. The rest of the boot process already ensures that the boot image isn't tampered with. So to update they just need to generate another /system, generate another hash tree for it and sign it with the private key.
xyz` said:
Essentially the firmware update includes a hash of the /system partition (a tree of hashes) signed with Amazon's private key. The boot image includes the public key so that the device can verify the /system integrity. The rest of the boot process already ensures that the boot image isn't tampered with. So to update they just need to generate another /system, generate another hash tree for it and sign it with the private key.
Click to expand...
Click to collapse
https ---- source.android ---- .com/security/verifiedboot/dm-verity
Yeah this seems to indicate that the more of that partition that is accessed during the runtime, the more time and power are invested into verification during use. Lame.
Anyways, thank you very much, guys, for answering the questions.
I'm also interested in knowing why it isn't possible to just redo the system partition but modify it to match the hash... but I'll wiki that to find out why it doesn't work (SHA-256). I'm guessing that this isn't as simple as a checksum. Even if it meant making another file system to do it... I guess the other option is getting the private key.
W.R.T. building a tablet that doesn't suck, the project that I saw was basically someone who slightly dissassembled a SBC, so that they didn't have to design a mobo and find a chip for it. That makes sense but the SBC that I looked at (Orange Pi Zero ) don't actually seem to use all the options/connectivity provided in the datasheet of the SoC chip. For instance, it's capable of HDMI but there's no HDMI on the board, etc. Also, the project I read about ended up getting very expensive.
Another thing from that site:
"A public key is included on the boot partition, which must be verified externally by the device manufacturer."
What do they mean by verified externally? Like, I know with my tablet I needed to connect to the internet at least once to do anything with it.
This is the part that makes me think that we can mess with it:
" To mitigate this risk, most manufacturers verify the kernel using a key burned into the device. That key is not changeable once the device leaves the factory."
Also, I want to translate this into noob:
" And since reading the block is such an expensive operation, the latency introduced by this block-level verification is comparatively nominal."
Does that mean that the time spent reading the hash is small because there's a lot of calculation involved, such that the transmit time is small compared to the total time, or that the transmission of the next block info can happen during the calculation of the prior block info?
dc123123 said:
Another thing from that site:
"A public key is included on the boot partition, which must be verified externally by the device manufacturer."
What do they mean by verified externally? Like, I know with my tablet I needed to connect to the internet at least once to do anything with it.
Click to expand...
Click to collapse
It means that the boot partition (the boot.img) is verified by the bootloader, in our case that would be LK.
dc123123 said:
Also, I want to translate this into noob:
" And since reading the block is such an expensive operation, the latency introduced by this block-level verification is comparatively nominal."
Does that mean that the time spent reading the hash is small because there's a lot of calculation involved, such that the transmit time is small compared to the total time, or that the transmission of the next block info can happen during the calculation of the prior block info?
Click to expand...
Click to collapse
They're saying that there's no performance hit when enabling dm-verity because reading the actual data from the emmc is so slow you won't notice the additional slowdown introduced by hashing and verifying the block data.