Database Info

[Q] Will Asus ever allow CIFS to be enabled?

The ability to mount Windows shares and read/write is a huge benefit. However you need root to do this. I hear the B70 models have a different key, so regular rooting methods dont work. I understand they had reasons to lock it, but now you limit huge benefit. Will they enable it on their stock stuff eventually?

Android devices by default are not designed to have their file systems capable of being manipulated remotely for security and stability reasons. It's the same reason why root access is not available by default.
These modifications void your warranty because Android is licensed out to the end user as an embedded firmware, and not designed as a user-installable client or server OS. Modifying the OS for unintended usage like a Samba server opens up the device to all sorts of mishaps due to the lack of security gained through rooting, and manufacturers do not want to take responsibility for that.

Using ES File Explorer i can read/write to SMB shares.

dude2k5 said:
The ability to mount Windows shares and read/write is a huge benefit. However you need root to do this. I hear the B70 models have a different key, so regular rooting methods dont work. I understand they had reasons to lock it, but now you limit huge benefit. Will they enable it on their stock stuff eventually?
Click to expand...
Click to collapse
No it will never happen unless Android as a whole get FUSE embedded directly, and even then that just means there are additional tools to prefent horrific lockups.
The problem is that Kernel level filesystems do not react well suddenly being dropped, stale mount point result in jammed native processes and all sorts of bother. Given that SMB over a network can (and does) drop out whenever it feels like it the filesystem<-> SMB mapping is never goign to pass muster on a commercial mobile device.
That said there is no reason you can't have an SMB client (Like ES explorer) that (Much like an FTP client) simply acts as an agent for recovering files. But apps that normally access local files would not be able to "see" files on an SMB share until they were transferred to the tablet.
Hmmm, that said... most people here are talking about "streaming". You could write an SMB client (Like ES explorer) that then opens up a simple http-server on 127.0.0.1 on an unprivileged port then translate that into an SMB client get... though I don't know how you'd do an index other than with a web browser. Hmmm

Is there any Android device that supports hardware accelerated encryption?

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...

best crypt for Android. fail

I recently saw this on Google play.
It's a volume container encryption application that runs on many platforms including Windows Linux and Android and possibly others (ok I admit I'm pretty blind to Mac and Apple).
I thought I would give it a try. I have not used best crypt since I found true crypt.
I was able to create and mount a container in Android.
But that was about it.the built in file browser that you NEED to use is about as user friendly as a bed of thumb tracks. You had no options on what encryption methods to create the container or any other options. That's a pretty glaring problem.
I tried to install the desktop application but it requires internet to install..
And only an idiot would use such a system
(What happens is you need to reinstall to get to your data and you have no internet? All your backups are useless with internet required applications be it installing or running)
Security applications in any form should never NEED the internet to function in any way.
So basically I cannot even recommend looking at this software for any use.
I could understand issues like these in a new software company that knew nothing of security and was just starting out..
But the makers of best crypt have been around for years. And personally I could never see a situation where I would pay for a application that had such issues right at the start.
Even free I would never use it
It's NOT open source software so I can't even comment on their encryption techniques..
(Once again it would not matter as the desktop needs internet access to install and the app has no encryption options)

Secure Spaces Support (or equivalent feature) for Pixel?

I used Graphite Software's Secure Spaces on a Blackphone 2, and I really liked the way it allowed me to keep work and personal data separate. Visiting their website, I see that support is unfortunately limited to a small group of phones, and includes the installation of a customized ROM. In the xdaforums Nexus 5 and Nexus 5X Development forums, there are Secure Space ROM threads, but I'm just curious if anyone knows if there will be future support with Secure Spaces for the Pixel, or if there is another solution that provides a similar separation capability, for the Pixel. (Unfortunately my employer does not allow rooted phones).

Just received notification from Graphite that support for the Pixel is planned. If anyone knows of any similar "separation" technology that's available please feel free to post to the thread.

Not being familiar with Secure Spaces, and having only briefly scanned what it does, could you not do the same thing on the Pixel by setting up an additional user for the phone? When you set up a new user it's like a whole separate phone for that user, including passphrase, apps, storage, email, settings, everything.
Maybe it's an ignorant suggestion, but it looks like that's what Secure Spaces does.

I think that Secure Spaces offers more separation than what you're describing, (although I admit I've never tried setting up two user accounts on my phone to see what separation is provided). My current and former employer require that any devices that access the corporate network, (in order to get email, calendar schedule, etc.), be installed with MDM, (mobile device management), software that allows the IT department to have complete control over the entire phone's configuration, (most obvious if you try to change the security options), and management. Secure Spaces allows me to have separate workspaces, one that corporate IT can own, and another that can be configured and managed as I want. It also keeps data separate between the workspaces.

jasnn said:
I think that Secure Spaces offers more separation than what you're describing, (although I admit I've never tried setting up two user accounts on my phone to see what separation is provided). My current and former employer require that any devices that access the corporate network, (in order to get email, calendar schedule, etc.), be installed with MDM, (mobile device management), software that allows the IT department to have complete control over the entire phone's configuration, (most obvious if you try to change the security options), and management. Secure Spaces allows me to have separate workspaces, one that corporate IT can own, and another that can be configured and managed as I want. It also keeps data separate between the workspaces.
Click to expand...
Click to collapse
When I create a new user under Nougat, it's as if it's a brand new phone. You only have the base apps that were there when the phone was new, you have to set up Gmail again, Chrome is empty, Photos shows nothing, etc. You can manage security settings, pretty much everything. The only thing I've found that it will not let the secondary user do is open the Messenger application - so the secondary user cannot read or send text messages on the phone - which is of course a good thing.
I also found an article with this blurb about the separation between users:
Under the hood, file-based encryption enables this improved user experience. With this new encryption scheme, the system storage area, as well as each user profile storage area, are all encrypted separately. Unlike with full-disk encryption, where all data was encrypted as a single unit, per-profile-based encryption enables the system to reboot normally into a functional state using just device keys.​
Anyway, it's probably all irrelevant now since the product you're used to and happy with is available for the Pixel. That said, if you haven't installed Secure Spaces yet it might be worth taking a look at it. Just two-finger swipe from the top and tap the "user" icon and then "Add user".

Thanks for spending the time to research this issue.
I'm sure that folks over in the two SecureSpaces development threads here, (1., 2.), can speak more authoritatively on what Secure Spaces offers over a stock setup. For me being able to configure the security options for my personal space, separate from my work space, is important, as well as keeping the data separate from each other.

What about Android for Work?
I used to use it with BES12, worked well.
Sent from my Pixel using Tapatalk

Anything we need to do about the latest WPA2 vulnerabilities that were found?

This is the story I'm referring to for those who haven't heard yet.
I just got my Note 8 on Saturday and did get a carrier update later in the day, not sure if it was related to this. Anyone have any info on what we need to do or are we waiting for AT&T/Samsung to release a patch?
From the link:
As a result, all Android versions higher than 6.0 are also affected by the attack, and hence can be tricked into installing an all-zero encryption key. The new attack works by injecting a forged message 1, with the same ANonce as used in the original message 1, before forwarding the retransmitted message 3 to the victim. In each case, the attacker can force a targeted device to re-install an already-in-use shared key, downgrading the key.
Click to expand...
Click to collapse

This will require an update from Samsung. Not holding my breath on that happening anytime this year.

Avoid public wifi like the plague. Even after the patch I'd stay away from it.
Also this includes turning on your hotspot in public. At least until a patch is pushed out.
That will keep you safe for about 6 months until the next bug is discovered. It's the nature of IT security.
One thing that is a great idea and an awesome feature on Samsung is the "Secure Folder" app.
You can use it to store pictures, files, apps, etc. They are encrypted by the KNOX container and require a pin or password to open the secure folder.
If you move let's say, your private pictures, your banking app, and any sensation files (eg credit cards, ID, passport, etc) into the app even if your phone gets compromised you should be okay.
*as a disclaimer I work in ISO for a fortune 100 company. More than will to offer any advice about protecting your phone, computer, wifi etc.

Thanks I didn't think about using the Secure Folder. I just moved (not copied) a photo into there to test it but the photo still shows up in the gallery, yet I don't see it when browsing for it from within the Secure Folder.
When something is within this folder, can it still be accessed from outside the app or do you always need to open the app, type in the password and then access it? Like could I still attach photos from there easily into a message/email or do I need to go in there, move them out of the folder, attach them, them move them back? Hope that makes sense.

Kadin said:
Thanks I didn't think about using the Secure Folder. I just moved (not copied) a photo into there to test it but the photo still shows up in the gallery, yet I don't see it when browsing for it from within the Secure Folder.
When something is within this folder, can it still be accessed from outside the app or do you always need to open the app, type in the password and then access it? Like could I still attach photos from there easily into a message/email or do I need to go in there, move them out of the folder, attach them, them move them back? Hope that makes sense.
Click to expand...
Click to collapse
No if it moved correctly it should be hidden unless you are in the secure folder.